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.

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.

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 

Sirviendo al Product Owner

Introducción

El rol del Product Owner es de alto valor estratégico pues traza la dirección en la cual ira un producto construido por un equipo de desarrollo. Muchas veces este rol es confundido por el de alguien que simplemente escribe requerimientos detallados y se los pasa al equipo para que este los implemente sin desviarse.

En otros casos el rol del Product Owner es mimetizado con el de un Project Manager que hace que el cronograma se cumpla y se entregue un producto que puede que tenga o no calidad o peor aún, que puede o no que vaya a resolver alguna necesidad de clientes reales.

Desde los inicios del movimiento eXtremme Programming se vio la necesidad de tener como parte de un equipo a alguien que tenga conocimiento del negocio e interactúe efectivamente con los stakeholders [Beck99]. Scrum enfatiza más esta figura al crear un rol e introducir el término “Product Owner” que implica que de hecho la persona en este rol tiene poder de decisión sobre el producto.

Es muy común escuchar que la herramienta principal del Product Owner es el Producto Backlog, lo cual es una verdad a medias pues existen muchas otras herramientas y conocimiento de otras disciplinas que pueden ayudar a que el Product Owner se desempeñe mejor en su rol. Es labor del ScrumMaster conocer estas herramientas y técnicas para poder pasárselas al Producto Owner a través de coaching y mentoría.

Pasos para Descubrir el Producto y el Product Backlog

Antes de pensar en crear un Product Backlog existen ciertos pasos que muchas veces por ser ignorados repercuten a la larga en un producto que no resuelve problemas o los resuelve de manera muy costosa.

El primer paso fundamental es entender el sistema dentro del cual habitará el producto; es decir no solo pensar en un producto como tal sino enfocarlo desde una perspectiva sistemática. Es vital entender que no solamente se trata de darle al cliente lo que pide sino ver cuáles son las variables que se verán afectadas por este curso de acción [Larman17]. 

El segundo paso a partir de entender el sistema consiste en diagnosticar cuál es el problema que se tratará de resolver con el producto que se construirá. Desde una perspectiva Lean el producto no resuelve el problema, lo mitiga y habrá que evolucionar el producto buscando cada vez mejores mitigaciones. 

El tercer paso consiste en evaluar con el equipo de desarrollo la factibilidad del producto, desde luego esta validación debe no sólo incluir la perspectiva técnica sino también financiera, legal, de mercadeo, etc. Aquí aparece una trampa muy frecuente que consiste en invertir mucho tiempo prototipando y explorando antes de proseguir con la construcción del producto real; precisamente la agilidad se trata de minimizar este tiempo y validar dentro del gemba.

El cuarto paso consiste en descubrir qué tendrá el producto, es decir, qué características (features) serán incluidas, para qué usuarios, y cómo estas se beneficiarán usándolas [Watts17]. Las técnicas de Juegos de Innovación (Innovation Games) descritas por Hohmann [Hohmann07] han probado en la práctica ser de gran ayuda a la hora de entender y descubrir el producto. Una recomendación importante es utilizarlas dentro de un workshop presencial en el cual se tenga un grupo de trabajo compuesto por stakeholders reales, el Product Owner, algún miembro del equipo de desarrollo y el ScrumMaster como facilitador.

El quinto paso consiste en poner todas las ideas juntas en un Product Canvas [Pichler10] en el cual resulta también muy conveniente comenzar a bosquejar cómo lucirá la interfaz del producto.

El sexto paso implica descubrir cuáles serán los PBI que se incluirán en el backlog y tratar de ordenarlos, User Story Mapping [Patton14] es la técnica mejor equipada para esta tarea.

El séptimo y a veces controversial paso es estimar los PBI del Product Backlog. Este paso es controversial por lo que la estimación implica. Hay que recordar que las estimaciones son solamente eso estimaciones y no compromisos y que además serán reestimadas constantemente a medida que avancemos en el desarrollo del producto. De hecho, una estimación no es más que un marcador de posición para recordar que después hay que seguir discutiendo y refinando el entendimiento respecto al PBI.

El octavo y último paso consiste en trazar la estrategia del producto [Pichler16], la estrategia tiene un componente importante que es el Release Plan que a su vez incluye la definición de frecuencia de los releases. El Release Plan debe incluir también la alineación del desarrollo de software con las áreas circundantes, por ejemplo, con un plan de marketing, aprovisionamiento de infraestructura, redacción de contratos, etc.

Finalmente, cualquier que sea el producto descubierto, el backlog creado y el Release Plan escrito hay que siempre recordar que no es definitivo, que por el contrario debe e irá cambiando y ese es precisamente el punto de la agilidad.

Ver el Backlog Como Sólo una Lista

Una de las grandes confusiones que he observado en muchas empresas y equipos es la sobre-complejización del concepto de backlog. Herramientas online para Agile Lifecycle Management añaden complejidad adicional con terminología, interface y opciones que hay que aprender para poder usar la herramienta. 

Algunos Project Managers también contribuyen a la confusión pensando que el backlog es una especie de gráfica Gantt unidimensional y en el cual hay que aplicar un proceso de control de cambios para realizar cualquier movimiento.

Una simplificación de este concepto viene de la mano del trabajo de Richardson [Richardson05] que desde el pragmatismo nos invita a pensar en el backlog (cualquiera que sea este) como en una lista de cosas por hacer o cosas por comprar en un supermercado.

Si seguimos el enfoque anterior una lista debe tener las siguientes características:

  • Públicamente visible y disponible, es decir no hay una lista secreta del Product Owner y otra del equipo sino una sola lista que todo el mundo puede mirar y cambiar
  • Priorizada, pero utilizando varios criterios de priorización, no solamente la estimación de cuánto durará en implementar un ítem
  • En una línea de tiempo que implica que debe haber un horizonte cercano que indica cuándo deberían terminarse los ítems de la lista, si el tiempo se agota antes de completar todos los ítems pues no se implementan algunos de baja prioridad
  • Activa y no estática, es decir que va cambiando con el tiempo en función del aprendizaje del equipo de desarrollo, del mismo Product Owner y de los stakeholders
  • Medible que implica que se puede determinar en un criterio binario cuando algo se ha completado o no
  • Con un objetivo claro que quiere decir que estamos implementando ítems de un producto, no ítems por si acaso que luego de implementados se archivarán para no usarse nunca

Herramientas Para Mantener un Product Backlog

En el mercado actual de herramientas online existe una gran variedad que van desde las que hacen una sola cosa hasta las que son partes de un ecosistema y posibilitan la trazabilidad entre herramientas.

Un denominador común que he podido observar en estas herramientas es que están orientadas a generar reportes para la alta gerencia, es decir agregan información y permiten ver quién movió qué tarjeta a qué estado y cosas por el estilo.

La otra característica dominante es que estas herramientas no permiten gran experimentación ya que vienen con opciones y terminología definida que apunta a la estandarización de procesos. Recuérdese aquí que bajo un enfoque Lean nosotros queremos flexibilidad en las herramientas que nos permita kaizen de mejora continua.

Ante este panorama una alternativa muy simple es usar hojas de cálculo compartidas (Google Spreadsheets) para mantener el backlog y un wiki para detallar cualquier PBI. Aunque esto parezca poco tecnológico respeta el principio de simplicidad en las herramientas, economiza costos, promueve la experimentación, reduce la curva de aprendizaje y facilita la comunicación.

No es solamente mi experiencia personal la que permite decir que equipos de desarrollo con herramientas simples como las descritas pueden trabajar efectivamente, sino que es un hecho observado a gran escala tal como documenta Larman [Larman10].

Tratar de Incluir al Product Owners en el Equipo

Idealmente el Product Owner debería ser parte integral y a tiempo completo del equipo de desarrollo, pero la figura del outsourcing muchas veces distorsiona esta condición ideal.

Si el Product Owner pertenece a la compañía que contrata los servicios de outsourcing y además vive en otro país es muy recomendable que viaje por lo menos una vez al mes para pasar tiempo con el/los equipos con los que trabaja remotamente.

Tener la presencia física del Product Owner resulta muy valioso no a la mitad de un Sprint porque eso provocaría interrupciones sino al final para el Sprint Review, el Sprint Retrospective y el Sprint Planning que vendría al día siguiente. 

Si el Product Owner participa en las retrospectivas podrá escuchar de primera mano los problemas e ineficiencias que el equipo mencione además de poder aportar su visión desde afuera. 

De igual manera el estar presente le permitirá escuchar cómo su rol es percibido por el equipo y las ineficiencias que el equipo puede observar en su accionar.

Un tercer beneficio es que la presencia del Product Owner añade una visión más conectada al negocio a la hora de proponer kaizens de solución de problemas o kaizens de mejora continua.

Conclusiones

Los Product Owners tiene el potencial de redefinir el panorama de las industrias en las que trabajan a través de la creación de productos innovadores pero tal cosa no ocurrirá si carecen de una mentalidad ágil y emprendedora reforzada por un sólido conocimiento del negocio y de la teoría, técnicas y herramientas propias de su artesanía.

La práctica es esencial y considero más enriquecedor que un Product Owner cree varios productos en un horizonte de digamos cinco años a que trabaje en solamente mantener un sistema operando por el mismo periodo de tiempo.

Finalmente quiero enfatizar una vez más un concepto fundamental: el rol del Product Owner y de hecho la idea detrás de un Equipo Scrum, es tener un equipo altamente efectivo y motivado que construya un producto que impacte en el mercado.

Bibliografia

Beck99 Beck K., 1999. Extreme Programming Explained: Embrace Change, Addison-Wesley

Larman17 Larman C., Vodde B., 2017. Large-Scale Scrum More with LeSS, Addison-Wesley

Watts17 Watts G., 2017. Product Mastery: From Good to Great Product Ownership, Inspect & Adapt Ltd

Hohman07 Hohman L., 2007. Innovation Games: Creating Breakthrough Products Through Collaborative Play, Addison-Wesley Professional

Pichler10 Pichler R., 2010. Agile Product Management with Scrum: Creating Products that Customers Love, Addison-Wesley Professional

Patton14 Patton J., 2014. User Story Mapping: Discover the Whole Story, Build the Right Product, O’Reilly Media

Pichler16 Pichler R., 2016. Strategize: Product Strategy and Product Roadmap Practices for the Digital Age, Pichler Consulting

Richardson05 Richardson J., Gwaltney W., 2005. Ship it!: A Practical Guide to Successful Software Projects, Pragmatic Bookshelf

Larman10 Larman C., Vodde B., 2010. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Addison-Wesley Professional

Sirviendo al Development Team

Introducción

Toyota décadas atrás acuñó esta frase que representa su cultura “Great people make great products” [Ohno13]. La frase representa el enfoque hacia el individuo que a su vez utiliza su creatividad y motivación para construir cosas asombrosas.

Toyota entre otras contribuciones fue la primera compañía automotriz en concebir su producción alineada no en torno a los procesos, las herramientas, la materia prima o el capital; sino más bien en torno a los trabajadores que empoderados iban experimentando con mejores formas para hacer su trabajo.

El enfoque Toyota ha tratado de ser copiado en muchos países e industrias, pero simplemente no se puede copiar el ingrediente secreto: la gente. 

Similarmente en Scrum se hace un énfasis muy fuerte en equipos autoorganizados, empoderados, motivados, donde nadie tiene la razón todo el tiempo, donde se experimenta y aprende constantemente.

Como tal, un ScrumMaster no estaría haciendo nada que un coach o supervisor en Toyota no haya hecho antes, la gran diferencia está desde luego en que un equipo que hace software no es igual que un equipo que manufactura partes en una línea de producción de Toyota. Sin embargo, un principio fundamental si es extrapolable: líderes como profesores y coaches que sirven a los equipos.

La Panacea de la Autoorganización

La autoorganización no es para cualquiera, no a todo el mundo le gusta la idea de que no haya un jefe que le diga cómo y cuándo hacer las cosas. De hecho, para muchos equipos resulta intimidante pensar que de aquí en más ellos son dueños de sus propias decisiones.

Algo que ayuda a mitigar el miedo inicial a la autoorganización es clarificar el hecho de que no porque un equipo sea autoorganizado carece de líderes que ejercen un tipo de liderazgo por conocimiento o influencia, pero no por autoridad jerárquicamente establecida. 

En el operar de un equipo autoorganizado es frecuente ver que los miembros del equipo tienden a seguir a alguien que conoce más de algún tema, o quien aprendió algo nuevo y quiere enseñarlo, o algún otro miembro del equipo que tiene una idea brillante o sabe cómo resolver un problema. 

Como corolario podríamos decir que los líderes siguen existiendo en un equipo autoorganizado y que su liderazgo es rotativo y basado en un estilo distanciado del autoritarismo y la jerarquía.

El Reto de la Autoorganización Constante

Una vez vencido el miedo inicial a la autoorganización surge el siguiente desafío: cómo mantener al equipo autoorganizado a lo largo del tiempo. Una práctica muy humana es que ante el menor problema tendemos a volver a los viejos hábitos, aunque sepamos que estos no sean los correctos; es decir que ante la presión de la gerencia o con los tiempos encima un equipo deja de lado la autoorganización para volver al modelo de ser dirigidos por un Project Manager que lo sabe todo. 

Algo que ayuda a mantener la autoorganización a lo largo del tiempo es tener un equipo altamente motivado. Desde esta perspectiva, si inferimos que la motivación impactará positivamente en la autoorganización deberíamos empezar a buscar herramientas que nos ayuden a mantener alta la motivación de un equipo.

Daniel Pink [Pink11] nos presenta un modelo que explica los factores que mantienen motivados a los individuos, su modelo considera estos componentes:

  • Autonomia
  • Maestria
  • Propósito

Experimentalmente he aplicado este modelo con equipos de desarrollo de software y puedo decir que efectivamente contribuye no solo a mantener alta la motivación sino también a crear un ambiente de aprendizaje continuo.

Mitos Acerca de Equipos Autoorganizados

Los equipos autoorganizados han generado varios mitos a lo largo de los años en las organizaciones que han experimentado con ellos. La siguiente es una lista de los mitos que he podido escuchar:

