No obtener el rendimiento esperado de Scrum puede venir de su desconocimiento. Esperar que Kanban solucione todas estas carencias puede deberse al mismo desconocimiento sobre Kanban.
Recientemente conocí a una startup con cuatro equipos de desarrollo que estaba dudando si debía pasar de scrum a KANBAN. Escribo «scrum» en minúsculas porque según ellos Scrum les aportaba posiblemente más restricciones que ventajas, mientras que veían en «KANBAN» una solución ideal a todas sus necesidades. Concretamente planteaban como problemas de Scrum:
- El Product Owner no puede impulsar sus prioridades en las planificaciones de los sprints debido a dependencias técnicas expresadas por el equipo.
- Los eventos se percibían como un desperdicio de tiempo por algunos miembros de los equipos.
- Y el más importante: los Sprints de Scrum no permitían dar respuesta a cambios repentinos que requería su producto en la nube.
Según ellos, pensaban que Kanban les podía aportar las siguientes ventajas respecto a Scrum:
- Menos tiempo dedicado a reuniones.
- Mayor flexiblidad para responder a cambios urgentes requeridos por el mercado.
Al escucharles me pareció un caso interesante, por un lado era una empresa con bastante proyección y un muy buen nivel técnico, y por el otro, es un caso bastante representativo de las dudas que hacen escoger entre la falsa dicotomía de Scrum o Kanban.
Contenidos del artículo
La diferencia entre scrum y Scrum
En primer lugar, es importante tener claro que es kanban y sus diferentes enfoques:
- kanban (en minúsculas) es un sistema de gestión del proceso basado en tarjetas, que se mueven cuando un estado siguiente del proceso se queda sin trabajo (pull system).
- Un sistema kanban está diseñado para hacer seguimiento del trabajo y optimizar el flujo. Suele constar de un tablero, las tarjetas y las políticas que restringen como operar el tablero.
- El método Kanban es un sistema Kanban bastante popular ideado por David J. Anderson.
Sin embargo, Scrum es un marco de trabajo (framework) y por tanto no se pueden comparar con dichas distinciones. A título individual distingo entre «scrum», como una aplicación subóptima del marco de trabajo debido a diferentes factores habituales, y «Scrum» como un conocimiento y aplicación óptima del marco para maximizar el valor generado en el producto y mejorar contínuamente la efectividad del trabajo de los equipos.
En el caso de esta empresa, al preguntarles reconocieron que habían ciertos de estos antipatrones habituales que se daban en su caso:
- No disponían de un Scrum Master a tiempo completo y profesionalizado.
- La planificación y seguimiento de los sprints se orienta a cantidad (número de historias de usuario y velocidad) por encima de impacto (valor del producto generado).
- El Sprint se usa como un escudo para defender al equipo de las «ingerencias» externas.
Si no se cuenta con un Scrum Master a tiempo completo, suele ser habitual que el conocimiento del marco de trabajo y partido que se obtenga de su uso queden frenados y no mejoren a lo largo del tiempo, fenómeno conocido como Scrum Zombie. Por contra, si se impulsa un conocimiento profundo de la meta de los componentes y reglas de Scrum a todos los miembros del equipo, se irá mejorando su aplicación y la efectividad obtenida. Scrum más que un método se convierte en una herramienta de pensamiento conjunto.
Revisando los problemas percibidos según una visión sólida de Scrum
El primer problema era una inflexibilidad percibida en el Sprint Planning por el Product Owner para priorizar sus necesidades en el Sprint. Una de las carencias identificadas era el enfoque de esta reunión a «rellenar de historias» el backlog del Sprint, en vez de centrarse en consensuar primero la Meta del Sprint y planificar después aquellos ítems del Backlog (PBI) que iban a contribuir a dicha meta. Este segundo enfoque de la reunión debería facilitar una discusión más rica y no tan productiva del alcance del Sprint que facilitara al Product Owner enfocar el resultado del Sprint a sus objetivos. Además, la Guía de Scrum tampoco obliga a «rellenar» toda la capacidad del Sprint, hecho que discutiremos en el problema de la flexibilidad del Sprint.
Por otro lado, no siempre se utilizaban los refinamientos previos al Sprint para identificar y optimizar las dependencias técnicas, de manera que dejaran mayor margen de acción al planificar el Sprint. Esta es la función del refinamiento conjunto entre equipos que prescribe el marco de trabajo Nexus de Scrum.org. Refinando conjuntamente entre los Equipos de Desarrollo y el Product Owner, se podrían minimizar las dependencias y pensar como prepara el Backlog de Producto para optimizar las Metas de los siguientes Sprints.
El segundo problema consistía en que no se percibía el valor de los eventos. Además de la falta de guía que proporcionaría un Scrum Master profesional, otros hallazgos que pudimos ver al hablar con esta startup fueron, p.e.:
- Del Sprint Planning ya hemos hablado en los párrafos anteriores. No tienen el mismo valor y generan la misma motivación una planificación mecánica orientada de historias de usuario, que una planificación más creativa orientada a optimizar la Meta del Sprint.
- Respecto al Scrum Diario, un Sprint Backlog predictivo y orientado a la realización mecánica de historias no es tan motivador de seguir como otro Sprint Backlog basado en la optimización de una meta del Sprint.
- Una Revisión del Sprint basada en revisar historias no es tan motivadora como una que revise la consecución, o no, de una meta. Además, la variabilidad externa al Sprint (cambios súbitos que requería las dependencias de Redes Sociales del negocio de esta startup) hacía que muchas Revisiones fueran decepcionantes, por obtener un incremento muy diferente del planificado.
- Y una Retrospectiva del Sprint, no facilitada por un Scrum Master que además tenga como único objetivo, en paralelo al Sprint, la mejora continua del equipo, procesos y personas, suele ser bastante más pobre.
El tercer problema consistía en la falta de flexibilidad que imponía el Sprint, según esta empresa, y que dificultaba la adaptación de eventos imprevistos al que debían hacer frente de manera prioritaria, especialmente cambios en redes sociales con las cuales trabajan. Como se decía al hablar del primer problema, si tratamos al Sprint simplemente como un contenedor de tiempo en el cual realizar historias y además pretendemos rellenarlo al máximo, es normal que cualquier imprevisto pueda parecer un serio problema que obligue a cancelar el Sprint, o bien a entregar su alcance inicial muy mermado, sin un aparente control.
Si revisamos cuidadosamente la Guía de Scrum, se dice textualmente (lo pongo en inglés porque la traducción al castellano es muy mala) lo siguiente:
- No changes are made that would endanger the Sprint Goal;
- Quality goals do not decrease; and,
- Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
De esto se deduce claramente que se pueden introducir cambios al Backlog del Sprint siempre y cuando no hagan peligrar la consecución de la meta del Sprint. Por lo tanto, si la Meta del Sprint no es tan ambiciosa que responder a cualquier imprevisto pueda ponerla en peligro, se facilita la realización de cambios al Backlog del Sprint tanto si los identifica el equipo como el Product Owner.
Así pues, como conclusión de los tres inconvenientes presentados sobre Scrum, una correcta interpretación de Scrum los minimiza o elimina por completo.
Los supuestos beneficios de Kanban sobre Scrum
Tras revisar como una correcta interpretación de Scrum minimiza los problemas percibidos, se puede preveer como las expectativas de mejoras de Kanban sobre Scrum no se vayan a cumplir probablemente.
El primer supuesto beneficio era la disminución del tiempo dedicado a reuniones. Con Kanban pasa algo similar a Scrum, muchos equipos implementan solo lo que conocen o lo que creen viable, y se dejan lo demás. A esto se le llama proto-kanban, y aunque es muy sencillo comenzar, no le busquemos lógicamente los beneficios de implementan un sistema kanban completo. El método Kanban sugiere hasta 7 cadencias de feedback, que requieren hasta otras tantas reuniones. No es que se tengan que hacer todas en cualquier contexto, ni hacerlas desde el principio, pero es bueno conocer que existen y que podrían tener que hacerse. Éstas son:
- Replenishment Meeting
- Daily Kanban
- Service Delivery meeting
- Delivery Planning meeting
- Strategy Review
- Operations Review
- Risk Review
Así pues, no de verifica que existan menos reuniones o que vaya menos gente.
Además, el uso sólido de Kanban es muy exigente con el orden de los cambios introducidos, con lo cual tampoco iba a ofrecer la flexibildad imaginaria que pueden cambiarse las cosas a medio Sprint sin las restricciones técnicas, de dependencias y de capacidad del equipo. De hecho, la utilización de Kanban todavía hace más evidentes estas restricciones.
El segundo supuesto beneficio era la mayor flexibilidad para responder a cambios. Si bien Kanban proporciona un excelente método para trabajar eficientemente según prioridades cambiantes, su uso aparte de las prácticas de Scrum puede hacer perder el foco del desarrollo a medio y largo plazo. Además, se puede incluir perfectamente un sistema Kanban dentro del Sprint, de hecho muchos equipos lo hacen al madurar. En el curso Professional Scrum con Kanban (PSK) de Scrum.org enseñamos como obtener lo mejor de Kanban y Scrum.
Conclusión
Como hemos visto, no conocer profundamente Scrum y Kanban puede tener dos consecuencias:
- No obtener el beneficio de Scrum y encontrarle inconvenientes que pueden minimizarse.
- Exagerar las expectativas de Kanban y desconocer sus posibles riesgos.
