Hoy compartiré las observaciones del Scrum Master sobre el primer año de vida del equipo en el nuevo marco.
¿Por qué decidimos ir a Scrum? Las razones son comunes para muchas empresas:
- la relación no tan simple entre "negocios" y "desarrollo";
- la necesidad de agilizar las entregas;
- entendiendo que es necesario reconstruir los procesos.
El cambio a Kick-Off nos llevó unos seis meses (desde principios de 2019): estudiar, capacitar, preparar materiales y recopilar la información necesaria. Y finalmente,
el 3 de junio de 2019, comenzamos el primer sprint.
El primer año en el nuevo marco es un desafío tanto para el equipo como para el Scrum Master. Es necesario cambiar radicalmente la mentalidad y empezar a hacer las cosas de otra manera.
¿Qué debe recordar un Scrum Master durante este período?
El Scrum Master no es un zapato, no tiene por qué ser cómodo. Es necesario desarrollar una habilidad sostenible para reflejar al equipo y a sus miembros individuales de patrones de comportamiento poco saludables. Es muy importante aprender a dar retroalimentación de manera correcta y oportuna, incluso si esto sacará tanto al Scrum Master como al oponente de la zona de confort.
Piense en términos de equipo, no de individuos. Debe ver al equipo como un organismo vivo y recordar que si "los órganos individuales se enferman", entonces todo el organismo puede comenzar a deprimirse. Para continuar con la analogía, el Scrum Master es un terapeuta. No es un cirujano, sino un terapeuta, por lo que los casos clínicos difíciles se derivan a otros especialistas.
Scrum, como LeSS, no tolera la inmadurez personal de los miembros del equipo. Si el equipo no sabe qué es Scrum, nunca ha trabajado en este marco y, además, si ya ha funcionado en la composición actual, recomendaría abstenerse de voltear en LeSS de inmediato.
La identificación de voluntarios para el Kick-off (que generalmente toma tres días) dentro de un equipo que no ha trabajado anteriormente en Scrum es más probable que sea falsa. Si las personas no han trabajado en este marco antes, difícilmente entienden realmente qué es y realmente pueden hablar sobre su voluntad de trabajar de esta manera.
Hardy no es todo. Si hay un problema con el software, incluso un desarrollador que sea muy bueno en términos de dureza puede convertirse en un gran problema.
En equipos autoorganizados, las personas con una reflexión desarrollada, inteligencia emocional y un deseo de autodesarrollo continuo, expansión de conciencia y voluntad de cambiar el paradigma pueden vivir y existir en armonía.
Sería ingenuo creer que eres el más inteligente. Es muy importante transmitir este mensaje a todos los miembros del equipo. La penetración en esta mentalidad más simple da lugar a muchas ventajas en lugar de desventajas: desde el respeto mutuo hasta el “sentimiento de estar juntos”.
La parte más difícil es trabajar con responsabilidad. Es importante que las personas comprendan que la "voluntariedad" no se trata solo de la voluntad y la voluntad de trabajar en Scrum. Se trata de la disposición a desarrollarse, a crecer por encima de uno mismo, a aprender a dar y recibir retroalimentación, a reflexionar y hacer cambios. Se trata del proceso continuo de mejorar no solo los procesos, sino también a nosotros mismos.
La gente a menudo no entiende por qué se necesita un Scrum Master. Y aquí, después de muchos diálogos y talleres, discusiones y conversaciones diferentes, llegué a la conclusión de que este malentendido a menudo se debe a una falta de disposición para comprenderlo. El Scrum Master debe tener esto en cuenta y seguir trabajando en ello.
¿Qué nos dio Scrum en un año?
“Negocios” y “desarrollo” se volvieron inseparables: la comprensión de “nosotros” y “ellos” dejó de existir. Los expertos en negocios trabajan junto con los desarrolladores en los mismos equipos. Ahora, la comprensión de lo que necesita una empresa vive dentro de los equipos de desarrollo. Como resultado, hemos mejorado significativamente la velocidad de entrega: ahora los lanzamientos ocurren una vez por sprint. Actualmente estamos viviendo en sprints de tres semanas. Anteriormente, la tasa de publicación real no era más de una vez cada mes y medio.
Hemos legalizado la deuda técnica y empezamos a hacer tiempo para ella en los sprints. Acordamos la proporción del 70% frente al 30%, donde el 30% se asignó a la deuda técnica.
En un año, pudimos incorporar todas las competencias críticas al equipo, abandonamos a los proveedores e internalizamos el desarrollo. La influencia de cada uno en los resultados del desarrollo y en las soluciones implementadas se ha incrementado significativamente. La inmersión de los desarrolladores en el producto y en el contexto del cliente ha aumentado significativamente. En consecuencia, la carga semántica "¿Por qué?" Ha cambiado cualitativamente.
Lanzamos el proceso Discovery: aumentamos significativamente la inmersión en la "piel del cliente". Ahora todas nuestras ideas, en cuanto a lo que nos parece que el cliente sería útil, las comprobamos directamente con los clientes. Creó un ambiente listo para experimentar y una cultura de voluntad para experimentar.
Implementado CI / CD.
Cubrimos prácticamente toda la funcionalidad de la aplicación WEB con autotests, lo que redujo significativamente el tiempo y los costos laborales de la regresión manual.
Hemos comenzado la transición a una arquitectura de microservicio, que debería agregar más independencia a los equipos de desarrollo.
Hemos introducido un sistema para monitorear aplicaciones y hardware: ahora en modo en línea es posible monitorear el estado de uno y otro y, a veces, recibir señales antes de que salgan las llamadas de los clientes. Hemos creado una serie de paneles para monitorear los indicadores comerciales, incluidos los KPI en modo automático.
Durante el año logramos hacer mucho, pero nuestro camino aún continúa.
PD: Deliberadamente no escribí sobre las etapas de implementación de Scrum. Puedes leer mucho sobre esto ahora. Si está interesado, puedo escribir un artículo aparte.