MITO REALIDAD
Los equipos autoorganizados no saben cómo hacer una retrospectiva. No solamente los equipos autoorganizados tienen este problema, por eso es que en Scrum se tiene el rol del ScrumMaster que facilita las retrospectivas
Las estimaciones de los equipos autoorganizados son las peores No hay información estadística creíble que muestre una clara correlación entre la autoorganización y la precisión de las estimaciones 
Los equipos autoorganizados son los que más deuda técnica acumulan porque nadie está mirando la calidad del código  La autoorganización combinada con maestría, programación entre pares, revisiones de código y otras prácticas hacen que la calidad global del código suba y el conocimiento se disemine
En un equipo autoorganizado cuando se va un miembro todo su conocimiento se va con él En cualquier equipo donde se tienen silos de conocimiento este riesgo siempre estará presente. La autoorganización bien orientada a romper silos de conocimiento tiende a mitigar grandemente este riesgo
Los equipos autoorganizados sirven para iniciar una revolución interna dentro de una empresa con el fin de conseguir reivindicaciones laborales y económicas Si los trabajadores no son justamente compensados o si sus condiciones laborales en general no son buenas, desde luego que habrá un descontento que se podrá manifestar a través de un sindicato. Cabe hacer notar que si bien los sindicatos también son autoorganizados nada tienen que ver con equipos de desarrollo que se autoorganizan para trabajar

Considero que parte de la labor del ScrumMaster como coach es ayudar a que las personas y las empresas comiencen a cuestionar los mitos y dejen de considerarlos como verdades que impiden pensar en tener equipos autoorganizados.

Dinámicas de los Equipos

Para empezar, distingamos entre un grupo de personas y un equipo, si bien el segundo está formado por personas este tiene características sinérgicas y de comportamiento que lo hacen más creativo y productivo que un grupo de personas que simplemente trabajan juntas.

Estas son algunas de las características más sobresalientes de un equipo:

  • El liderazgo surge en demanda (on-demand) y nunca se carece de él
  • Está presente la habilidad para lidiar con conflictos
  • Todos los miembros del equipo manifiestan libremente sus opiniones y estas son valoradas y respetadas
  • Las normas y acuerdos de trabajo del equipo son conocidas y respetadas por todos los miembros
  • Los miembros del equipo comparten objetivos y motivaciones comunes
  • Los miembros del equipo se exigen responsabilidad y compromiso entre ellos mismos
  • El equipo lleva bastante tiempo (muchos meses e idealmente años) conformado por los mismos miembros
  • El equipo está formado por miembros que trabajan a tiempo completo

Si hablamos más en particular acerca de un equipo ágil encontraremos atributos claves como:

  • Reglas básicas siendo seguidas y en constante inspección y adaptación
  • Conciencia de las capacidades y competencias, así como de las limitaciones y temores de cada miembro del equipo
  • Colaboración efectiva y eficiente entre los miembros del equipo

Evitar la Homogeneidad, Tratar la Diversidad 

Una tendencia clásica a la hora de formar equipos es la de buscar miembros de equipo que sean los más parecidos entre ellos considerando aspectos como educación, formación académica, género, edad, etnicidad, estrato social, creencias, valores, etc. 

Contrariamente a lo que parecería estos equipos tienden a carecer de autocrítica y pensamiento creativo, tienden a más inestabilidad, conflicto y se disuelven más rápidamente [Pfeffer06].

Una alternativa más prometedora es formar equipos en los cuales la diversidad sea una característica. De todas las combinaciones posibles una de las más básicas es tener diversidad de género.

A partir de la diversidad de género se puede ir explorando varias opciones como:

género —> edad —> etnicidad —> formación académica —> etc.

Una advertencia importante, la diversidad necesita de la co-locación para que el equipo pueda engranar [Larman10]. Experimentalmente puedo decir que la diversidad en equipos globalmente distribuidos puede crear barreras de entendimiento y comunicación retardada que eventualmente afectan al producto.

La Obsesión de Medir el Rendimiento del Equipo

Una de las formas más efectivas de matar la colaboración y transparencia dentro de un equipo es ofrecer premios o incentivos individuales; los incentivos se enfocan en incrementar el rendimiento individual dejando en segundo término el rendimiento colectivo y la colaboración.

El rendimiento tampoco puede medirse con una sola métrica, es más cualquiera que sea la métrica usada los miembros del equipo pueden ingeniárselas para burlarla y así conseguir el incentivo. 

Por otro lado, factores como estabilidad laboral y psicológica tienden a mantener a los miembros del equipo tranquilos y colaborando. Nótese que por estabilidad laboral me refiero a que el trabajador no será despedido pero el tipo de trabajo que hará irá cambiando; es decir, debido al entrenamiento y funcionalidad cruzada los miembros del equipo aprenden y hacen más de un tipo de trabajo. 

Acuerdos de trabajo que promuevan el respecto, el aprendizaje y la colaboración constante también tienen un impacto positivo en el rendimiento global del equipo.

Objetivos comunes y beneficios compartidos con la empresa cuando el producto se vende bien en el mercado históricamente también han probado tener un efecto positivo en el rendimiento.

