Roles en Scrum | El equipo Scrum
Introducción
Una de las principales contribuciones de Scrum es que definió más claramente tres roles que son los que se encuentran dentro de un equipo, enfatizando que tres y sólo tres roles son necesarios.
Sin embargo con el paso de los años estos tres soles han sido mal entendidos principalmente porque las organizaciones tratar de hacer una equivalencia directa con cargos jerárquicos existentes.
El primer punto de cambio proviene de que precisamente las organizaciones deben darse cuenta de que tienen que cambiar su estructura jerárquica formal hacia algo más ligero y simple.
Los roles tampoco fueron creados para hacer un plan de carrera ya que ellos coexisten con el mismo nivel de jerarquía y autoridad dentro del equipo. Dicho de otra manera, cada rol esta en relación de pares con los otros dos roles.
El equipo
En principio hay que hacer notar que en terminología Scrum existen dos equipos:
El Equipo Scrum que aglutina a todos los roles
El Equipo de Desarrollo que aglutina a los Desarrolladores
Personalmente creo que esta separación conceptual contribuye muchas veces confusión ya que la gente empieza a preguntarse cosas como ¿si soy Desarrollador a que equipo pertenezco?
Considero entonces que es mucho más sencillo utilizar el termino Equipo para referirse a las personas que trabajan juntos en el desarrollo de un producto [Larman17].
Tamaño del equipo
La preferencia siempre es tener equipos pequeños puesto que esto facilita la colaboración e interacción efectiva. Esta demás decir que un equipo pequeño se comunicara efectivamente si todos sus integrantes trabajan desde la oficina y comparten la misma mesa.
Sin embargo cuando un equipo es demasiado pequeño, digamos dos personas, no existe suficiente diversidad de opinion ni tampoco suficiente gente para cada rol. Un equipo demasiado pequeño también tiene menos posibilidades de avanzar rápido pues simplemente no hay suficientes desarrolladores que escriban código.
En el otro extremo, un equipo que se acerca o pasa la decena de integrantes se vuelve ineficiente debido a: problemas de comunicación y coordinación, malos entendidos, desocupación, y especialización excesiva.
Por tanto llegamos a que un tamaño recomendable de equipo debería ser de más o menos siete integrantes incluyendo todos los roles. Sin bien la teoría dice que podemos aumentar o reducir dos personas mi recomendación es que tengamos siete como el número máximo de integrantes para un equipo.
Los Tres Roles
Los tres roles de Scrum son los siguientes:
ScrumMaster
Product Owner
Desarrollador
Cada uno de estos roles tiene un enfoque diferente:
ScrumMaster enfocado en Scrum, la gente, los procesos adaptativos, el cambio organizacional, la motivación, el trabajo en equipo
Producto Owner enfocado en el producto, el cliente, el mercado, la estrategia, el mediano y largo plazo
Desarrolladores enfocados en en la calidad del código, en las prácticas técnicas, la táctica, en aprender el lenguaje especifico del cliente, y el aprendizaje constante
No existen roles adicionales ni deberían existir; no existe por ejemplo el rol de Manager o Project Manager pues el equipo se maneja a si mismo y no hay una figura central de autoridad.
Tampoco existe roles de Líderes Técnicos o Arquitectos porque las decisiones técnicas se toman en base al consenso y conocimiento de los desarrolladores.
El liderazgo como tal existe pero es primero rotativo dependiendo del tema o coyuntura y segundo voluntario pues la gente decide a quien seguir.
Derechos y Responsabilidades del Product Owner
El Product Owner tiene los siguientes derechos:
Abortar el Sprint si identifica que el Incremento del Producto perdió todo valor de negocio para el cliente
Tener la palabra final acerca del orden del Product Backlog
Pedirle a los desarrolladores que en cualquier día del Sprint le muestren software funcionando, bien construido y corriendo en un ambiente integrado preferentemente de producción
El que un Product Owner no pueda ejercer sus derechos es un indicador claro de que algo no esta funcionando bien y es labor suya y del resto del equipo (e incluso la organización en su conjunto) trabajar para que pueda ejercerlos.
Si bien el Producto Owner tiene derechos también tiene obligaciones, alguna de ellas son:
Maximizar el potencial retorno de la inversión identificando características del producto y ordenando esas características en una lista (Product Backlog)
Trabajar dedicadamente para que el Product Backlog sea visible, pequeño, adaptativo y claro para todo el equipo y clientes
Conectar a los desarrolladores con los clientes que originaron los requerimientos para que puedan hablar directamente y facilitar la comunicación de primera mano
Ser el guardian de la vision del producto, es decir, ser quien tenga claro que está construyendo el equipo, para quien, en cuanto tiempo y con que impacto esperado
Mantener el Product Backlog ordenado y alineado con los objetivos de negocio que se persiguen con la construcción del producto
Nótese que no menciono como una de las responsabilidades del Product Owner el escribir historias de usuario ya que éste es uno de los malos entendidos más grandes acerca de este rol.
Las historias de usuario no se deben escribir por las siguientes razones [Larman10]:
El lenguaje escrito no es la forma más eficiente y económica de comunicación
Historias de usuario detalladas con lenguaje escrito eliminan la necesidad de comunicación oral, debate y creatividad colectiva
Mucha escritura hace que el equipo invierta tiempo excesivo analizando y redactando documentos convirtiendo Scrum en una cascada dividida en fases
Al escribirse las historias se disminuye significativamente la necesidad de que el cliente hable con los desarrolladores y viceversa, en Scrum queremos exactamente lo opuesto “colaboración con el cliente”
Las historias, porque el nombre correcto es “historias” y no “historias de usuario”, se crearon para tener presente un patrón de comportamiento en el cual los desarrolladores interactúan con los clientes de manera frecuente [Beck99].
Derechos y Responsabilidades del Scrum Master
El ScrumMaster tiene derechos tales como:
Llamar la atención del equipo cuando hacen algo completamente desviado de la esencia de Scrum pero lo llaman Scrum
Tener el respaldo del nivel más alto de gerencia para tratar de cambiar el sistema organizacional dentro del cual opera el equipo
Tratar de extender Scrum muchos más allá del equipo para contagiar a toda la organización y provocar su transformación
Es importante hacer notar que el simple hecho de empezar con Scrum es de por si disruptivo para muchas organizaciones todavía ancladas en prácticas Tayloristas. Como corolario de lo anterior no se puede esperar que al adoptar Scrum todo siga como antes, por el contrario Scrum −si su adopción es exitosa− acabará transformando una organización que comenzará a emplear prácticas de administración modernas [Hamel07].
Las obligaciones del ScrumMaster incluyen por ejemplo:
Crear, cultivar y expandir un ambiente de aprendizaje continuo donde el equipo se sienta cómodo experimentando, fallando y aprendiendo
Cambiar al equipo y las dinámicas de la organización
Ayudar a que el equipo se comunique efectivamente entre sus miembros pero también externamente con los clientes y el resto de la organización
Colaborar con el equipo para despejar obstáculos
Contribuir para el equipo se mantenga enfocado y cercano al lugar donde realmente ocurre el trabajo (gemba)
Insertar en el equipo la mentalidad de siempre andar buscando y eliminando formas de desperdicio [Ballé14]
Derechos y Responsabilidades del Desarrollador
Los desarrolladores tiene derechos como por ejemplo:
Sentirse cómodos y respaldados para decir “no se”
Ser capaces de autoorganizarse y decidir por si mismos como hacer el trabajo
Invertir tiempo, esfuerzo y energía para crear un producto de software bien construido que los haga sentir orgullos de su trabajo y dominio de su artesanía
Que los desarrolladores entiendan sus derechos y tengan el respaldo de la organización para hacerlos valer es vital. De nada serviría que los desarrolladores crean tener estos derechos y la gerencia se los quite o simplemente les diga como hacer la cosas y los presione al punto de no dejarlos invertir tiempo y esfuerzo para crear software con calidad.
El conocimiento de la artesanía de software es vital pues sólo a través de él los desarrolladores aprenden los fundamentos de su oficio, fundamentos que deberían pasarse de generación en generación y no redescubrirse para cada producto. Artesanos de software con conocimiento del oficio muchas veces son necesarios para capacitar al equipo [Mancuso15].
Si hablamos de las responsabilidades de los desarrolladores, estas incluyen entre otras:
Aprender una segunda, una tercera y de ser posible hasta una cuarta especialidad técnica para así poder construir más efectivamente al equipo
Aprender el lenguaje y terminología del dominio de conocimiento con el que se esta trabajando para comunicarse eficientemente con el cliente
Construir software utilizando prácticas modernas para el desarrollo de software [Beck99]
Evitar desperdicios en el trabajo y procesos que retrasen la retroalimentación y comunicación efectiva con el cliente
Manifestar su opinión cuando se sienten sobrecargados o cuando sienten que el producto esta yendo en la dirección equivocada
Características del Equipo de Desarrollo
El Equipo de Desarrollo debe reunir ciertas características para realmente funcionar bien [Larman08], características tales como:
De larga vida, que quiere decir que los miembros del equipo se conocen de hace mucho y viene trabajando años juntos
Co-ubicado, que literalmente implica que todos los miembros del equipo trabajan desde la misma oficina y se están sentados compartiendo la misma mesa de trabajo
Sin jefes formalmente asignados, esto implica que no hay una jerarquía impuesta sino líderes naturales que el resto del equipo decide seguir dependiendo de las circunstancias
Autoorganizados, que pone el poder (y la responsabilidad) en los miembros del equipo para decir como se organizaran para llevar a cabo el trabajo
Empoderados, que quiere decir que los miembros del equipo toman decisiones técnicas por si mismo sin tener que consultar o ser aprobados por alguna otra persona
Las características anteriores parecen ser muy caras y contradicen la tendencia de tener outsourcing y equipo geográficamente distribuidos, pero si lo pensamos bien, hacemos las cuentas, y le preguntamos a la gente de los equipos que hacen el trabajo encontraremos que tienen sentido.
Desde una perspectiva sistema, si tenemos un equipo visto como un sistema que tiene miembros pasajeros, que esta globalmente distribuido, que tiene jefes, que recibe ordenes, y que require aprobaciones entonces acabamos con un sistema más complejo, jerárquico, lento y burocrático.
Scrum desde luego no quiere lo anterior sino más bien persigue la noción de simplicidad sistémica donde un equipo opera de la manera más efectiva posible con la menor complejidad.
El Product Owner es una Sola Persona
Existen varias razones para concentrar la responsabilidad de Product Ownership en una sola persona, una de las más importantes es que una persona en lugar de un comité acorta el proceso de toma de decisiones y ayuda a mantener la integridad del producto.
El concepto de tener una persona con capacidad total de decisión sobre el producto no es nuevo, de hecho se inspira en el Chief Engineer de Toyota que tiene todo la responsabilidad sobre el desarrollo y puesta en producción de un vehículo.
Aún cuando pensamos o necesitamos escalar Scrum para múltiples equipos lo más recomendable es mantener un solo Product Owner y un sólo Product Backlog para un producto que será desarrollado por centenares de desarrolladores [Larman17].
Un Product Owner para ser efectivo en su rol debe realmente estar inmerso en el mercado y entender a cabalidad sus necesidades, más importante todavía debe ser capaz de anticipar los movimientos del mercado.
El Product Owner Tiene la Palabra Final Acerca del Producto
Aún cuando los usuarios, los clientes, y los ejecutivos pueden tener opiniones respecto al rumbo del producto, es la prerrogativa del Product Owner decidir que va o no en el Product Backlog y en que orden.
Como el Product Owner tiene la palabra final sobre el producto él debe buscar tener ciclos cortos de retroalimentación para validar sus ideas e hipótesis acerca del producto.
Los ciclos cortos de retroalimentación a su vez tienen dos precondiciones:
Tener software funcionando en todo momento
Tener acceso a clientes o usuarios reales en todo momento
Si lo anterior no es posible todavía mi sincera recomendación es trabajar hasta conseguir que si lo sea porque no hay sustituto para la retroalimentación real.
La retroalimentación real que recolecta el Product Owner de los usuarios finales, el mercado e inclusive el equipo, le permite redireccionar el curso del producto o validar que se está avanzando en la dirección correcta, pivotear o perseverar en terminología de Lean Startup [Reis11].
Sólo Product Owner Aprueba Trabajo para el Equipo de Desarrollo
El Equipo de Desarrollo esta compuesto por desarrolladores a tiempo completo que trabajan en un sólo producto a la vez y es el Product Owner quien decide que se trabajara en cada Sprint, romper esta regla trae consecuencias como:
Pérdida de enfoque del equipo con el consiguiente costo de reenfoque
Demasiadas distracciones porque el trabajo viene desde multiples fuentes causando retrasos, peleas internas, retrabajo, y confusión de prioridades
Cabe hacer énfasis en que si bien el Product Owner es quien aprueba que trabajo se hará, ya a la hora de hacer el trabajo los desarrolladores deben comunicarse directamente con los clientes para así entender que se debe hacer e ir recolectando retroalimentación a medida que avanzan con el trabajo.
De hecho una de las grandes confusiones con el rol del Product Owner es pensar que él es el único que puede y debe hablar con los clientes, si esto acaba ocurriendo el Producto Owner se convertirá en el recurso critico que provocará un cuello de botella y consecuentemente retrasará el flujo de trabajo [Goldratt90].
Desde la teoría de la comunicación se sabe que mientras más nodos se añadan en un canal de comunicación más tarde y distorsionado llegará el mensaje. Es por esta razón que tampoco conviene tener un Product Owner que este de hombre en el medio entre el equipo y el cliente.
Conclusiones
Los roles de Scrum son solo tres y deben mantenerse así pues no se necesitan más. Cuando se observan problemas en la adopción de Scrum buscar en el número de roles o añadir más personas normalmente no es la solución, el problema muchas veces está en otro lugar.
Tres roles implican simplicidad y es que en esencia Scrum es minimalista y Lean, es importante siempre recordar lo anterior para no complejizar el Equipo Scrum con nuevos roles o figuras de poder innecesarias.
Los roles son solamente eso roles pero no cargos jerárquicos que limitan responsabilidad y derechos de manera estricta. Al final el trabajo en equipo y la colaboración debe sobreponerse por el encima del dogma que puede llevar a que alguien diga “yo no hago ese trabajo porque no esta definido dentro de mi rol”.
Bibliografía
Larman17 Larman C., Vodde B., 2017. Large-Scale Scrum More with LeSS, Addison-Wesley
Larman10 Larman C., Vodde B., 2010. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Addison-Wesley Professional
Beck99 Beck K., 1999. Extreme Programming Explained: Embrace Change, Addison-Wesley
Hamel07 Hamel G., 2007. The Future of Management, Harvard Business Review Press
Ballé14 Ballé M., Ballé F., 2014. Lead With Respect A Novel of Lean Practice, Lean Enterprise Institute
Mancuso15 Mancuso S., 2015. The Software Craftsman: Professionalism, Pragmatism, Pride, Prentice Hall
Larman08 Larman C., Vodde B., 2008. Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum, Addison-Wesley Professional
Reis11 Reis E., 2011. The Lean Startup, Crown Business
Goldratt90 Goldratt E. M., 1990. Theory of Constrains, The North River Press
Artículo Original: https://percella.com/2019/01/24/roles-en-scrum/