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

Standard

Hola gente. Pues siguiendo donde nos habíamos quedado, en esta ocasión además de como se los prometí, hablaré de los roles. Dejando al último el del SCRUM Team, ya que es para mí uno de los puntos más difíciles de implementar en un principio.

El primer rol que vamos a ver es el del Product Owner (PO de ahora en adelante). Este rol al contrario de lo que pudiéramos pensar, no es lo mismo que el cliente o usuario final, es más que nada el medio de comunicación para lo que quiere el cliente. Es decir, que nuestro PO no tiene que ser por fuerza un cliente, sino que es el responsable de administrar los items de nuestro Product Backlog (PB).

Para que se entienda mejor, tomemos como base el siguiente gráfico.

POExamples

Icons made by Freepik from www.flaticon.com is licensed under CC BY 3.0
Como podemos observar, el primer caso es el más sencillo, donde tenemos un Cliente, que a su vez cumple el rol de PO.
En el segundo caso, podemos observar que hay un “grupo de clientes” que puede ir de 1 a “n” cantidad, que tienen un PO que los “representa” por así decirlo.
Y el último es muy parecido al anterior, sólo que en este caso un miembro de nuestra empresa es el PO, por ejemplo un arquitecto de software o un líder de proyecto, etc.
Lo que intento ilustrar es que no es lo mismo un Cliente que un PO, sino que este último es cualquier persona que esté a cargo del manejo del PB. Así mismo, su responsabilidad es acordar cuando se hace cada item del PB, fechas de liberaciones, cambios a los items, etc.
Una última cosa que veo impo rtante mencionar del PO, es que siempre se busque que sea alguien con disponibilidad para atender dudas, juntas, revisiones, en fin, cualquier cosa necesaria durante el proceso de desarrollo, ya que en SCRUM se promueve la comunicación activa entre el Development Team y el PO, y en caso de que este último sea difícil de contactar, es muy probable que genere problemas ya que el equipo durante el desarrollo va a tener dudas sobre los requerimientos y si estas no son resueltas de manera ágil, puede generar retrasos o que lo que se entregue no sea lo que se buscaba por el lado del PO.
El segundo rol del que voy a hablar es el Scrum Master (SM), creo que este es el rol más sobre-valorado o menos entendido (según como se vea) del framework SCRUM. Esto lo comento porque como lo mencioné en la publicación anterior, muchas veces se piensa que el SM es el equivalente a un líder de proyecto o similar, lo cual está muy alejado de la realidad. Primero me gustaría comentarles algunas cosas que NO hace y NO ES el SM:
  • No es un líder de proyecto. Tienen responsabilidades distintas.
  • No es un jefe. El SM no tiene la responsabilidad de como decimos “latiguear” al ST, sino los miembros del ST son los responsables de hacerlo.
  • No es el responsable de que se hagan las cosas. De nuevo, esto es responsabilidad del ST.
  • No es un miembro del equipo. Si bien pudiese parecer que el SM es parte del ST, esto no es correcto, ya que realmente no tiene actividades de desarrollo durante la construcción de los proyectos.
  • No es un secretario. El SM no tiene porque ser quien lleve las minutas, aunque puede hacerlo, no es su responsabilidad.
  • Un SM no hace planeación, esta la hace el ST junto con el PO.
  • Un SM no hace de mensajero.

Probablemente hay más cosas que pudiera listar pero creo que con estas se entiende el punto y es que muchas veces se llega a confundir con este rol, como si se hablase de un gerente de proyecto o similar.

El rol del SM es simplemente el de FACILITADOR, es decir, APOYA al equipo y al PO, ayuda a hacer acuerdos, a que se entiendan los PO con los ST, ayuda a llevar las reuniones a cabo, a conseguir licencias de software en caso de necesitarse, a gestionar cosas que el equipo necesite.

