El comienzo de esta historia parte de un equipo nuevo de cuatro personas sin experiencia en Scrum dentro de una organización que trabaja en modo tradicional. Acompáñame para seguir los cambios de opinión que he ido teniendo al tratar el dilema de estimar.
Mi primera propuesta fue la de estimar usando los puntos de historia. Descarté los métodos de “estimar en horas” por ser ineficaz y con tendencia a meter colchones ocultos y “estimar en tallas” por ser poco útil (en mi experiencia todo se convierte en M y alguna S y XL).
Pero algo no me terminaba de encajar. Me daba la sensación de que para este equipo novato en Scrum le estaba dando de golpe demasiada información. El paso de waterfall a Scrum es o puede ser muy brusco, y en mi caso me parece que eso provoca que el equipo no tenga claro cuál es para mi la esencia de un Sprint y en el fondo de Scrum: generar un incremento de software con valor potencialmente liberable.
Además, la organización, llena de ANS o SLA, está encantada de que usemos puntos de historia para obligar a los equipos a que 1 punto de historia sea X horas para todos los equipos y así poder establecer las penalizaciones por contrato para cada HU. Sí, todo muy en línea con el cuarto valor del manifiesto Agile.
Tabla de contenido
Movimiento #noestimates
Impulsivamente dije, “esto de la estimación es un desperdicio lean seguro, si tan empíricos somos, no entiendo para qué estimamos”. Y me vino a la mente un movimiento que se llamaba #noestimates, así que me puse a investigar a ver en qué consistía y si me aplicaba. Revisé este post de Jero (típico old but gold), de ahí fui al whitepaper original, a la web propia de referencia http://noestimates.org/blog/ y al grandísimo artículo de Ron Jeffries sobre el movimiento. Luego me vi (y lo recomiendo) un video de una entrevista al propio Vasco Duarte creador del movimiento.
En este punto ya tenía una idea bastante clara de qué era el movimiento #noestimates; y fue ahí cuando reconocí que no me convenció. Si bien es cierto que es interesante el concepto de no estimar los PBIS y basar tu predictibilidad en un cálculo de cycle time, lead time y throughput siguiendo la lógica que nos dá una curva normal. Incluso me gusta que se pueden aplicar los principios de Lean Six Sigma como os contaré en un próximo artículo.
Pero todo esto se basa en que los PBIS sean muy parecidos sino iguales, y eso es algo que en mi caso por lo menos era directamente irreal. De hecho, dada la complejidad del desarrollo de software me resulta difícil ver/entender cómo un PO puede ser capaz de dividir (el famoso slice) los PBIS para que tengan el mismo tamaño. Además tener en cuenta que en Scrum nunca había medido cycle/lead time, por tanto, es una nueva tarea que se agrega. Recopilar, mantener y publicar esos datos; tarea que si somos justos es igual de desperdicio que la estimación.
Esto no acaba aquí
Y aquí es cuando me dí cuenta de que mi trabajo tenía que ser enseñar o ayudar a la organización a que use adecuadamente y entienda para qué valen las estimaciones. Para esto, lo que hice, y os contaré en el siguiente artículo, es intentar ir a la fuente de la información y realizar las famosas 5 preguntas Porqué?
Comentarios recientes