Blog

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?

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.

Scrum Mastery

Introducción

La maestría de Scrum no viene de repetir siempre las mismas formulas y tratar de aplicar a rajatabla siempre las mismas ideas, bien más bien de dudar de lo que se conoce y forzarse a uno mismo a seguir aprendiendo.

Si bien es cierto que la práctica constante hace al maestro no es la práctica repetitiva y mecánica la que hará a un gran ScrumMaster; pero lo contrario si es cierto, sin práctica no hay cómo convertirse en un gran ScrumMaster.

Paradójicamente la práctica pura sin reflexión puede producir que los conceptos inicialmente aprendidos muten en otros literalmente opuestos y que con el tiempo se vuelven en verdades para el practicante.

Para evitar esta mutación de la práctica hay dos anclas que ayudan bastante: primero, una comunidad de pares con la cual vincularse y compartir experiencias, y segundo, el constante aprendizaje a través de la lectura de buenos libros.

¿Porque Eres un ScrumMaster?

Al hacer y hacerme esta pregunta a mí mismo a lo largo de los años he encontrado respuestas tan variadas como:

  • Necesitaba el trabajo
  • Por el prestigio
  • Me obligaron
  • Me enviaron a un curso y luego tomé el rol
  • Por accidente
  • Porque está de moda
  • Para convertirme en un líder

Quizás más importante que la respuesta misma sea por qué debemos preguntarnos por qué estamos cumpliendo este rol, considero que el cuestionamiento constante es el que nos hace encontrar en nosotros mismos la motivación interna para: uno, seguir en el rol y dos, crecer en el mismo.

La otra pregunta fundamental por hacerse es si los valores de Scrum siguen vivos, no solo dentro del equipo, sino dentro de uno mismo. Este trabajo de introspección resulta muy enriquecedor pues con el tiempo las prácticas y técnicas cambian y se enriquecen, pero los valores deben mantenerse.

He encontrado en el camino muchos ScrumMasters que predican los valores y hasta los prescriben para sus equipos, pero no los internalizan ellos mismos; la consecuencia lógica de esto es que la gente de los equipos se da cuenta y deja de creer en la autenticidad y liderazgo del ScrumMaster.

Si hablamos de liderazgo considero que un líder desde el enfoque Scrum no es alguien a quien la jerarquía diga que hay que seguir, sino más bien alguien a quien la gente decide seguir. Desde luego este estilo de liderazgo escogido por la gente no es exclusivo de Scrum y se puede encontrar en empresas como Whole Food, W. L. Gore & Associates, y Google [Hamel07]. 

El ScrumMaster Ante el Conflicto

El conflicto como tal no es inherente solamente a los equipos Scrum ni a las empresas en las cuales trabajan los ScrumMasters. El conflicto está en la naturaleza misma de la interacción de los seres humanos, interacciones que pueden llevarse a cabo a nivel colaborativo, personal y/o de negocios [Kaner07].

Sin embargo, como ScrumMaster hay que prepararse para lidiar con conflictos que pueden ser de carácter destructivo y fracturar las relaciones dentro de un equipo. En general, conflictos de este tipo presentan características como:

  • Emocionalidad, es decir alguien o varias personas en el equipo gritan, gesticulan, lanzan objetos o se comunican de manera agresiva
  • Tono de voz, puede ser que nadie esté gritando, pero hay un sarcasmo implícito en la comunicación que engendra más sarcasmo, indirectas, doble sentido y críticas. Cabe hacer notar que no es necesario gritar para ser hiriente con los demás
  • Falta de interés en resolver el conflicto, relaciones fracturadas presentan esta característica que tiene que ver con que ya todos se acostumbraron al conflicto, que les incomoda, pero no quieren hacer nada para resolverlo

Una vez percibido el conflicto, el ScrumMaster deberá analizar cuáles son las causas y las alternativas que se podrían tomar. Desde su rol empoderante no es recomendable que el ScrumMaster termine el conflicto con un grito y les diga a todos cómo comportarse. 