A continuación listaré, algunas de las responsabilidades del SM:

  • Ayudar a quitar impedimentos al equipo (licencias de software, compra de equipo, etc.)
  • Ser moderador de reuniones ya sea del ST o reuniones con ST y PO.
  • Darle visibilidad al equipo de cómo van con respecto a la planeación. Por ejemplo, diariamente mostrarles un burndownchart.
  • Inculcar la filosofía SCRUM en el ST y el PO.
  • Proteger al equipo de distracciones.

Estas son algunas de las responsabilidades del SM. Como podemos observar, el SM no tiene tantas responsabilidades como muchas veces lo aparenta, sin embargo no quiere decir que dicho rol no sea importante o que sea fácil de cumplir, ya que es indispensable sobre todo en equipos que están iniciando con SCRUM.

Por último, pudiéramos decir que la meta final del SM es, hacer que el ST no necesite de un SM, ese debe ser el objetivo de este rol.

Bueno, después de estos dos roles viene el último que es el Scrum Team. Este rol es el compuesto por los desarrolladores, y es recomendable que se tengan algunas consideraciones cuando se forman los equipos.

  • Equipos no muy grandes de desarrollo de 5-9 creo es lo recomendado. Cuando haya proyectos muy grandes que necesiten muchas personas es una opción el separar el proyecto en varios equipos, cada uno con su PB, SM e incluso PO. Esto es preferible a tener equipos de muchos integrantes.
  • Los miembros del equipo de preferencia deben tener el mismo “nivel/experiencia”, esto se recomienda sobre todo porque muchas veces las estimaciones de alguien con experiencia y alguien sin experiencia pueden variar demasiado y hacer más difícil el acordar los tamaños de los items del PB, sin mencionar que la diferencia de experiencia puede llegar a amedrentar a los más novatos, o desaprovechar a los más experimentados. Lo que se busca es que el equipo crezca como una unidad.
  • Los integrantes deben ser personas multidisciplinarias en lo posible, esto ya que es común que todos los integrantes tengan que realizar actividades tanto de análisis, diseño, programación, pruebas y cualquier cosa que se necesite. Es normal que cada integrante tenga su área de especialidad, pero tiene que ser apto en el resto de las áreas, para así tener un equipo que realmente pueda apoyarse entre sí.
  • El ST debe ser una entidad auto-administrada, este es para mi el punto más importante, así que en lugar de simplemente listar voy a extenderme un poco más.

Un ST debe ser auto-administrado, esto quiere decir un par de cosas, la primera de ellas es que es el equipo y no el SM ni el PO los que definen cómo van a trabajar de manera interna. Es decir, un SM no les va a decir quien va a hacer cual tarea, sino que esas decisiones las va a tomar el equipo.

Colocaré algunos ejemplos de situaciones que se me ocurren para ejemplificar este término de “auto-administrado”:

  • En SCRUM el equipo decide cuando hace las cosas, la única fecha de compromiso es la del fin del sprint, es decir, para fines prácticos lo que importa no es que se “trabaje” sino que se produzca, viéndolo de otra forma. Supongamos que el equipo me dijo que me entregaría 3 módulos, el A, el B y el C. A mi no me interesa si no hacen nada la primer semana por decir algo, y la segunda semana se tienen que desvelar, el compromiso del ST es entregar para el final del Sprint, lo que dijo que entregaría.
  • En el ST nadie es jefe/superior y todos lo son, esto significa que en SCRUM, el equipo es el responsable de motivar, exigir, y de cierta forma hasta despedir miembros del equipo. Esto es un cambio drástico sobre cómo se trabaja normalmente, ya que, usualmente estamos acostumbrados a que un líder de proyecto o jefe, esté exigiendo resultados, de pláticas para tratar de motivar al equipo a mejorar y todas las prácticas que ya conocemos. Este es uno de los puntos más difíciles que he visto de entender por el equipo, ya que muchas veces, por el compañerismo o por la experiencia, o simplemente por la personalidad de algunos integrantes, no suelen decir las cosas como son. Un ejemplo es, suponiendo que en un equipo de 5 personas, un miembro del equipo no cumple con lo que se comprometió a hacer, lo cual provoca que el equipo no entregue en tiempo y forma. El ideal, es que al interior del equipo, todos los integrantes hablen con esa persona, y exigirle que cumpla con su responsabilidad, o en caso de que sea recurrente este comportamiento en el miembro, es la OBLIGACIÓN del equipo solicitar que este miembro sea retirado o sustituido por otra persona. Y aunque este punto suena lógico, realmente por las razones que mencioné anteriormente se dificulta en ocasiones que el equipo lo haga.
  • TODO ES RESPONSABILIDAD DE TODOS, esto es que, si bien, internamente el equipo es el encargado de exigirse de manera interna, es igual de importante que se entienda que aquí no existen los individuos, sino sólo el equipo. Un ejemplo de esto es, que en el ejemplo anterior, cuando al final el ST presente al PO los resultados del sprint, no va a decir “Juan, Pedro y yo sí terminamos, pero Margarito no”, sino que el ST debiera decir “No cumplimos con lo que dijimos que íbamos a entregar”, esto puede sonar injusto, pero desde mi punto de vista, es más justo y realista, ya que para el final del día, nosotros decimos que vamos a entregar como equipo, y es nuestra responsabilidad hacer lo necesario para que las cosas se hagan.

