Veremos cómo en Scrum se trata de entregar valor en equipo, no se trata de otra cosa.
Porque todos pueden hacer su parte correctamente, pero el paciente aún puede morir en la mesa de operaciones si el equipo no mira la imagen completa.
Lo sé que lo sé. Estamos hablando de un equipo Scrum, no de un equipo médico. Pero siga mi metáfora y piense en el paciente como el Incremento y Desarrollo como el equipo médico.
Para asegurarnos de que todos usamos el mismo vocabulario, estas son algunas de las definiciones que usaré:
- Equipo Scrum: Product Owner, Scrum Master y el equipo de desarrollo.
- Equipo de Desarrollo: los miembros del Equipo Scrum que desarrollan el Incremento.
- Incremento: La suma de todo el trabajo desarrollado por el Equipo de Desarrollo durante el Sprint. El Incremento es un paso hacia una visión u objetivo.
- Sprint: un cuadro de tiempo durante el cual se crea un Incremento “Listo”, utilizable y potencialmente liberable.
- Meta de Sprint: un objetivo que se alcanzará dentro de Sprint a través de la implementación de la cartera de pedidos del producto, y guía al Equipo de Desarrollo sobre por qué está construyendo el Incremento.
Una de las cosas más importantes que muestran si Scrum se implementa de manera efectiva en una organización es la forma en que el Equipo de Desarrollo observa el Incremento y su papel en la entrega.
No hay roles individuales en el Equipo de Desarrollo en Scrum, como se establece claramente en la guía Scrum:
- Scrum no reconoce títulos para los miembros del Equipo de Desarrollo, independientemente del trabajo que realiza la persona;
- Scrum no reconoce sub-equipos en el equipo de desarrollo, independientemente de los dominios que deben abordarse como pruebas, arquitectura, operaciones o análisis de negocios; y,
- Los miembros del Equipo de Desarrollo Individual pueden tener habilidades especializadas y áreas de enfoque, pero la responsabilidad pertenece al Equipo de Desarrollo en su conjunto.
¿Por qué es tan importante que el equipo de desarrollo lo entienda? ¿Por qué no pueden centrarse simplemente en lograr su pequeña parte del trabajo que debe hacerse?
Bueno, echemos un vistazo a los eventos y artefactos de Sprint y analicemos lo que significa la falta de roles individuales en el Equipo de Desarrollo.
La planificación de Sprint se realiza en equipo
Es el Equipo de Desarrollo el que se compromete a construir el Incremento. No individuos solteros o solitarios.
Si no todos creen que el Incremento y el Objetivo Sprint son alcanzables, es hora de inspeccionar y posiblemente adaptarse al comienzo del Sprint. Intenta descubrir por qué ese es el caso.
¿Es porque algunos miembros del equipo sienten que tienen una gran parte del Incremento en su plato? ¿O no está claro el trabajo y la visión sobre el Incremento de los demás en el equipo?
Preferiblemente, estas preguntas que desea haber respondido como equipo Scrum antes de comenzar su trabajo. Al planificar en equipo, también ayuda a demostrar cuál es el papel de los miembros del equipo en relación con el panorama general de la empresa, lo que ayuda con la motivación.
Riesgo si la planificación de Sprint se realiza como individuos: si la planificación de Sprint no se realiza como un equipo, conduce a situaciones en las que algunos miembros del equipo terminan temprano con “su” parte del Incremento y pasan a nuevas tareas antes de que se alcance el Objetivo de Sprint logrado, lo que a su vez conduce a objetivos de Sprint no alcanzados y menos valor para el cliente.
También conducirá a una menor aceptación de la planificación, ya que las personas estarán de acuerdo con las tareas que tienen que cumplir, aunque no necesariamente estarán de acuerdo con el trabajo de otros miembros del equipo.
La Daily Scrum se hace como equipo
El Daily Scrum es un momento para que el Equipo de Desarrollo planifique las próximas 24 horas y el check-in, si todavía estamos en camino de alcanzar el Objetivo Sprint.
Si se hace bien y como equipo, el Daily Scrum le dirá al equipo si todavía están en camino o si deben hacer ajustes para lograr el Objetivo Sprint. No se trata de resumir lo que usted como individuo hizo o no hizo.
Es el momento de compartir con el equipo cómo fueron las últimas 24 horas y las próximas 24 horas para que el equipo sepa cuándo surgen nuevas situaciones. Así que concéntrate en el objetivo de Sprint como un todo y no en tareas pequeñas.
Riesgo si el Daily Scrum se realiza como individuos: Desmotivación sobre el Daily Scrum, son los momentos en que alguien dice que tuvo “reuniones” o que revisó una lista de tareas, sin mencionar los aprendizajes o los objetivos de esas reuniones.
El Daily Scrum trata sobre el Equipo de Desarrollo que inspecciona el plan para lograr el Objetivo Sprint, y la simple mención de una reunión no ayuda a alcanzar ese objetivo.
Esos son ejemplos de alguien haciendo el standup como individuo, marcando una casilla sin pensar por qué ocurre el Daily Scrum o cómo pueden contribuir y ayudar a otros en el equipo con la planificación de 24 horas.
La Sprint Review se hace como equipo
Una parte de la Revisión de Sprint es la demostración de Sprint. Algunos equipos de desarrollo tienen dificultades para demostrar su trabajo, dependiendo del tipo de especialidad que tengan.
Los back-end generalmente tienen menos trabajo visual para mostrar que los front-end. Pero no importa quién haga el back-end de la interfaz. Los miembros del equipo también pueden hacer demostraciones de trabajo entre ellos.
Muestre el valor entregado como equipo hacia el Incremento y cambie el rol de demostrador. Debido a que el trabajo se realizó en equipo, no debería importar mucho quién demuestre el trabajo.
Riesgo si la Revisión de Sprint se realiza como individuos: los miembros del Equipo de Desarrollo muestran su trabajo y no mencionan el panorama general.
Hablan sobre las características y piensan que la mitad de la funcionalidad de trabajo está hecha, ya que completaron su parte y un miembro diferente del equipo necesita terminar el resto.
Pero, no importa si un miembro del equipo ha realizado todas sus tareas. Si no hay valor para el cliente para entregar, no se hace nada. El paciente habrá muerto. No podemos llegar a entregar valor en equipo si no lanzamos nada para cliente.
La Sprint Retrospective se hace como equipo
Durante la Retrospectiva de Sprint, es el equipo el que analiza su trabajo en su conjunto. Se trata de inspeccionar cómo el equipo puede trabajar de manera más efectiva. Es un momento para aprender en equipo.
Señales de que las retrospectivas de Sprint se realizan de forma individual: los miembros del equipo no reciben comentarios si no se relacionó directamente con ellos personalmente.
De este modo, no se identifica con el problema como propio. Incluso si el aporte no los afecta personalmente, sí afecta al equipo del que forman parte y, por lo tanto, debería ser el propietario. Esto evitará que el equipo aprenda y se adapte, deteniendo su crecimiento.
Sin crecimiento personal y profesional, no hay posibilidad de entregar valor en equipo ni de ninguna manera.
En resumen
El equipo de desarrollo tiene mucha responsabilidad, y puede ser un desafío vigilar el panorama general cuando se trabaja como miembro de ese equipo.
Pero dado que Scrum tiene como objetivo ofrecer valor, y no se trata de marcar casillas, lo más importante es lo que importa. Y eso solo se puede lograr entendiendo que, como miembro del Equipo de Desarrollo, su contribución individual no es lo que cuenta.
Es el Incremento entregado como un equipo único de desarrollo es lo que cuenta. En Scrum se trata de entregar valor en equipo, no se trata de otra cosa, ya sea resolver problemas complejos o lanzar productos al mercado.
Al fin y al cabo, es demostrar como hacer Professional Scrum de la siguiente manera:
Y si tenemos esto en cuenta en un entorno médico, el paciente puede vivir para ver otro día …
Pingback: Cómo Scrum ayuda a la industria cafetera colombiana - Agile611