SCRUM parte 1: “Introducción” y primeras dificultades que se presentan.

Standard

Buen día, hoy les quiero compartir mi experiencia implementando SCRUM con varios equipos. Primero que nada esta serie de publicaciones (así es, serán varias publicaciones) más que una guía para implementar SCRUM en tu negocio o equipo es para transmitir lo mejor posible mis experiencias y opiniones sobre algunos temas que se suscitan al tratar de implementar este framework, también hacer notar que si bien en el título escribí “Introducción” este,  está entre comillas, y eso es porque la verdad SCRUM es sencillo de explicar así que me enfocaré en cosas que considero básicas. Ahora sí empecemos.

(Nótese que la imagen es nada más para poner algo de SCRUM, pero después le daré sentido xD)

Primero me gustaría aclarar que SCRUM no garantiza buenos resultados, y que tampoco es tan fácil de implementar, para empezar SCRUM tiene como punto de partida algo que a muchos les va a causar ruido y esto es que se basa en equipos AUTO-ADMINISTRADOS. Nótese el uso de mayúsculas, ya que la mayoría de esta introducción es referente a este tema.

En SCRUM es muy importante que el Scrum Team sea integrado por personas con alto sentido de responsabilidad, compromiso, iniciativa e incluso me atrevería a incluir emprendedor, esto es porque en SCRUM el primer responsable de que se entregue lo que se dijo es el equipo. También es muy importante mencionar que el Scrum Master NO ES el responsable de que el equipo entregue y este es un error en el que se puede caer ya que en ocasiones pensamos que un SM(Scrum Master) es lo mismo que un líder de proyecto, lo cual está alejado de la realidad.

Pero bueno para seguir con esta introducción a SCRUM y no enredarme en temas que veré más adelante, empezaré por definir SCRUM con mis palabras, “Trabajo en Equipo”, tal vez suene simplista y prefiero pecar de eso, que enredarlos mucho.

Scrum es el juego de equipo en cuanto a desarrollo de proyectos. Con este framework la planeación es un poco diferente a lo que muchas veces hacemos, ya que se trabaja sobre metas en común, es decir todo el equipo debe trabajar para un objetivo a la vez y no. Terminar el proyecto no es un objetivo, lo que quiero decir es que por poner un ejemplo, supongamos que planeamos un sistema para captura de calificaciones. Muchas veces con otras formas de trabajar lo que hacemos es repartirnos el trabajo por módulos o cosas similares, esto en SCRUM es un poco diferente, con SCRUM se busca que el equipo entero trabaje sobre objetivos específicos, digamos por ejemplo que decimos que vamos a hacer el módulo de usuarios y el de alumnos. Suena “lógico” dividir al equipo y decir que la mitad haga un módulo y la otra mitad otro módulo (suponiendo que son más o menos del mismo tamaño), sin embargo es de cierta manera es preferible que todo el equipo se enfoque en terminar primero un módulo que hacer los dos al mismo tiempo.

Esto tiene una razón de ser y no es mero capricho, ya que con este framework lo que se espera es entregar algo funcional, es decir, no es bien visto entregar sólo el análisis, diseño o cualquier cosa que no le sea ùtil al product owner (llamémosle cliente pero no es del todo correcto, más adelante veremos el ¿porqué?), con SCRUM se “prefiere entregar el 100% del 80% que el 80% del 100%” esta frase nos la comentó alguien en un curso de Scrum, pero no recuerdo bien quien fue, una disculpa, pero bueno esta frase es MUY importante para mi, ya que te da un enfoque un tanto diferente, aquí no se busca sacar tareas o “trabajar” más, se busca producir. Lo que la frase nos dice es básicamente que si al PO(product owner) le entregas el 100% del 80% del producto, tendrá un 80% FUNCIONAL, es decir que puede utilizarlo, mientras que tal vez entregues el 80% del 100% es decir, a todas tus funcionalidades les falta algo, por lo tanto le estás entregando 0% de valor al cliente.

Esto hace para mi la gran diferencia en el enfoque de SCRUM, aquí se busca producir cosas que si el PO lo desea, puede enviar a producción inmediatamente, ya que con el enfoque de entregar el 100% básicamente lo que nos dice siguiendo el ejemplo de la aplicación escolar es que preferimos entregar el módulo digamos de usuarios funcional al 100% aunque no se entregue nada del módulo de alumnos. Porque para fines prácticos es muy probable que si le entregas el 80% del módulo de usuarios y el 80% del módulo de alumnos, realmente no le estás entregando nada.

Otra cosa relacionada con este punto es que cuando hablamos de entregar el 100% estamos hablando del 100%, es decir se incluyen el análisis, diseño, implementación y las pruebas, y toda cualquier otra cosa que sea parte del desarrollo. Así que no se vale eso de entregar algo que no fué probado.

Bueno, como me estoy extendiendo más de lo que quiero sólo voy a comentar otra característica que me gusta de SCRUM y es que tiene un enfoque de apertura al CAMBIO, es decir, SCRUM nos dice que entendamos que el PO tiene derecho a cambiar de opinión y que es normal, y que inclusive deben ser esperados dichos cambios. Esto es otra de las cosas que me agradan de SCRUM, ya que es un poco más realista a esperar que el cliente no cambie sus necesidades en seis meses de desarrollo.

El otro tema que voy a hacer enfoque en estos posts, y que realmente es lo que me importa hablar, pero que será para otra ocasión, es de los equipos AUTO-ADMINISTRADOS, este tema me gusta porque desde mi punto de vista pone a prueba el carácter de las personas y su compromiso para que las cosas pasen.

Les prometo para la siguiente publicación, colocar más contenido, pero la verdad creí necesario separar el tema en varias publicaciones. Y trataré de que sea lo antes posible.

Nos vemos en el siguiente post.

Leave a Reply

Your email address will not be published. Required fields are marked *