Bueno, hay muchos ejemplos más que se me ocurren, pero la verdad, creo que he sido bastante claro, sólo me queda cerrar este tema de “auto-administrado” con al que pienso es una parte clave del uso de SCRUM.

Muchas veces como empleados, nos quejamos de las órdenes del jefe, de cómo se hacen las cosas, de las exigencias en tiempos muy justos, de requerimientos más levantados, de planeaciones mal hechas, de código más codificado, etc. Con SCRUM sin embargo se tiene, por fuerza que dar al equipo “PODER DE DECISIÓN”, es decir, darle la libertad (y responsabilidad) de planear, estimar, proponer, construir, tener canal abierto con el PO para resolver dudas, en fin, aquí el responsable de TODO el proceso de desarrollo es, precisamente el equipo de desarrollo AKA Scrum Team.

Algo que, muchas veces he observado, es que cuando le das este tipo de poder al equipo, lo primero que pasa es que la productividad cae. Esto resulta interesante, y pienso que es una de las cosas con las que tenemos que tener más cuidado cuando implementamos SCRUM, en un ambiente donde no estamos acostumbrados a como desarrolladores, tener estas libertades parece ser, por lo menos en mi experiencia, que las personas tienden a tomar decisiones equivocadas, la primera es sobre-estimar, es decir, muchas veces se hacen estimaciones sobradas por miedo a no cumplir con el compromiso o porque les gusta tener ese “colchón” para en caso de tardar un poco más tener tiempo de compensar, esto lo que provoca es que muchas personas se queden en su zona de confort, con lo cual, al no tener mayores exigencias que vinieran de un jefe, puede llevar al equipo a que su productividad sea mucho menor a la que realmente es su potencial.

Otro aspecto que considero una de las más grandes oportunidades que nos da SCRUM a los desarrolladores, es el tomar la responsabilidad de que las cosas se hagan, es el de tomar el control, y demostrar lo que realmente podemos conseguir cuando se nos da la oportunidad y sobre todo el poder de decisión sobre un proyecto. Y es al mismo tiempo un riesgo grande, ya que, la mayoría de las veces, como empleados, cuando un jefe no nos dice que hacer, corremos el riesgo de sentirnos perdidos, además de que al mismo tiempo es un poco injusto pedir que con un cambio tan drástico de una manera de trabajar “tradicional” el equipo entienda que tiene que cambiar su mentalidad y su sentido de responsabilidad.

Bueno, me estaba emocionando y ya va algo de texto, así que cerraré hasta aquí el tema.

Por favor tengan paciencia pues es que casi no tengo el tiempo para hacer los artículos y prefiero hacerlos cortos.

En el siguiente post, ya veremos más sobre el proceso que nos sugiere SCRUM para trabajar, y al mismo tiempo con esto daré por terminado el tema de los roles.

Espero que a alguien le sirvan estas experiencias. Saludos y hasta el siguiente post.

 

Leave a Reply

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