Formando Equipos Nuevos

Los equipos no se forman de la noche a la mañana, de hechos hay modelos teóricos que postulan que existen varias etapas que un equipo debe atravesar para comenzar a considerarse operativo.

Si hablamos de formar un equipo completamente nuevo el primer paso será el reclutamiento de sus miembros. Mucho se ha hablado y escrito acerca de cómo entrevistar desarrolladores, pero el mejor consejo que puedo ofrecer es pedirles que desarrollen código real durante la entrevista.

Variaciones de sugerencia anterior pueden incluir sesiones de pair programming con el candidato o entrevistas colectivas con coding katas. El punto importante para no perder de vista es que la única forma de evaluar las capacidades de un desarrollador es ver como resuelve problemas con código.

Es factible construir un equipo altamente productivo sobre la base de un grupo de excelentes desarrolladores, pero es más costoso y a veces imposible hacerlo sobre la base de un grupo de desarrolladores que desconozcan las particularidades de su artesanía [McBreen01].

Definición de Terminado Creada por el Equipo

Una de las particularidades de un equipo de desarrollo autoorganizado es que tienen la responsabilidad de crear junto con el Product Owner su propia Definición de Terminado que se utilizará para calificar Product Backlog Items (PBI) como realmente completados.

Lo anterior produce muchas veces la confusión de pensar que la Definición de Terminado es estática, que se crea una vez y se mantiene inmutable por todo el ciclo de desarrollo de un producto. 

En realidad, lo contrario debería ocurrir, la Definición de Terminado es afectada por el kaizen que la fuerza a mejorar y la lleva cada vez más cerca de un ambiente de producción, es decir los PBIs se considerarán realmente terminados cuando puedan correr en un ambiente real de producción.

Haciendo un símil con Toyota, la Definición de Terminado es como el checklist final que debe pasar un automóvil con sus partes para considerarse realmente terminado y apto para la venta. 

Siguiendo con la analogía, el automóvil es el producto y cada parte y tarea de ensamblaje son los PBIs; desde luego de nada valdría tener partes que cumplan la Definición de Terminado si estas no conforman el producto final que es despachado al mercado.

Las siguientes son dos técnicas que empleo frecuentemente para la creación y representación de la Definición de Terminado:

  • Escritura en un papelógrafo de todos los pasos que debe seguir todo PBI para considerarse realmente terminado
  • Creación de una matriz donde en las filas van los PBIs y en las columnas los pasos del Definition of Done. Esta matriz permite rastrear cuál es el estado de un PBI en particular en términos de que pasos de la Definition de Terminado que ya ha cumplido vs cuáles le falta todavía cumplir.

El Valor de las Practicas de Ingeniería

Una medida muy simplificada del grado de conocimiento y disciplina de un equipo de desarrollo consiste en ver que prácticas de ingeniería ha internalizado y que tan frecuentemente las emplea.

De las muchas prácticas propuestas por eXtremme Programming [Beck04] no es necesario que un equipo las adopte todas o en un orden preestablecido. Sin embargo, hay algunas de ellas que son esenciales, a saber:

  • Integración continua en intervalos de tiempo cada vez más pequeños y sobre el repositorio central [Kim16]

Siguiendo el mantra de XP: Dividir —> Conquistar —> Integrar

  • Collective Code Ownership a través de Feature Teams que conozcan el código de todas las capas y componentes propios de un feature. Nótese aquí que no solo se trata de tener crossfunctional teams sino también de tener cross component teams [Larman10]
  • Refactorización constante que consiste en mejorar la lógica de una pieza de código sin que las salidas se vean alteradas [Kerievsky04]. Es muy difícil refactorizar con confianza si no se tienen tests que sigan confirmando que la salida no ha cambiado. Desde una perspectiva Lean la refactorización puede ser entendida como un kaizen de mejora
  • Diseño Simple que tiene que ver con mantener el diseño de un sistema o aplicación dentro de los límites de la comprensión sin añadir complejidad arquitectónica innecesaria [Fowler02]
  • Test Driven Development que de todas las prácticas de XP resulta ser la más complicada de internalizar y la que requiere mayor estudio y disciplina por la simple razón de que los desarrolladores no están acostumbrados (y muchas veces se resisten) a empezar a codificar primero por la prueba y respetando el ciclo de TDD [Beck02]

Las prácticas ingenieriles anteriormente descritas de ser correcta y disciplinadamente aplicadas permitirán que el equipo de desarrollo cree código y lo lleve a producción en intervalos muy pequeños de tiempo maximizando de esta manera la posibilidad de obtener feedback inmediato. En terminología Lean mientras más rápido se lleva a producción más se incentiva el flujo y más se reduce el tiempo de paso por la línea de producción.

Si pensamos en términos de escala y ahora tenemos múltiples equipos (más de ocho equipos cada uno con siete a nueve integrantes) se hace vital tener prácticas como TDD, integración continua y diseño simple para evitar tener en una incompresible masa de código.