Por el contrario, es necesario que el ScrumMaster le haga ver al equipo y/o personas en conflicto cuáles podrían ser sus posibles reacciones, por ejemplo:

  • Negar el conflicto, es decir caer en el acto de negación y decir cosas como “aquí siempre nos gritamos, pero al final somos todos amigos” 
  • Ceder todo el tiempo parecería ser una forma de aplacar el conflicto, pero en realidad puede agravarlo pues el problema subyacente no se está resolviendo; ceder también podría ser un síntoma de desinterés e indiferencia
  • Abrumar al otro usando todos los recursos y argumentos con tal de ganar la discusión
  • Retirarse del conflicto simplemente terminando la discusión lo más pronto posible o bien quedándose callado mientras dure la discusión 

Si bien no hay una forma perfecta de reaccionar ante el conflicto, mientras más se estudie y se eduque al equipo acerca de este tema más chances tendremos que este puede reaccionar de manera positiva y lidiar efectivamente con él. 

Liderazgo Servicial

Existen varios tipos de liderazgo y un ScrumMaster debe estar preparado para adoptar el que más convenga en una situación particular. De todos estos estilos de liderazgo posiblemente el que más trabajo cuesta desarrollar es el de liderazgo servicial pues implica, no solo un trabajo conceptual, sino también el dominio del propio ego [Sinek17].

Dominar el ego es fundamental si un líder piensa en servir a los demás con la intención de que otros crezcan y se beneficien ellos con su propio crecimiento. Implica también reconocer que el crecimiento del líder no es hacia arriba en una escala jerárquica sino hacia dentro de sí mismo.

Si bien no existe una medida de que tan buen o mal líder servicial uno puede ser existen ciertos atributos que se pueden observar:

  • Pensar primero en los demás, es decir apuntar a que los demás están antes que uno mismo o como Sinek [Sinek17] diría dejar que los demás coman primero como un acto de generosidad y respecto
  • Comunicarse hábilmente dejando de lado cualquier forma poco efectiva, sarcástica o hiriente de comunicación; aprender a comunicarse es en sí un camino que requiere práctica y estudio pues todos podemos hablar mas no comunicarnos
  • Ser un pensador sistémico que no solo considera el aquí y el ahora, sino que ve más allá a través de los efectos e implicancias de cada decisión e interacción con las personas

De la misma manera que un ScrumMaster apunta a ser un líder servicial para el equipo también debe serlo para la empresa; empresas en las cuales se va trabajando este tipo de liderazgo tienden a una transformación más profunda producto de la cual los trabajadores pueden llegar a sentirse más empoderados, creativos y como parte activa de la empresa misma.

El liderazgo servicial no es una receta mágica para liberar el poder creativo de un equipo y una empresa, es una herramienta más que puede ayudar a que la gente comience a sentirse segura y a experimentar.

Parafraseando a Hamel [Hamel07] el futuro de una empresa es incierto y mientras más aprendan y experimenten los empleados de esta, más chances tendremos de llegar ahí, donde quiera que esté el siguiente gran producto de la empresa.

Conclusiones

El camino de crecimiento del ScrumMaster no termina en realidad nunca pues implica un aprendizaje constante o como diría Taiichi Ohno ser un eterno estudiante [Ohno13].

Si bien Scrum es solo un marco de trabajo ligero de fondo ofrece la oportunidad de ser visto como un camino, como un “do” en el sentido de las artes marciales japonesas y como tal, no solo es importante hacia donde nos lleva sino también cada paso que demos en él. 

Bibliografia

Hamel07 Hamel G., 2007. The Future of Management, Harvard Business Review Press

Kaner07 Kaner S., 2007. Facilitators Guide to Participatory Decision-Making, Jossey-Bass; 2nd edition

Sinek17 Sinek S., 2017. Leaders Eat Last: Why Some Teams Pull Together and Others Don’t, Portfolio; Reprint, Revised edition

Ohno13 Ohno T., 2013. Taiichi Ohno’s Workplace Management, McGraw Hill

Sirviendo a La Empresa

Introducción

Tradicionalmente se concibe al ScrumMaster como un removedor de impedimentos, pero esta tarea puede ser exhaustiva, frustrante y que no aproveche totalmente el potencial del ScrumMaster. Más aún, depender de un ScrumMaster para remover impedimentos no crea una cultura de autoorganización dentro de un equipo y más bien fomenta la existencia de un recurso crítico. 

