Mensaje contradictorio
Las dos caras de la moneda: «Por favor, equipo scrum: mejorad el sistema, mejorad el producto, mejorad el código» y el mismo día en otra reunión escuchas «Pero que no tenemos tiempo para mejoras. Llegamos tarde a los hitos de todos estos proyectos y no podemos estar dedicando tanto a la calidad de código o a rehacer partes para que sean más mantenibles. Ya lo haremos más adelante«. Pero ese «más adelante» jamás llega. ¿Te suena esta situación?
Como Scrum Master, frente a estas situaciones quiero ayudar a ambas partes. Digamos que entiendo las necesidades que existen a un lado y otro «del muro» (en otro momento escribiré sobre esa pared de ladrillo que existe entre management y desarrollo). Por un lado, quiero apoyar al equipo para que parte del tiempo de cada sprint se dedique a mejoras que aporten el máximo beneficio (y no especialmente al corto plazo, sino al medio plazo y sobre todo al largo plazo – aunque éstas últimas sean las más difíciles de justificar frente a management). Es una realidad que cuesta ver: hay que dejar tiempo y espacio al equipo para que puedan crear, mejorar, innovar. Por otro lado quiero ayudar a management (jefes de proyecto, jefes de unidad) para poder cumplir con las necesidades de negocio pero de una forma sostenible (¡ajá! aquí está el quid de la cuestión 😄). ¿Cómo cumplir con las dos?
El punto de vista de management
Dejemos a un lado la parte de management, porque empatizando con ellos es obvio que no podemos parar de repente de producir funcionalidad para mejorar «cosas» de dudosa justificación para ellos. Simplemente eso no podemos hacerlo y punto. Por ello, hay conversaciones en las que es preferible no perder energía (sinceramente y a título personal, aún estoy aprendiendo a controlar esto… No es tan fácil… jajaja). A menos que sea una mejora grande, con mucho impacto, muy concreta y que podamos justificarla con números objetivos, no tiene sentido quejarnos de que nunca tenemos tiempo para mejorar. Centrémonos en qué podemos hacer nosotros desde otro enfoque (je-je-je).
¿Y qué hacemos?
Existen unos momentos muy buenos de reflexión llamados retrospectivas donde el equipo tiene un rato que todo el mundo (IT + management) entiende como sagrado y respeta -es lo que más me gusta, la verdad-, para analizar cómo ha trabajado en un período de tiempo. Por ejemplo, qué ha hecho bien y es bueno ser consciente de ello para seguir haciéndolo. O qué podría haber hecho mejor para aprender de ello y corregirlo de aquí en adelante. En estos ratos de confianza me gusta explicitar qué tipo de trabajo hemos «producido». Digamos, que analizar el valor de lo generado es algo potente si lo que quieres es maximizarlo:
X horas dedicadas a historias de usuario Y horas dedicadas a resolver bugs Z horas dedicadas a interrupciones N horas dedicadas a mejoras u otras tareas -------------------------------------------------- M horas totales trabajadas del sprint
Con este reparto podemos ver a qué hemos dedicado el tiempo y si esa dedicación es la que queremos tener o no. Si sprint tras sprint nos vamos dando cuenta que las horas de mejoras son CERO, quizás haya algo que podamos hacer. Lo principal para producir un cambio es hacer visible lo invisible, hacer explícito lo que no se ve. Tras ver esto, a lo mejor el equipo puede establecer una regla. Por ejemplo, añadir una tarea de mejora en cada sprint, o dos tareas, o un time-box controlado… Hasta que consiga algo (con un mini roadmap de lo que quiera conseguir u objetivo, por ayudar a focalizar). Ese poquito dedicado sprint a sprint realmente no perjudicará a negocio directamente, y quizás siente las bases de una cultura diferente. Una cultura basada más en la importancia y no tanto en la urgencia.
La cultura de la sostenibilidad
Además, existe una buena filosofía en Scrum, Extreme Programming, etc. Consiste en dedicar un 80% del tiempo efectivo del sprint a producir valor tangible en el corto plazo y un 20% del tiempo del sprint a mejorar el sistema. Éste último no visible al corto plazo, pero necesario al medio-largo. Si te gusta cómo se expresa en la guía Scrum…
To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.
– Scrum Guide
Esta forma de trabajar va alineada con la «mejora continua» y con «cultura devOps» que tanto está en boca de todos en este gremio.
Por tanto, para que el equipo tenga ese tiempo y espacio de mejora e innovación quizás la forma sea empezar poquito a poquito. Se puede ir introduciendo «una unidad de mejora» en cada sprint e ir viendo el avance. Pero al mismo tiempo hay que dar salida a las features que negocio sigue pidiendo (veremos si a la velocidad que demandan, porque eso es carne de otro artículo). Y aquí, el trabajo más duro será convencer a ese jefe tradicional, disfrazado de Product Owner, para hacer hueco explícito en el sprint backlog. ¡Ánimo!