Conclusiones

Vivimos en una era en la cual todos los sistemas simples que podían ser escritos por un desarrollador trabajando en solitario ya han sido escritos, por tanto, es de vital importancia asumir que todos los sistemas que se escriben y escribirán a futuro serán productos del trabajo colaborativo y sinérgico de equipos de desarrolladores.

Debido también a que el desarrollo de software requiere de un alto componente creativo ligado a la motivación y compromiso se hace de vital importancia para un ScrumMaster descubrir técnicas, herramientas y paradigmas que le permitan servir mejor al equipo de desarrollo del cual es parte.

Una recomendación final, el descubrimiento de estas técnicas, herramientas y paradigmas no debe ser un camino andado en solitario por el ScrumMaster sino más bien un camino en el cual todo el equipo se embarca.

Bibliografia

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

Pink11 Pink D., 2011. Drive: The Surprising Truth About What Motivates Us, Riverhead Books 

Pfeffer06 Pfeffer J., Sutton R., 2006. Hard Facts, Dangerous Half-Truths And Total Nonsense: Profiting From Evidence-Based Management, Harvard Business Review Press 

Larman10 Larman C., Vodde B., 2010. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Addison-Wesley Professional 

McBreen01 McBreeen P., 2001. Software Craftsmanship: The New Imperative, Addison-Wesley Professional 

Beck04 Beck K., Andres C., 2004. Extreme Programming Explained: Embrace Change, Addison-Wesley; 2nd edition 

Kim16 Kim G., Debois P., Willis J., Humble J., 2016. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations, IT Revolution Press

Kerievsky04 Kerievsky J., 2004. Refactoring to Patterns, Addison-Wesley Professional 

Fowler02 Fowler M., 2002. Patterns of Enterprise Application Architecture, Addison-Wesley Professional

Beck02 Beck K., 2002. Test Driven Development: By Example, Addison-Wesley Professional

Agile Coaching

Introducción

Uno de los términos más populares en los perfiles profesionales y de búsqueda de empleo es el de “Agile Coach”, como pasa con muchas otras cosas es un término fácilmente asumido pero muy poco entendido. 

Siguiendo la escuela de pensamiento Toyota un coach es un mentor que conoce tan bien el trabajo que puede enseñárselo a un trabajador e incluso reemplazarlo en caso de que este último no venga a trabajar. Es más, un coach de tanto en tanto vuelve al gemba para hacer trabajo de valor agregado para no desconectarse de la realidad y continuar mejorando sus destrezas [Ohno13].

Una noción diferente viene de la escuela que predica que un “professional coach” no necesita conocer el negocio y sus tecnicismos para poder hacer coaching eficiente. Esta segunda escuela de pensamiento se enfoca en pulir las habilidades de coaching aplicables a cualquier contexto.

Mi postulado personal es que un ScrumMaster debe alinearse con una corriente de coaching que le permita conocer tres facetas: el trabajo, el ser humano, y a sí mismo.

Respetando la Agenda del Cliente

Un coach debe anteponer la agenda del cliente por sobre la suya, es decir, los problemas, preocupaciones, ideas y opiniones del cliente tienen más valor que las del coach [Kimsey11]. Si estas están equivocadas, desde la perspectiva del coach, es labor del coach ayudar al cliente a que descubra por qué están equivocadas y pueda descubrir otras mejores. 

Muy frecuentemente he encontrado de primera mano y por terceros historias de Agile Coaches que van a una empresa y le dicen a la gente que todo o gran parte de lo que han estado haciendo por años está errado, que eso no es Ágil y que deben hacer esto o aquello porque ellos son los Agile Coaches contratados para evangelizarlos.

Este discurso no solo genera resistencia y anticuerpos, sino que no respeta el principio básico de coaching de “client agenda”. Más aún, crea la ilusión de que la agilidad es como un evangelio en el cual hay una única forma de hacer las cosas correctamente lo cual desde luego contradice los principios ágiles.

Manteniendo la Neutralidad

Quizás debido a que son las empresas las que pagan los servicios de los Agile Coaches no es extraño ver que estos se conviertan en la nueva versión de los capataces que presionan a los trabajadores para producir más a toda costa. 

Si bien la agenda del cliente puede estar ligada con incrementar la productividad a toda costa y sacar el máximo beneficio del tiempo de los trabajadores, la labor del coach entonces tendrá que ver con que desde una neutralidad presentar opciones para quizás llegar a los mismos resultados pero siguiendo caminos diferentes.

La misma neutralidad deberá estar presente cuando los equipos quieran enfocarse a trabajar en cosas que no necesariamente aporten valor o insistir en mantener prácticas ingenieriles ineficientes: una vez más la idea no es que el coach les diga que eso está errado, sino que les ayude a descubrir mejores caminos.

Coaching Stances

