– Post escrito por María Morales (@MaMoralesMC) y Noemí Navarro (@nnsanchez92).
Hace más de un año ya se hablaba de una de las estrategias para escalar agilidad por el blog con el post otra estrategia para escalar Scrum: Disciplined Agile Delivery (DAD).
Como ya hemos dicho otras veces, es importante moverse a la velocidad del mercado, que el negocio esté alineado con desarrollo, el desarrollo con buenas prácticas, el testing ágil y una larga lista de etc.
En este post explicaremos en más detalle las partes que nosotras consideramos más importantes de DAD, nos hemos basado en el libro de Scott W. Ambler Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise (IBM Press).
Una de esas cosas es el equipo, por eso, lo primero de lo que queremos hablaros es de los roles, así que vamos a ello…
Roles en DAD
En DAD respecto al equipo no hay reglas obligatorias, sino que nos enseñan unas reglas básicas como guía para mejorar en cuanto a eficacia. Cuando hablamos del equipo tenemos que explicar los roles y sus responsabilidades, según DAD, una persona puede tener varios roles, y con el tiempo ese o esos roles pueden cambiar, además un rol puede ser representado por varias personas al mismo tiempo.
DAD considera que todos los miembros son iguales, independientemente de los roles que tenga, entonces todas las personas trabajan para llegar a una solución o a cumplir una necesidad. Hay unas responsabilidades mínimas, esto hay que tenerlo claro y además saber que no están organizadas en jerarquías.
Los roles se agrupan por categorías: los roles primarios (que son independientes de escalar agilidad) y los roles secundarios, que se encuentran para abordar las dificultades de escalar agilidad en nuestra organización.
Roles primarios en DAD
En este primer post nos vamos a centrar en los diferentes roles que hay en DAD denominados primarios, en primer lugar os dejamos una primera imagen que ilustra los roles primarios y a continuación explicamos cada uno de los roles.
Si nos centramos en los roles primarios (hemos decidido no traducirlos a español), podemos ver los siguientes:
- Los Stakeholders son las personas que de una forma u otra tienen relación con el producto o solución, esto no es nada nuevo ya que los stakeholders los hemos visto en muchas ocasiones en agilidad en diferentes posts del blog.
- El Product Owner es la persona que hace de unión entre los stakeholders y el equipo, esto tampoco es nuevo, sabemos que tiene que estar en estrecha colaboración con el equipo y con los stakeholders para eliminar la documentación, o para resolver las dudas del equipo, entre otras responsabilidades. Es importante saber que cada equipo tiene un solo Product Owner. Aunque en principio el Product Owner se adopta de Scrum, se diferencia de este porque en DAD tiene que priorizar todos los elementos, no solo las necesidades, también hay que priorizar los elementos por ejemplo de eliminar desperdicio, o valorar el trabajo de otro equipo. Hay que tener cuidado para que el Product Owner no se convierta en un cuello de botella, y es importante saber que no debería ser el Architecture Owner, ni el Team Leader. Aquí puedes ver más información sobre el Product Owner.
- Team Member aunque en agilidad a los miembros del equipo se les suele denominar desarrolladores, en DAD cambia este concepto, ya que los miembros del equipo hacen las pruebas, el análisis, el diseño, la planificación y muchas cosas más. El equipo tiene que ser auto-organizado y colaborativo:
– “Overspecialization”, es decir, que debe tener un conocimiento general en otras áreas del desarrollo software no solo en su especialidad.
– Colaborativos, el ambiente de trabajo debe ser colaborativo.
- Team Lead es un Servant Leader, es decir, es el sirviente del equipo, creando y manteniendo las condiciones que permiten al equipo tener éxito (puedes leer más del Servant Leader en el post Servant Leadership vs Host Leadership). Además un Team Lead tiene que ser un agile coach, ya os hablamos este verano del Coaching en el post Coaching: Todo lo que necesitas saber del Coach, en DAD el Tema Leader como agile coach ayuda a mantener al equipo centrado en la entrega de trabajo y en cumplir el objetivo de la iteración, además elimina cualquier impedimento para el equipo esto es igual que el Scrum Master en Scrum. Esta persona no debería ser Product Owner.
- Architecture Owner está estrechamente relacionado con el riesgo del proyecto, es el encargado de que el equipo mitigue el riesgo, además facilita la creación y evolución del diseño de la solución global. Puede que no sea necesario tener una persona que adquiera este rol en equipos pequeños y puede que este rol lo adquiera la misma persona que tiene el rol de Team Lead. Una de las cosas importantes es que la persona que tenga el rol debe tener un conocimiento técnico y una buena comprensión de la parte de negocio.
Terminando…
Hemos querido dividir el post en dos partes para que no se hiciera muy largo y poder entrar más en detalle en cada uno de los roles.
En el post de la semana que viene hablaremos de los roles secundarios y de la transición de los roles tradicionales hacia los nuevos roles de DAD.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023