Blog

Recapping Agile 2019

I’ve attended to my seventh Agile Conference this year in Maryland and in this short post I’ll try to recap the most important things that have impacted me during this awesome week. Before going there I have to say that this is my last conference as an Agile Alliance Board Member and this makes me feel sad but grateful for the opportunity to have served the Agile community at large.

Let’s start with something that really passionates me these days: LeSS. For the first time in the history of the conference we had a booth run by the self-organized team of “Fans of LeSS“. In my opinion this group of volunteers made a great contribution to the community by bringing LeSS to a conference with thousands of attendees that now know what it is. I was pleasantly surprised that Bas Vodde, co-creator of LeSS, was also at the conference.

Bas is the getleman on the left

Another great thing that coincided with this conference was the announcement of the “Fans of LeSS” declarating that now is receiving signatories. This is a historic event because it unites many of us that have been loudly proclaiming that Agile and Scrum have been distorted by companies and consultants. I’m anticipating that this will help to bring back sincerity about the true meaning of Agile and Scrum.

Going back to the conference there were two sessions ran by James Shore in which he presented an interesting idea: providing all the necessary tools for non-technical coaches to coach developers on TDD. Before you start asking how a non-technical coach will be able to even answer basics questions on TDD let me tell you that James seems to have produced materials, in the form of videos and samples, that can guide developers in simple TDD exercises. Of course if developers got stuck you can always call James.

James Shore on the stage

It’s fair to say that out of all XP practices, TDD seems to be the most challenging one for several reasons, but then it is a practice that truly contributes to disseminate the knowledge and craft better software. For this reason I can say that I applaud James’ efforts to popularize this practice.

On the not so bright side James create all his material in Java/JavaScript that are not my pick of programming ecosystem. Of course, this is just a personal preference that can be easily counter backed just by looking out there to the number of companies that use Java.

James Shore and Arlo Belshee presented a very interesting session on leading a technical transformation at very large scale with hundreds of developers. These are my key takeaways from that session:

  • Centralized leadership is not well equipped for dealing with the high systemic complexity of millions of lines of legacy code
  • Empowered teams using XP practices are the best chance to approach a highly complex code base
James on the left and Arlo on the right

As I mentioned at the beginning of this post, this was meant to be short with just the three or four things that made my mind wonder and dream with a world in which better software products could be produced by happier developers.

#noprojects

Recientemente termine de leer el libro #noprojects A Culture of Continuous Value escrito por mi dilecto amigo Shane Hastie con quien tuve la suerte de servir varios años en el Board de Directores del Agile Alliance.

El valor continuo esta en contraposición de la noción de proyecto con alcance y fecha fija.

El libro en sí se base en un postulado que se viene escuchando ya desde hace bastante: que debemos pasar de la era de los proyectos a la era de los productos. Las razones detrás de este postulado son multiples pero una que para mí tiene mucho sentido es que los proyectos tienden a resultados inmediatistas en desmedro de la calidad y la cohesión de un grupo humano de individuos en un equipo de verdad.

El libro también hace una revision historia del origen y él porque se incluye el concepto de proyectos que a su vez dio origen a la profesión de Project Managers. Es interesante que en el contexto histórico los proyectos contribuyeron gran valor pero en la era del conocimiento simplemente son un anacronismo.

Rescato también del libro la inclusion de varios postulados, libros y teorías mas modernas como el Cynefin Framework y de Dude’s Law por nombrar solo uno cuantos. Interesantemente el libro presenta la idea de que diferentes fuentes, incluyendo la corriente agil, acaban convergiendo en que los proyectos no son la mejor manera para abordar el trabajo creativo que es lo que se require para crear disrupción en los competitivos mercados actuales.

Los casos de estudio incluidos en el libro son valiosos desde la perspectiva que validan la hipótesis de que es posible alcanzar valor para las organizaciones creando productos sin necesidad de caer en la pesada carga de verlos como proyectos multietapa y que requieren control centralizado. Sin embargo los casos de estudio, como es siempre cierto con ellos, son altamente dependientes del contexto dentro del cual ocurrieron.

Finalmente considero que la mera existencia de un libro como este indica que hay una evolución del conocimiento no motivada por la moda sino por la necesidad, evolución que con un poco de suerte y perseverancia nos acabara sacando de una vez por todas de la era de los proyectos y los recursos y nos llevara hacia la era de los productos creados por individuos motivados y respetados como seres humanos.

Memorias del primer curso de Certified LeSS Basics

