Elementos integradores de LeSS

Por mucho tiempo se ha estado buscando la combinación que mejor funcione y que permita que múltiples equipos Scrum puedan trabajar de manera productiva. Los creadores de LeSS, siguiendo un enfoque de experimentación, acabaron descubriendo que cosas no funcionan y cuales pueden tener buenas chances de funcionar.

Es precisamente porque con Scrum no hay receta cierta que muchos errores se acaban repitiendo una y otra vez. A lo anterior hay que sumarle el síndrome del “yo soy diferente” que básicamente consiste en creer que por alguna razón lo que no le funciona a nadie a mí me acabará funcionando bien.

Entrando en tema, en LeSS existen elementos que centralizan y otros que descentralizan. La idea de los centralizadores es crear alineación y seguir una linea común y desde luego los descentralizadores están para proveer autonomía y fomentar la creatividad. En este post hablaré de solamente un par de estos elementos centralizadores.

Un solo Product Owner para todos

Dentro de Scrum básico ya se veía desde hace décadas que la figura de un PO empoderado, visionario, emprendedor y que concibe el producto de manera sistemática, acaba siendo fundamental para llevar a buen termino el trabajo de varios equipos.

Desde luego lo anterior no quiere decir que el PO no escucha a nadie, por el contrario esta en constante comunicación con todos los equipos, interesados, clientes, usuarios, etc., pero al final del dia es el/ella quien tomas las decisiones de producto.

Visto desde la perspectiva opuesta, tener múltiples POs acaba creando dos grandes problemas:

  1. Una jerarquía accidental con múltiples niveles donde la comunicación fluye rápidamente de abajo hacia arriba pero no necesariamente igual de bien en la dirección contraria
  2. La demora en la toma de decisiones pues estas deben ser consensuadas en largas reuniones

Todos o nadie querrá ser ese PO

Si el salario, privilegios, poder de decision e influencia están concentrados en ese único PO, desde luego que todos en los equipos (o fuera de ellos) ambicionarán esa responsabilidad.

Es ahi donde precisamente LeSS propone hacer cambios sistémicos profundos dentro de la organización para que la figura del PO sea influyente y decisiva mas no jerárquica y burocrática.

En el extremo opuesto, ¿qué hacer cuando nadie quiere ser ese PO? La respuesta a la pregunta anterior puede ser el síntoma más no la causa raíz, quizás la verdadera razón resida en que la organización no crea productos innovadores, sigue recetas antiguas o simplemente castiga y busca responsables. 

Al explorar las causas raíz quizás se desvelen ante nosotros las verdaderas razones por las cuales nadie de buena gana se quiere aventurar a ser el PO de varios equipos.

Un unico repositorio sin ramas

La idea de que cada desarrolladores es libre, feliz y más productivo avanzando en solitario con su copia local de código es simplemente eso, una idea; idea qué por cierto ha probado una y otra vez ser contraproducente. Desde luego en este punto comenzarán Ustedes a pensar en contraargumentos como:

  • Es que así hemos trabajo siempre
  • Es que la gran empresa X a la que miramos con admiración trabaja de esta manera
  • Es que el manager de desarrollo, que hace 15 anos es manager y no desarrollador, nos dijo que trabajemos así
  • Es que en la universidad yo trabaja así y a eso estoy acostumbrado
  • Es que yo hago mi parte y luego veré como integro (si llego a integrar mi trabajo con el de los demás)
  • Y la clásica, este no es un problema para nosotros porque somos “diferentes”

Acortaré el camino y les daré la respuesta a sus males: todos los desarrolladores, en todos los equipos Scrum, todos los dias, en incrementos muy pequeños, integran su código sobre un repositorio que no tiene ramas.

Si lo anterior es difícil de entender vuelva a leerlo y verá que el problema no esta en el entendimiento de la oración sino en lo contraintuitivo que suena. Contraintuitivo porque estamos acostumbrados a hacer lo contrario de lo simple, disciplinado y ordenado.

La pesadilla de la integración

“Ya terminamos nuestras historias, solamente nos falta integrarlas”, ¿habrán escuchado de casualidad la frase anterior? De haberla escuchado quizás se hicieron preguntas como las siguientes:

  • ¿Cuánto tiempo tomará integrar todo?
  • ¿Porque no integramos antes?
  • ¿Y después de integrar recién vamos a poder probar si todo funciona?
  • ¿Qué vamos a mostrar en el Sprint Review de los equipos si nada esta integrado?
  • Y una pregunta existencial aún más profunda, ¿porque será que los desarrolladores desarrollan su código sin integrarlo continuamente?

Facilitaré la vida de mis lectores respondiendo solo a la última pregunta, los desarrolladores no integran su código frecuentemente porque piensan que integración continua es igual a una herramienta que compila el código de todos.

En LeSS redescubrimos un viejo concepto de eXtreme Programming, integración continua es integrar continuamente al final de cada ciclo corto e integrar siempre sobre el repositorio central.

Si lo anterior llega a ser entendido, digo realmente entendido, y practicado con una disciplina espartana, finalmente habremos despertado de la pesadilla de la integración.

La despedida

Así como existen elementos de centralización organizativa, como es el caso de tener un único PO, y elementos de centralización del trabajo técnico, como es el tener un único repositorio sin ramas, existen muchos mas elementos centralizadores dentro de LeSS – elementos que espero poder describir a futuro en otro post.

Sin embargo este juego de centralizar algunas cosas y descentralizar otras requiere un cambio profundo y la motivación para mantener este cambio. Al final LeSS, como herramienta de rediseño sistémico, lo que pretende es precisamente hacer que la forma cómo las organizaciones se estructuran cambie y de esta manera impactar el trabajo mismo y consecuente la organización de múltiples equipos Scrum.

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?

El comienzo de un nuevo ciclo

Comienzo este 2019 con energias renovadas luego de un 2018 bastante intenso en el cual tuve la fortuna de poder llegar varios países y conocer gente nueva interesada en aprender acerca de Scrum.

En mayo del 2018 una reunion de Board de Directores del Agile Alliance fue el motivo para ir y conocer la bella ciudad de Porto en Portugal.

Image result for porto portugal

La conferencia Agile 2018 en agosto en San Diego- California también fue otro hito importante  del 2018 ya que tuve la oportunidad de aprender nuevas cosas, encontrarme con viejos amigos y conocer gente nueva.

Image result for agile 2018 conference

En octubre un curso privado me llevo por primera vez a la bella ciudad de Cali-Colombia  y quede encantado con el paisaje y la calidez de su gente.

Image result for cali colombia

Cerrando el 2018 con broche de oro en noviembre fui para California un par veces a tomar los cursos de Certified LeSS Practitioner-Principles and Practices con Bas Vodde y Craig Larman respectivamente. Estos cursos fueron sin duda el punto más alto de mi aprendizaje de todo el  2018 ya que pude adquirir conocimiento y confirmar conclusiones a las que empíricamente yo había llegado.

Con todo esto puedo decir que el 2018 fue definitivamente un gran año y miro con mucho optimismo este 2019 que recién comienza.

Uno de mis objetivos para este 2019 es escribir más (sobre todo en castellano) para compartir mis idea y esa es la razón por la cual inicio este blog.