Scrum y XP desde las trincheras, mis notas del libro

El fin se semana pasado termine de releer la segunda edición de este ya clásico libro de Henrik Kniberg. Fue muy refrescante leer en él los pensamientos del autor desde una mirada critica de su propio trabajo plasmado en la primera edición.

Voy resumiendo algunas impresiones que se me quedaron del libro :

  • El product backlog no es descubierto de manera solitaria por el Product Owner sino que debe venir de una activad grupal con stakeholders y/o developers. Técnicas como User Story Mapping resultan muy útiles para este fin.
  • Las historias de un backlog deben ser pensadas desde la perspectiva de cómo serán presentadas en un Sprint Review, el resultado de esa definición es el que puede (y de hecho debe) ser programado a través de criterios de aceptación automatizados .
  • El uso de Google Spreadsheets para mantener el Product Backlog es una alternativa válida que no solamente abarata y simplifica el juego de herramientas sino que también ofrece gran flexibilidad para moldear la herramienta al proceso evolutivo del equipo y no a la inversa.
  • El Sprint Retrospective es el evento más importante de Scrum pues es de hecho el único que permite inspeccionar la forma de trabajo del equipo en su conjunto e irla mejorando. Dejo para otro post la noción de que el Sprint Retrospective es un evento meta-circular.
  • El Backlog Refinement es un evento en el cual el Producto Owner junto con el equipo pueden incorporar su conocimiento más reciente acerca de los backlogs.
  • Scrum fue concebido como un “wrapper” de XP y de hecho fue Ken Schwaber quien convenció a Jeff Sutherland de no prescribir practicas ingenieriles para hacer Scrum más digerible y acelerar su popularización.
  • Los Feature Teams son una forma preferible de organización de múltiples equipos y ofrecen muchas más ventajas que los Component Teams.

Si bien hay muchos otros tópicos importante que el libro aborda creo que con lo anterior resumo la esencia y ayudo a provocar curiosidad en la gente. Recomendación final, léanse el libro 🙂

Revisando el “Old Scrum”

Después de muchos años me di la oportunidad de releer el clásico libro de Schwaber y Beedle que fue el que inicio la popularidad de Scrum.

Y encontré varias cosas que cambiaron con el tiempo o que de alguna manera fueron mal entendidas, la siguiente es una lista que resumen mis hallazgos:

  • Scrum fue concebido como un “wrapper” alrededor de las prácticas de eXtreme Programming. Lo anterior no solo explica porque ambos se parecen pero más importante que eso implica que no es factible esperar mucho de Scrum sin que las prácticas técnicas hayan cambiado hacia eXtreme Programming.
  • Quien escribe el código es el dueño del mismo, lo cual implica que no hay terceros que lo prueban, mantiene y ponen en producción. Esto se alinea con el principio Lean de evitar hand-offs y especialización de roles. Visto desde otra perspectiva ya en este libro se comienzan a sentar las bases de lo que décadas después vemos en DevOps.
  • La organización es en su conjunto responsable por remover impedimentos y solamente esta tarea exclusiva del Scrum Master.
  • El efecto sociológico que tiene Scrum sobre la organización en su conjunto, efecto que se traduce en la presencia de valores y creencias que son perpetuadas a través de los roles y su profundo impacto en el diseño organizacional.
  • Los orígenes de Scrum conectados con los procesos de control industrial empírico practicados por DuPont.
  • La conexión Smalltalk que fue el lenguaje de programación en varios proyectos dentro de los cuales Schwaber participo. Consecuentemente esa conexión derivó en el acercamiento hacia Kent Beck y su equipo que fueron los pioneros en XP.
  • En ninguna parte del libro se menciona la escritura de historias de usuario, el uso de story points ni menos aun la estimación usando planning poker.
  • Las tareas se estiman en horas, de 4 a 16 horas por tarea lo cual desde luego es demasiado pero el punto importante es que se estiman en horas.
  • Scrum fue concebido como un marco de trabajo orientado a resultados, no a reportes por lo tanto no se deben utilizar Gant charts, PERT charts o cualquier otro mecanismo de tracking importado de otras disciplinas ingenieriles.
  • La concepción de que el software se fabrica es errada y por tanto la noción de “fabrica de software” esta fuera de contexto.

Algunas cosas que en mi opinión no fueron concebidas adecuadamente, o quizás si lo fueron para el momento que se escribió el libro, son estas:

  • El Sprint Review es para mostrar el incremento a los ejecutivos de la empresa, aplicable quizás si se construye un producto interno pero aun así no efectivo si los ejecutivos mismos no serán lo que usen el producto.
  • Scrum se describe como un “management framework” donde management esta representado por la figura del Scrum Master, esta es quizás la parque que acabo creando mayor confusion pues tener una figura central de management dentro del equipo puede y acaba en la práctica con el concepto de autoorganización y empoderamiento.
  • La prescripción de utilizar burndown charts que fuerza a tener estimaciones y luego tratar de adherirse a ellas. Si bien este es un concepto atractivo en la práctica no probó ser util.
  • Sprints de 30 días de duración que en la practica resultan muy largos y acaban promoviendo retrasos en la integración e historias muy grandes.
  • El Daily Scrum Meeting como instancia de reporte de status, considero que no es realista reportar el estado de progreso sin mirar el código y mirarlo y entenderlo simplemente no es algo que se pueda hacer en una reunion de menos de 15 minutos.

Creo que este libro debe ser redescubierto por todos aquellos que nos consideramos parte activa del movimiento Scrum pues en el hay sabiduría que debe ser interpretada y pasada correctamente.

Finalmente no me canso de enfatizar que sin la mejora en lo técnico Scrum simplemente se queda como un “wrapper” vacío que mejora cosas cosméticamente pero no acaba produciendo un cambio profundo de efecto duradero. Más aún, la mejora en lo técnico implica un rediseño organizacional sistémico que quizás la mayoría de las organizaciones no se animen o puedan realizar. Sin lo anterior los frutos de Scrum tristemente seguirán siendo pocos.