Memorias del primer curso de LeSS en castellano

El 19 de junio tuve la suerte de dictar por primera vez el curso de Certified LeSS Basics en Ciudad de Mexico, de hecho esta fue la primera vez que este curso se enseña en castellano en un país hispano hablante. En este post trataré de recoger algunas de la ideas centrales que fueron discutidas.

LeSS es en esencia un marco de de trabajo que se puede aplicar para el diseño/re-diseño organizacional y el pensamiento sistémico es uno de sus herramientas de pensamiento

LeSS parte de la premisa que cualquier empresa debe ser conceptualizada como un sistema complejo en el cual existen diferentes actores interconectados, esta interconexión es la que hace que sea necesario analizar sistémicamente cualquier cambio y los efectos que pueda desencadenar. 

Una de las razones principales por las cuales LeSS es una alternativa viable para el rediseñó organizacional sistémico es que lidia adecuadamente con la alta complejidad inherente de una organización. 

La forma de LeSS de lidiar con esa alta complejidad sistémica inherente es no introduciendo más complejidad, es decir siendo un marco de trabajo minimalista que rescata la simplicidad del verdadero Scrum

Mas aun, si se tiene una empresa con una complejidad alta debido a factores como su tamaño, procesos, cantidad de empleados, ubicaciones geográficas y otros; al tratar de aplicar en ella un marco de trabajo complejo la complejidad de la empresa se volverá super lineal. Lo anterior viene de un postulado sistémico simple: sistemas complejos tienden a sobrecomplejizarse cuando en ellos se aplica una herramienta sistémica mas compleja

LeSS también parte de una noción fundamental: el rediseñó organizacional sistémico requiere compromiso sincero de la alta gerencia de una empresa.

La razón del postulado anterior es que simplemente no es acertado asignar un problema de amplitud sistémica a solamente un individuo cuyo poder de influencia y cognitivo no alcanzaría a impactar a toda una organización. Dejare para otro post la discusión de que en realidad no se necesita un Agile Coach que transforme una organización sino Pensadores Sistémicos que rediseñen organizaciones. 

Uno de los cambios sistémicos mas profundos es dejar de ser una organización que promueva la competitividad interna, el control y a las métricas; y pasar a ser una organización que realmente cree un ambiente de aprendizaje continuo donde la gente se pueda sentir segura aprendiendo y fallando.  

En este sentido LeSS enfatiza que no se trata de copiar mejores prácticas (he hecho la frase “mejores prácticas” se considera dañina pues nos aleja de la mejora continua) de otras organizaciones sino via experimentación descubrir cómo convertirse en una organización de aprendizaje constante. Dicho más resumidamente se trata de aspirar a ser una “learning organization” y no una “copying organization”.

Algunos de los cambios sistémicos profundos implican el identificar y eliminar formas de desperdicio; después de todo LeSS tiene a Lean como otra de sus herramientas de pensamiento.  Pensando Lean hay ciertos esquemas y prácticas que no tienen cabida dentro de una organización simplificada. 

La lamina anterior muestra algunas de las prácticas organizacionales/ingenieriles que no acaban contribuyendo y que por el contrario generan desperdicio. Como es de esperarse la sola mención de que deben eliminarse crea resistencia y temor, razon por la cual LeSS no es para cualquier organización. La lógica de los creadores de LeSS ha sido que en lugar de salir a tratar de convencer a los gerentes de una empresa de eliminar estas prácticas, mejor esperaran a que gerentes visionarios se aproximen a ellos en busca de ideas acerca de como rediseñar sus organizaciones de tal forma de evitar estas prácticas improductivas.

LeSS abraza una mentalidad de experimentación constante pero sin reinventar la rueda y caer en errores conocidos y documentados.

LeSS no es presprictivo al 100% pero sí tiene una reglas que deben ser seguidas, respetando esas reglas la experimentación en bienvenida. Desde luego habra quien diga que esas reglas no aplican para su contexto particular y que lo que a los creadores no les funciono a el/ella si le funcionará, creo que ante esto lo único que puedo decir es que es necesaria la amplitud de mente y la humildad intelectual para estar mejor preparados pasar sacar provecho del “secreto mejor guardado de la agilidad” (LeSS).

Finalmente agradezco de sobremanera a los colegas que salen en la siguiente fotografía por haber sido parte de este curso y espero escuchar de ellos a futuro historias acerca de su viaje de descubrimiento con LeSS. 

LeSS y las heridas autoinflingidas