Los coaching stances (posturas o actitudes) son diferentes modos bajos los cuales opera un coach y van cambiando de acuerdo con la necesidad del coachee y la circunstancias en las cuales interviene el coach.

Lyssa Adkins [Adkins10] identificó las siguientes posturas:

  • Coach como Coach-Mentor 
  • Coach como Facilitador
  • Coach como Profesor
  • Coach como Resolvedor de Problemas
  • Coach como Navegante de Conflictos
  • Coach como Conductor de la Colaboración

Cada una de estas posturas tiene en sí sus propias técnicas y características y cada una debe ser conocida y dominada por un Agile Coach.

Si bien es cierto que el talento natural y la preferencia personal harán que un Agile Coach se incline más hacia unas posturas que a otras y se desempeñe en unas mejor que en otras, esto no es excusa para no conocerlas todas.

De hecho, la habilidad de un Agile Coach está en la facilidad con la cual pueda cambiar de postura y evaluar cuál es la que le conviene adoptar en un momento y situación particular.

Técnicas de Coaching

Existen muchas organizaciones y coaches internacionales que han desarrollado varias técnicas de coaching aplicables desde el coaching uno-a-uno hasta el coaching a equipos. Como Agile Coach creo que el enfoque no debe estar en conocer todas las técnicas sino más bien en investigar, practicar y pulir la aplicación de unas cuantas.

Mi selección personal de técnicas se limita a estas tres:

  • Active Listening (escucha activa)
  • Powerful Questions (preguntas poderosas)
  • Reflection (reflexión) 

Más allá de las técnicas creo que su efectividad en la práctica está conectada con el grado de self-awareness que el Agile Coach haya podido desarrollar y por tanto el énfasis debe estar en conocerse a uno mismo primero.

Conclusiones

El coaching es un campo apasionante de una aplicabilidad muy grande en los equipos ágiles donde la interacción entre individuos a diferentes niveles se ve maximizada. Por lo anterior es de esperarse que la demanda de servicios de Agile Coaches tienda a crecer en los próximos años a medida que la corriente ágil siga ganando terreno.

Sin embargo, el embarcarse en la labor de Agile Coach requiere de un gran compromiso personal y disciplina para primero conocerse a sí mismo y luego todo lo que esta apasionante disciplina del coaching implica.

En las más que sabias palabras de Lao Tzu “Know yourself and you will win all battles”.

Bibliografia

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

Kimsey11 Kinsey-House H., Kinsey-House K., Sandahl P., Whitworth L., 2011. Co-Active Coaching: Changing Business, Transforming Lives, Nicholas Brealey; 3rd edition

Adkins10 Adkins L., Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, Addison-Wesley Professional

Facilitación Agil

Introducción

El trabajo de un ScrumMaster muchas veces requiere que este actúe de facilitador para que las discusiones dentro de los equipos se mantengan enfocadas, productivas, cortas y con un nivel adecuado de respecto y energía.

Como tal, el rol del facilitador tiene que ver con propiciar el flujo del diálogo sin monopolizarlo ni imponer conclusiones propias. Muy frecuentemente el rol de facilitador requiere resistir la gran tentación de decirle al equipo qué hacer y cómo hacerlo.

En otras oportunidades la facilitación tiene que ver con la rotura del silencio, es decir con formular la pregunta adecuada que genere una discusión valiosa [Schein13]. A veces la facilitación implica el realizar esa pregunta incomoda que nadie quiere hacer.

Cualquiera que sea el detonante, el ScrumMaster debe estar preparado y tener dentro de su caja de herramientas técnicas y conocimiento que le permitan actuar como un facilitador de la comunicación interna del equipo, así como también externa en la interacción del equipo con otros actores.

Estar o No Estar de Acuerdo

En muchas oportunidades los equipos pueden no estar de acuerdo acerca de aspectos técnicos del trabajo mismo y estos desacuerdos en el mejor de los casos son expresados verbalmente; muchas otras veces el desacuerdo está ahí subyacente, pero nadie en el equipo dice nada al respecto.

Una tendencia muy común es temerle al desacuerdo y tratar de evitarlo o ignorarlo; es decir, tratar de mantener una “armonía artificial” dentro de la cual todos parecen estar siempre de acuerdo y no tener opiniones encontradas. El problema con la “armonía artificial” es que es un indicador de un equipo disfuncional [LencioniI02]. 

Al igual que en los deportes y otros ámbitos, tener un equipo disfuncional rara vez conduce a un trabajo enfocado y productivo. Por el contrario, ventilar desacuerdos es una forma de atacar la disfuncionalidad y fortalecer el operar de un equipo.

Desde otra perspectiva, el desacuerdo es parte del interactuar de equipo. De hecho, es la base sobre la cual se va despertando el diálogo y la creatividad para converger en acuerdos.

Esquematizando un poco este modelo:

Divergencia ——-> Zona de Incomodidad ——-> Convergencia

La labor del ScrumMaster como facilitador no es evitar que el equipo ingrese en la “Zona de Incomodidad”, por el contrario, es propiciar que ingrese, se quede un corto tiempo y salga con un acuerdo de convergencia [Schwarz16].

Cabe hacer notar que la convergencia no quiere decir que la discusión condujo a la mejor solución y a la respuesta correcta, simplemente crea un acuerdo, hipótesis o idea que deberá ser validada en la práctica. Desde luego si la hipótesis o idea no da los resultados esperados el ciclo se repetirá.

Técnicas Para Ayudar a la Convergencia

En muchas oportunidades los equipos pueden enfrascarse en un debate que se extenderá por varios minutos y hasta horas; por supuesto que la conversación puede ser valiosa, pero sigue cayendo en el campo de las hipótesis. Hablando en lenguaje Lean, la conversación y el debate están distantes del gemba.

Estas son algunas técnicas que pueden resultar útiles para ayudar a que un equipo converja y quede de acuerdo en algo:

  • Votación usando los dedos de la mano (fist of five) donde cinco dedos quieren decir completamente de acuerdo, uno dedo es sinónimo de desacuerdo y tres dedos quieren decir apoyar lo que la mayoría decida
  • Votación con puntos (dot voting) en la cual se escriben las posibles ideas, alternativas u opciones en un papelógrafo y cada miembro del equipo debe colocar un punto al lado de la opción que prefiere
  • Voto de la mayoría (majority vote) consiste en recolectar los votos y gana la opción que obtiene el 51% o más del total de votos. Esta técnica puede resultar útil con equipos grandes y que estén geográficamente distribuidos, se puede implementar a través de un electronic poll teniendo cuidado de no tener demasiadas opciones para no dispersar los votos
  • Voto a través de una moción (decider protocol) que consiste en que alguien articule una propuesta de manera concreta, alguien más secunde la propuesta y luego se vota verbalmente o con las manos levantadas para ver si la moción tiene suficientes votos como para ser aceptada

En general no es recomendable que un ScrumMaster tome decisiones técnicas o de negocio sin conocimiento profundo de esos tópicos. Sin embargo, existen situaciones en las cuales el equipo presenta dos alternativas sobre las cuales no se ha podido escoger sin importar la técnica de facilitación que se usó. En un caso como el descrito el voto del ScrumMaster puede ser el de desempate solamente para sacar al equipo del empantanamiento.

Facilitación de la Escucha

Retrotrayendo un poco, en muchas oportunidades la facilitación se vuelve necesaria porque la gente del equipo simplemente no se está escuchando la una a la otra o si se escuchan no están entendiendo lo que la otra parte quiere decir.

Kaner [Kaner07] propone varias técnicas de facilitación que pueden ayudar a facilitar la escucha, por ejemplo, algunas de ellas son:

  • Apilamiento (stacking) que consiste en definir una secuencia para que hablen varias personas que tratan de hablar al mismo tiempo
  • Parafrasear que consiste en repetir usando términos similares lo que una persona dijo y preguntarle si se capturó la esencia de la idea
  • Pedir ejemplos más concretos (drawing people out) ayudan a que no solo quien propone sino quienes escuchan entiendan mejor la esencia de la idea
  • Abriendo el espacio (making the space) para personas en el equipo que no hablaron o hablaron muy poco. Esta técnica es especialmente válida para conectarse con aquellos individuos de personalidad introvertida que pueden no haber entendido la idea y no se animan a preguntar

Las técnicas de escucha son una valiosa herramienta en el repertorio de un ScrumMaster pues cómo ya dijimos ayudan a facilitar la comunicación a partir del mejor entendimiento de lo que la otra parte quiso decir.

Conclusiones

Es muy cierto que una de las facetas principales de un ScrumMaster es la de facilitador, pero también lo es que esta no puede ser la única ni tampoco consumir todo el tiempo del ScrumMaster. Idealmente se debe a apuntar a cultivar un estilo de liderazgo que promueva dentro del equipo una cultura de autofacilitación [Hackman02]. 

La facilitación partiendo desde la escucha o mejor aún la facilitación de la escucha efectiva es una de las mejores herramientas que tiene un ScrumMaster para ayudar a que un equipo converja en una idea, se ponga a experimentarla y así la valide.

Bibliografia 

Schein13 Schein E., 2013. Humble Inquiry: The Gentle Art of Asking Instead of Telling, Berrett-Koehler Publishers; 1 edition

Lencioni02 Lencioni P., 2002. The Five Dysfunctions of a Team: A Leadership Fable, Jossey-Bass; 1st edition

Schwarz16 Schwarz R., 2016. The Skilled Facilitator: A Comprehensive Resource for Consultants, Facilitators, Coaches, and Trainers, Jossey-Bass; 3rd edition

Hackman02 Hackman R., 2002. Leading Teams – Setting the Stage for Great Performances, Harvard Business Review Press

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