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.

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?

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?