Ideas interesantes vienen de fuentes inesperadas como la tripulación de un submarino. David Marquet [Marquet13] cuenta la historia de cómo el empoderamiento de la tripulación de un submarino que en teoría él comandaba los llevó a niveles de excelencia desarrollando el potencial pleno de cada submarinista. 

En el caso de Marquet fue él quien se dio cuenta que no estaba capacitado para dar todas las órdenes y que el conocimiento pleno no le pertenecía y por tanto dio el salto de fe y delegó esa responsabilidad a los que realmente hacían el trabajo. Este estilo de liderazgo documenta en un nuevo contexto el potencial del empoderamiento y la autoorganización. 

Quizás venga siendo tiempo de que los ScrumMasters se reinventen a sí mismo como influenciadores y educadores de la alta gerencia para que así sea esta la que dirija la transformación de la empresa hacia la agilidad.

El Cambio Organizacional si es Posible

El cambio hacia organizaciones de jerarquía plana, donde existe el empoderamiento y la autoorganización, pero donde además existen utilidades y la empresa continua no solo siendo viable sino también crece, es posible tal como lo documenta Frederic Laloux [Laoux14] en su estudio que incluyó empresas de gran escala y con más de una década de existencia.

En su ya clásico libro, Gary Hamel [Hamel07] visionariamente identifica varias características que tendrán el management futuro que se aleja de los dogmas y explora enfoques más empoderantes y centrados en la gente. 

Hamel sostiene postulados como: “sin jefes, pero con muchos líderes” que podrían sonar revolucionarios y anárquicos pero que en realidad promueven fomentar la cultura de formar líderes cercanos al gemba que entiendan mejor la problemática del trabajo y ayuden efectivamente con la mejora continua.

En el rol de ScrumMaster no solo se es uno de esos líderes sino también se es el promotor y coach de la gerencia que internaliza este cambio en la forma de concebir el management. 

Un punto importante por reconocer es que el promotor u opositor del cambio organizacional siempre acaba siendo la cabeza de una organización y por tanto por ahí es por tanto por donde se debe empezar [Ballé14].

Escalando Scrum

Existen varios enfoques y propuestas para escalar Scrum, por nombrar algunas: Large Scale Scrum (LeSS), Disciplined Agile Delivery (DAD), Scrum at Scale y Enterprise Scrum.

Mi preferencia personal se inclina por LeSS debido a dos motivos: primero porque fue desarrollado por sus creadores en años de trabajo con equipos reales en diferentes lugares del mundo y segundo porque mantiene la simplicidad de Scrum.

LeSS sigue siendo Scrum con algunas adiciones, pero a su vez se basa en varias disciplinas aliadas, lecciones experimentalmente aprendidas y sólidas prácticas de ingeniería [Larman08].

Un punto importante a recordar con LeSS es que no promueve el escalamiento sin control sino más bien el de-escalamiento ya que sostiene el principio de que mucho software de calidad se puede construir con poca gente siempre y cuando esta tenga el conocimiento, la disciplina necesaria y este dispuesta a ir mejorando sus prácticas continuamente.

Conclusiones

Es posible hacer que Scrum funcione bien no solamente para un equipo de manera aislada sino para varios equipos y para toda la empresa en su conjunto, pero para que esto ocurra se requiere de un cambio en el pensamiento y la forma de trabajo.

El cambio debe necesariamente incluir a la alta gerencia pues sin ella simplemente se quedará a medio camino y alcanzará resultados subóptimos.

Scrum tiene el potencial de ser el catalizador que produzca una profunda transformación dentro de una empresa. El ScrumMaster es quien inicia esta transformación, pero es la gente misma dentro de la empresa la que es responsable en última instancia de su propio destino.

Bibliografia

Marquet13 Marquet D., 2013. Turn the Ship Around!: A True Story of Turning Followers into Leaders, Portfolio

Laloux14 Laloux F., 2014. Reinventing Organizations, Nelson Parker

Hamel07 Hamel G., 2007. The Future of Management, Harvard Business Review Press

Ballé14 Ballé M., Ballé F., 2014. Lead With Respect A Novel of Lean Practice, Lean Enterprise Institute

Larman08 Larman C., Vodde B., 2008. Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum, Addison-Wesley Professional