Estaba pensando en LeSS mientras tomaba un cafe en un cowork, mis pensamientos fueron detonados por esta imagen:

Creo que la imagen metafóricamente ilustra lo que la mayoría de las veces acaba pasando cuando se quiere apresurar el desarrollo de software en detrimento de la calidad. Podríamos decir que en la imagen la oruga nunca se transforma en mariposa por completo ni tampoco vuela por lo pesada que se vuelve la deuda técnica.

En LeSS la metáfora es muy simple: hacer que la oruga se transforme en mariposa protegiendo su desarrollo y que luego vuele ligera. Si bien es una metáfora creo que es válida pues cosas como alcance expandiéndose sin final y la negación de la prácticas de XP acaban comprometiendo el producto.

El volar ligero en el mundo de LeSS implica el tener un producto sin toneladas de features que nadie usa o qué raramente son utilizadas. Cabe recordad que LeSS es Lean y por lo tanto trata de evitar todas las formas de desperdicio posibles.

LeSS no pretende resolver todos los problemas, solamente los más importantes que normalmente implican transformaciones sistemáticas profundas. Desde otra perspectiva LeSS apunta a dejar atrás las heridas que las organizaciones y equipos se infringen a sí mismas por ignorancia o masoquismo.

Si hablamos de este tipo de heridas estas de manera general segun mi criterio caen en cuatro categorías:

  • Heridas de conocimiento estático que se niega a evolucionar y actualizarse, es decir, gente que trata de resolver problemas ya resueltos con conocimiento inadecuado para el propósito.
  • Heridas de organizaciones anacrónicas que tratan de aplicar paradigmas de management que eran vigentes en pleno auge de la revolución industrial y cuando el trabajo manual y no el mental era el que predominaba.
  • Heridas de practicas de ingenieria que está probado que son anti-Lean o mejor dicho anti-sentido-común pero que la gente sigue insistiendo en emplear; la más dañina de ellas es escribir código que solo el desarrollador que lo escribió entiende.
  • Heridas personales de negación y queja pero que a la vez nos disparan el cambio personal ni tampoco el crecimiento. Esta es quizás la categoría donde el primer cambio hacia LeSS debe acaba ocurriendo pues del cuestionamiento personal profundo debe partir el aprendizaje sincero y sin descanso.

Finalmente me permito plantear un postulado: personas sin heridas forman equipos sin heridas dentro de organizaciones sin heridas y estas a su vez tienen mas chances de construir de manera armónica los productos que el mercado espera. Si lo anterior tiene sentido para ustedes la pregunta sistémicas se vuelve, ¿qué se necesita para empezar a sanar estas heridas?

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 🙂

Scrum si se mezcla con Kanban

Siguiendo con mi lista de libros a leer por autor esta vez le tocó el turno a este libro ya clásico:

Libro escribo en el 2010

Definitivamente recomiendo las primeras cincuenta páginas del libro pues contienen un resumen de la esencia misma de Scrum en comparación con la de kanban. La segunda parte del libro contiene un caso de estudio del cual aprendí poco, pero fue gratificante leer que una viaja amiga Linda Cook es referenciada por un reporte de experiencia que ella escribió.

En las cincuenta primera paginas Kniberg describe muy fiel a su estilo los puntos en común y diferencias entre Scrum y Kanban, de esa descripción me quedo con lo siguiente:

  • Kanban tiene tres principios fundamentales que representan la simplicidad de su enfoque, a saber: visualizar el flujo de trabajo, limitar la cantidad de trabajo en proceso y medir el tiempo de ciclo. A través de la visualización del flujo se pueden detectar las actividad que contribuyen valor, las colas y tiempos reales de operación. Con esas entradas se intenta definir empíricamente el límite de cantidad de trabajo en proceso que a su vez tendrá un impacto directo en el tiempo de ciclo.
  • Kanban es una herramienta poderosa más no un marco de trabajo como lo es Scrum. El no ser prescriptiva y simple la convierte en un buen candidato para usarse en complemento (o reemplazo) de Scrum. Desde luego si se decide complementar Scrum con Kanban o viceversa el objetivo siempre debe ser permanecer dentro del paraguas filosófico de la agilidad y el pensamiento Lean.
  • Un tablero kanban es ciertamente más prolijo y detallado que un tablero Scrum e invita a cosas como por ejemplo que exista uno solo compartido por multiples equipos. Al igual que en Scrum, un tablero en kanban se presta a la experimentación y evolución a medida que el equipo decide irle haciendo adaptaciones.
  • Kanban enfatiza más el trabajo con piezas pequeñas y de tamaño similar lo cual en esencia facilita el flujo. Al no tener un concepto de Product Backlog que debe estar priorizado abre la puerta para mayor agilidad y trabajo de forma pull y no push.
  • En Scrum el trabajo en progreso es limitado por unidades de tiempo como la duración del Sprint, la jornada laboral o la estimación de una historia. En Kanban por el contrario el trabajo en progreso es limitado por el estado del flujo de trabajo. Esta diferencia conceptual fundamental hace que kanban incentive de mejor manera el flujo constante.

