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.

Desarrollo de Software Ágil en 10Pines

Hace poco mi querido amigo Federico Zuppa terminó la tarea que se autoasigno la tarea de escribir un libro acerca del como hacen software dentro de 10Pines, empresa de la cual es parte casi desde su fundación.

Antes de hablar del libro me tomo unas lineas para hablar de la generosidad de Fede al dedicar tiempo y esfuerzo para escribir y brindar sus conocimientos a la comunidad de manera abierta y transparente. También aplaudo la entereza de 10Pines que lejos de proteger su forma de trabajo la hace pública; desde luego esto no quiere decir que todas las empresas deban copiarlos pues no es posible hacerlo, pero enterarse que 10Pines pone en práctica con éxito lo que la teoría dice es simplemente reconfortante.

El libro lleva por titulo “Desarrollo de Software Agil en 10Pines” y esta disponible gratuitamente. El tema central del libro gira en torno a describir el proceso que siguen dentro de 10Pines cuando van a trabajar con un cliente en la construcción de un producto de software.

Como tal el proceso es bastante clásico, se base en libros conocidos y no comentare mucho más acerca de ellos. Sin embargo si comentaré un par de temas que llamaron mi atención profundamente:

  1. El fuerte énfasis en la excelencia tecnica que se fundamenta en prácticas de eXtreme Programming y Clean Code.
  2. El uso de herramientas electronicas como JIRA.

Si bien el proceso descrito en el libro es hasta cierto punto conocido pues fue documentado hace mucho tiempo en libros ya clásicos, lo que no es fácil de copiar solo leyendo el libro es la disciplina y enfoque en lo técnico que hacen de 10PInes una potencia.

El entasis en lo técnico es solamente posible si se tiene grandes mentores y una cultura organizacional que lo cultive y fomente, y eso es precisamente parte del ADN de 10Pines.

Hablando del uso de herramientas electrónicas creo que es posible hacer lo mismo sin JIRA, con solo post-its y con comunicación eficiente. Quizás si volvemos a la esencia de XP postulada por Beck y el mítico equipo del proyecto C3 y pensemos Lean podemos ver JIRA como una forma más de desperdicio. Desde luego este es solo un teorema mío que no pretende desvalorar en lo absoluto el gran trabajo de Fede y 10Pines.

Finalmente, creo que ya era hora de tener libros como este, creo que la comunidad lo recibirá con apetito y curiosidad; y cómo me gusta decir “la curiosidad de los lectores es el combustible de los escritores”. Esperemos entonces escuchar más de Fede y las aventuras de 10Pines.