Cuando estés ayudando a algún equipo Ágil, prueba con la siguiente pregunta, o investiga por tu cuenta su respuesta, yo es una de las típicas que uso desde hace años.
La, aparentemente simple, pregunta de… ¿en qué estado debe terminar aquello (ese producto, solución, incremento en terminología Scrum, etc.) que estamos creando en un ciclo de vida iterativo e incremental ágil? ¿qué es lo que esperamos, o sería deseable, tener al final de los Sprints (o durante el Sprint)?
Por empezar por el principio, en el viejo (y podría incluso decir que olvidado) Manifiesto Ágil, aquel que define los valores, y principios, de una cultura Ágil, venía, entre los principios, lo siguiente: «Working software is the primary measure of progress».
Lo anterior se podría traducir a algo así como que la principal medida del progreso es el «working software», que podríamos traducir por software operativo (mejor que software funcionando). Que, para aquellos que hoy no usan Agilidad en desarrollo software hay quien cambió lo de «working software» por «working solutions».
I think @henrikkniberg finally found the words we were looking for to take the manifesto away from software pic.twitter.com/F1ROgCEiy7
— Alistair Cockburn (@TotherAlistair) 26 de septiembre de 2018
Dicho esto, parece más que razonable que en un Sprint o iteración se planifique hacer «cosas» que creen «working software» o incrementen el «working software» con más «working software».
Dicho así, dicho lo anterior, pues caba a n-mil interpretaciones y a que el Lado Oscuro campe a sus anchas.
Sin alargar la coletilla de que hay también n-mil maneras de ser Ágil, que esto son valores y principios, Shu-Ha-Ri, de que innoves, de que no hay dos agilidades iguales, etc., a mí, aún así, personalmente, hay cosas que, simplemente, me huelen mal y otras que me huelen bien, cuando alguien me enseña su Backlog de Sprint y yo pienso en «working software».
Huele a que habrá «más working software» al final de la iteración si lo que pretendemos hacer, es funcional, y eso, entre otras, implica que alguien pensó en el actor de esa funcionalidad, ese que muchas veces, de manera simplista y genérica, muchos llaman «usuario».
Huele a que habrá «más working software» si lo que pensamos hacer, al final del Sprint (o durante), se puede enseñar, se puede hacer demo.
Huele a que habrá «más working software» y o que queremos hacer es «end – to – end» en vez de partes sueltas que no aportan algo operativo a ese actor.
Huele a que habrá «más working software» si esperamos dejar lo que se cree en un entorno operativo, como es producción o, en su defecto, pre-produccción.
Otras cosas, como hacer papel, estudios, Spikes, validciones, etc., no huelen a que habrá «más working software»
Este post viene inspirado por una conversación, que resumí en la foto de instagram que te dejé al principio del post. Que la Agilidad te acompañe.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024