En una reunión de retrospectiva, un desarrollador escribe en un post-it que nunca terminan los puntos que han dicho en el sprint. Explica que esta frustrado, que trabajan sin descanso cada sprint, hacen horas extra y que aún así no llegan y nunca entregan nada. La única solución posible es alargar el sprint al doble de lo que dura ahora.
En una revisión con un stakeholder, un product manager explica que no van a poder hacer los ajustes para la campaña que se lanza la semana siguiente porque el sprint ya ha empezado. Hay que esperar al siguiente. Recientemente han alargado los sprints así que eso significa que lo empezarán a hacer en cuatro semanas.
En una design critique un diseñador presenta un diseño y recibe feedback muy positivo. Lo testa con usuarios y también parece funcionar. Sin embargo no lo podrán desarrollar hasta que incorpore a los diseños todos los casos que se pueden dar y las pantallas para ordenador de sobremesa, tablet y móvil.
En la última retrospectiva alargaron los sprints, así que ahora es muy importante que además de los diseños complete las secciones correspondientes en el PRD (Product requirements document). De esta forma, los desarrolladores pueden trabajar esas cuatro semanas de forma autónoma.
En 2001 se publicó Manifesto for Agile Software Development y 20 años después aún muchas discusiones van sobre product owners, sprints y documentación. Algunas de las quejas que se pueden escuchar en casi cualquier equipo se parecen a:
Cada equipo tendrá sus propias versiones. Parafraseando a Tolstoi, todos las equipos felices se parecen unos a otros pero cada equipo infeliz lo es a su manera.
Esto sucede en buena medida porque el manifiesto agile no habla de formas concretas para construir software, sino de unos principios generales:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Los principios parecen claros y cualquiera esta de acuerdo en que hay más valor en la parte izquierda que la parte derecha, pero el día a día lo define cómo ejecutamos la parte derecha.
En Streamloots nos consideramos un equipo de producto y tecnología feliz y muchas de las dinámicas que tenemos se parecen a las que traemos de otros equipos también felices -en el equipo se combinan experiencias de sitios como Invision, Rakuten, Visa, Microsoft, La Nevera Roja y Ontruck-.
Tenemos 5 básicos -como dice el título del artículo- que nos ayudan en la ejecución: