Ayer terminé de leer este libro de Henrik Kniberg y aunque fue escrito en la época pre-Spotify del autor contiene lecciones muy valiosas que a continuación tratare de resumir.
El libro documenta el caso de estudio del desarrollo de un sistema para la policía Sueca, proyecto en el cual Kniberg se vio envuelvo por varios meses hace como una década atrás.
Kniberg describe la manera en la que se estructuraron los equipos; se tuvieron equipos de análisis de requerimientos, features teams y equipos de testeo del sistema. Personalmente no favorezco este tipo de especialización por roles y funciones pero en este proyecto al parecer si funcionó bien. Si vemos los videos que el mismo Kniberg creó años después encontraremos que en Spotify solo existen feature teams.
Los tableros kanban fuero una herramienta fundamental para visualizar el estado de flujo de los items que los equipos iban trabajando. Los tableros segun Kniberg fuero evolucionando de manera experimental respondiendo al aprendizaje y necesidades de cada equipo. Dichos tableros fueron también muy usados en la reuniones de stand up y planificación.
Si bien en Scrum usamos una forma básica de tableros creo que la gran lección del libro es que de nada sirve un tablero si no se puede experimentar con él, si no no muestra el flujo de items y si no ayuda a detectar cuellos de botella. Lo anterior son principios Lean que de alguna forma en Scrum olvidamos y no deberíamos de hacerlo pues no usarlos solo conduce a tableros como herramienta decorativa.
Un concepto muy importante que se menciona en el libro es la necesidad de tener holgura (slack) que básicamente permite el flujo mas rápido de items. El libro presenta la analogía de una carretera en la cual si se pretende utilizarla al 100% de su capacidad entonces simplemente no hay suficiente espacio para que los automóviles se muevan. Desde teoría de restricciones (Goldratt) sabemos que sobrecargar un sistema al máximo solo degrada su rendimiento; curiosamente en muchas organizaciones todavía siguen tratando de utilizar al tiempo de cada miembro de un equipo de Scrum al 110% si fuera posible.
Kniberg propone el uso de burn up charts en lugar de burn down charts lo cual obedece a un principio Lean básico de solo contar las piezas bien fabricadas como medida de productividad. Si de métricas hablamos Kniberg enfatiza el uso del tiempo de ciclo que es la única métrica Lean que vale la pena medir y optimizar.
En el libro Kniberg describe una estrategia de versionamiento por equipo y por feature, incluso presenta una estrategia para trabajar con bugs y versiones. Una vez más esta es una experiencia del 2011 y pre-Spotify. Personalmente no recomiendo la creación de branches bajo ninguna circunstancia pero sí no hay ninguna otra alternativa creo que la idea de Kniberg tiene mucho sentido.
La ultima parte del libro me sorprendió gratamente con una explicación de cómo utilizaron diagramas de causa y efecto para descubrir los verdaderos problemas que vivieron en la construcción de ese producto. Los diagramas causa y efecto tiene la gran ventaja de que apuntan a descubrir la verdadera causa de los problemas yendo mas allá de solamente los síntomas visibles. Mas gratamente sorprendido me quede al encontrar la referencia y conexión de estos diagramas con los postulados de Senge acerca de modelamiento sistémico.
Puedo decir en conclusión que leer este libro fue una experiencia refrescante y motivante porque siembre esta bueno saber que en otras partes del mundo aplicaron con éxito ideas y principios clásicos de Lean, Scrum y XP. De más esta decir que recomiendo leerse el libro, pero ahi comento que al leerlo hay que considerar que los años pasaron y que los principios y prácticas ya evolucionaron.
Lo leí un tiempo atrás y me encantó. No tenía que el autor después de esto ayudó a desarrollar el modelo Spotify. Lo que recuerdo es que es un gran ejemplo de un equipo con un enfoque abierto, no encasillado en una metodología y que va construyendo, como recomienda Scott Ambler, su propio Wow (Way of Working) aprendiendo de la experiencia.
No solo ayudo a desarrollar el modelo, más importante que eso ayudo a implantar las prácticas ingenieriles desde la base.
Estoy totalmente de acuerdo contigo- hay que apoyarse en la literatura, aunque sea de hace unos años, si uno quiere obtener mas información sobre la metodología pero, al mismo tiempo, hay que tomar en cuenta que el tiempo corre y que las herramientas cambian con el paso de días. Para mi la mejor solución par estar al corriente de la evolución de método es practicar mucho. En mi vida profesional aplico muy a menudo varias herramientas online para hacer organización de tareas mas fácil. Una de mis favoritas es https://kanbantool.com/es/ que une todo lo bueno de la metodología Kanban ayudando enormemente gestionar proyectos de varios tipos.