En resumidas cuantos puedo decir que vale la pena leer el libro y aun más vale la pena experimentar con kanban.

Lean, el pariente cercano de Scrum en la práctica

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.

Cabe notar que este libro se publico en el año 2011

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.

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.

LeSS el secreto mejor guardado de la agilidad

El titulo de este post proviene del hecho de que LeSS no se promociona ampliamente ni tiene detrás suyo un gran esfuerzo de mercadeo. La razón para esto tiene que ver con la visión de sus creadores Craig Larman y Bas Vodde cuya teoría es que quien quiera buscar LeSS podrá encontrarlo pero que ellos no harán esfuerzos en promocionarlo.

LeSS no se estructura en un esquema que pretenda generar negocio para sus creadores ni tampoco atraer organizaciones ni consultores que quieran explotarlo en todo su potencial. Si bien existen consultores, capacitares y casos de estudio, LeSS en general sigue siendo de nicho y con fuerte presencia en Europa y Asia (parte de esto es porque ahi viven/trabajan Craig y Bas).

Lo anterior parece contraintuitivo pues ¿cómo alguien se enterara siquiera de que LeSS existe?. La respuesta es simple, a través de agilistas serios que leyeron, utilizaron, y aprendieron LeSS y qué pueden recomendarlo ampliamente.

En mi historia personal puedo decir qué descubrí LeSS el 2018 y desde entonces no he dejado de alabar su simplicidad, plasticidad y énfasis en la excelencia técnica. Más aun, gracias a LeSS he podido ponerle nombre a cosas que yo venia diciendo y haciendo desde hace tiempo y que Craig y Bas magistralmente teorizaron en los tres libros que escribieron.

Hablando de los libros después de leerlos y releerlos creo que ellos resumen todo tipo se situaciones reales a las cuales cualquier agilista se enfrentó, enfrenta o enfrentará. Dicho de otra manera, los libros muestran todos los problemas que uno podría encontrar con múltiples equipos y las soluciones que Craig y Bas encontraron via experimentación.

Así por ejemplo el gran valor de este libro es qué presenta centenares de experimentos que Craig y Bas realizaron a lo largo de los años y simplemente desde ahi pueden decir que no funciona y que podría llegar a funcionar. Es importante recalcar que no hay garantía de que alguno de los postulados de LeSS funcione a la perfección para un contexto particular pues como diríamos en Scrum “todo depende del equipo” y en LeSS tenemos muchos de ellos.

Sin embargo lo que sí vale la pena rescatar de este libro, y que corroboro con mi experiencia personal, es lo que no funciona. La genialidad de Craig y Bas esta precisamente en esos detalles, decirle abiertamente a quienes se acercan a LeSS que no hacer. Desde luego nunca faltaran las excepciones o la gente que diga “que importa que a ellos no les funciono, a mi me funcionará”.

¿LeSS debe seguir siendo un secreto?

Personalmente creo que no, pues si este conocimiento sigue oculto muchos errores se seguirán cometiendo, carreras acabaran frustradas, se crearan productos con toneladas de desperdicio y lo peor de todo, se seguirá culpando a Scrum de lo mal que salieron las cosas.

El riesgo sin embargo está en que al empezar a conocerse más LeSS sea criticado o ignorado. En este sentido creo que es más fácil ignorarlo que criticarlo pues sus bases teóricas y evidencia practica son difíciles de refutar (personalmente lo intenté y me quede sin argumentos válidos).

Un riesgo aun más grande creo es que LeSS sea mal entendido, devaluado y tergiversado. Si miramos el caso de Scrum este fenómeno es el que se vive actualmente, basta sólo con mirar cómo se ha vendido, explicado e interpretado Scrum en muchos lugares.

Entonces después de todo no resulta tan malo que LeSS siga siendo el “secreto mejor guardado de la agilidad” ¿verdad?