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.

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?

Mis reflexiones acerca del Global Scrum Gathering Austin 2019

Del 20 al 22 de mayo se llevó a cabo en Austin-Texas la conferencia Global Scrum Gathering Austin 2019 que contó con asistencia de aproximadamente 1600 personas y docenas de speakers.

Como siempre fue un placer asistir y conocer a nuevas personas y reencontrar a viejos conocidos que no había visto en mucho tiempo. Más allá de lo social la conferencia me dejó algunas impresiones que resumo en este post.

Un Open Keynote espectacular

Daniel Pink abrió la conferencia con un keynote basado en su último libro. Su keynote fue por decirlo en un termino magistral por la calidad de su contenido, la forma con la cual lo presentó, la conexión que estableció con la audiencia y la fluidez de su presentación.

Hacia mucho tiempo que no había tenido la suerte de asistir a un keynote en el cual la audiencia al final se ponía de pie para ovacionar al keynoter.

Desde luego las conferencia ágiles han tenido muchos otros excelentes keynoters pero Pink llevó el evento a nuevas alturas. Es interesante también recalcar que el Scrum Alliance ha crecido y madurado lo suficiente como para poder financiar la presencia de un keynoter de este calibre abriendo su conferencia.

El mito de las historias de usuario escritas

En el segundo día de la conferencia se armó un Open Space en el cual hubo una charla de TDD, lamentablemente se me escapa de la memoria el nombre de quien presentó el tema. Pero lo interesante del asunto para mi fue que durante esa presentación habían participantes que cuestionan TDD como práctica y preguntaban donde quedaba la documentación escrita, como encajaba todo esto con JIRA y como se deberían escribir historias de usuario.

Y entonces apareció Chet Hendrickson.

Chet dijo que como una de las personas que estuvo ahi cuando se inventaron las “historias” estas no se escriben, no son documentos, son por el contrario conversaciones valiosas entre desarrolladores y usuarios.

La clarificación de Chet involucro un pedido, que la gente y las empresas sean más corteses y dejen de llamarle “historias” o “historias de usuario” a lo que hacen pero que no tengan nada que ver con la idea original que él y los demás propulsores de XP crearon décadas atrás.

Para mí esta intervención de Chet fue la que ilumino el día y creo personalmente que debemos considerarnos afortunados de que los creadores del movimiento todavía estén presentes para clarificar malos entendidos. A su vez debemos considerarnos desafortunados por los múltiples malos entendidos que ahi allá afuera respecto a la agilidad en su conjunto.

LeSS es el secreto mejor guardado

Algunos colegas CSTs y LeSS Friendly Scrum Trainers decidieron financiar y atender un stand donde se promocione LeSS. Si bien ninguno de los dos co-creadores de LeSS estuvieron involucrados, pues promocionar LeSS no es de su interés, es la percepción de muchos trainers y consultores (evito usar la palabra coaches) de que LeSS es el “secreto mejor guardado” y que hay que empezar a revelarlo pues tiene el potencial para realmente de-escalar Scrum.

SaFE no esta funcionando

Una percepción generalizada entre la gente con la que tuve la oportunidad de hablar es que SaFE en general no acaba resolviendo los problemas que se suponía tenia que resolver.

Las razones son varias, van desde la elevada complejidad sistema hasta el resurgimiento de ideas que en los ’90s probaron ser ineficaces.

Sin embargo también es la percepción de la mayoría de los colegas con los que puede hablar del tema que SaFE se esta vendiendo muy bien, las empresas lo comprar y hay muchos quienes lo venden.

Entonces cómo corolario puedo inferir que SaFE funciona para quien lo vende y enseña pero no necesariamente para quién lo compra y trata de usarlo.

El Scrum Alliance apunta a ser realmente global

Quedaron atrás los días en los cuales ésta era una conferencia intima y pequeña organizada por voluntarios por amor a Scrum. En los tiempo actuales se ve un crecimiento y una mirada cada vez más hacia otros países donde se pueda expandir aun más Scrum.

En mi humilde opinion el Scrum Alliance tiene el capital económico y cuenta con el acceso al capital intelectual que permitiría esta expansion global. El tiempo dura si sus lideres pueden articular una estrategia válida que les permita alcanzar este fin.

Finalmente puedo decir sin lugar a duda que asistir a esta conferencia fue una experiencia intelectualmente refrescante, de aprendizaje y validación/revalidación de muchas ideas y conceptos, de reencuentro y caras nuevas. En general la recomiendo ampliamente y la próxima cita para mi será en Nueva York en mayo del 2020.

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.