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 agilitas 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 agilita se enfrentó, enfrenta o enfrentará. Dicho de otra manera, los libros muestran todos los problemas que uno podría encontrar con multiples 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 

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

Toyota, Lean, Agile y Scrum

Introducción

Mucho se ha dicho y escrito acerca de Toyota y cómo sus prácticas han revolucionado (o al menos intentado) el entorno de trabajo de empresas de diferentes rubros a nivel mundial.

Toyota ha sido la piedra fundamental sobre la cual los principios Lean se crearon y estos a su vez influenciaron grandemente la corriente Ágil y el marco de trabajo Scrum.

Sin embargo, dentro de Scrum muchas veces olvidamos volver a las raíces para así entender por qué hacemos las cosas. Scrum se ha vuelto popular pero más mucha gente sigue desconociendo los pilares sobre los que se funda y esto trae consigo consecuencias negativas.

La Máquina que Cambió el Mundo

Los automóviles han tenido una gran influencia en la transformación de las sociedades y su forma de fabricación ha sido definitiva a la hora de influenciar la manufactura global.

De hecho, ninguna otra máquina en la era moderna ha tenido una influencia tan grande en la forma como se han organizado trabajadores, materiales, capital, conocimiento y equipos [Womack07]. 

Una forma de organización más eficiente (evitando las varias formas de desperdicio) conduce a una mayor producción mejor alineada con el mercado y a su vez impacta positivamente sobre el ánimo y bienestar de los equipos: de aquí la recomendación de los ScrumMasters conozcan y apliquen los principios de manufactura Lean.

La Esencia del Pensamiento de Toyota

Taiichi Ohno [Ohno13] resume de manera muy acertada un principio fundamental: la percepción errada que proviene del distanciamiento del gemba. Para clarificar estos errores de percepción Ohno sugiere una práctica simple “Go and see”.

Por desgracia este principio no se ve frecuentemente dentro de los equipos Scrum en los cuales se pretende supervisar o evaluar el trabajo a través de reportes e indicadores visuales. 

Un segundo principio fundamental es “stop and fix” que literalmente quería decir para Toyota detener la línea de producción en cuanto se detectaba un problema de calidad, aplicar la técnica de los “cinco whys” para encontrar la raíz del problema, mitigar (no encontrar la solución perfecta) y luego reanudar la línea de producción.

El principio de “stop and fix” tenía también un segundo propósito: forzar el aprendizaje. En general los adultos, o al menos no todos, no quieren seguir aprendiendo y por tanto un mecanismo como este forzaba a que dejen de trabajar, reflexionen acerca de qué no está funcionando bien, planteen posibles mitigaciones y luego experimenten poniéndolas en práctica.

Contrariamente a “stop and fix” en los equipos Scrum muy frecuentemente se observa que los defectos se van apilando y hasta se crea un backlog para ponerlos allí, priorizarlos y no perderlos de vista; esta práctica no solo rompe el principio Toyota, sino que además no contribuye a mejorar las practicas ingenieriles ni el conocimiento de los desarrolladores. Hacer más mal trabajo de baja calidad o hacerlo con predictibilidad no contribuye positivamente al producto que continuará acumulando deuda técnica y deuda de aprendizaje.

Si bien la lista de principios Toyota [Liker04] se extiendo bastante mencionaremos aquí solamente uno más: “kaizen al infinito”. Este principio tiene que ver con el aprendizaje continuo y con cultivar un ambiente de gente con conocimiento elevado que hace productos excelentes [Senge90].

Muy frecuentemente encuentro ScrumMasters que andan en busca de las “mejores prácticas de Scrum” las cuales en realidad no existen y si las hay son dependientes de un contexto particular no fácilmente replicable o extrapolable. En lugar de eso, la labor del ScrumMaster debería volcarse más a construir un ambiente de aprendizaje continuo donde se experimenten con diferentes prácticas. Parafraseando a Senge [Senge90] el factor diferenciador de una empresa (y consecuentemente de un equipo) es el grado de conocimiento adquirido y las ganas de seguir aprendiendo.

Lean, Respeto y Desperdicios

El enfoque de manufactura Lean puede resumirse de manera muy genérica a través de la siguiente formula [Ballé14]: 

LEAN = RESPECT + KAIZEN

Donde RESPECT se refiere al respeto por los trabajadores, su creatividad y el deber que tiene la gerencia de proveer las condiciones necesarias para que estos desarrollen su máximo potencial.

Desde un enfoque más estratégico Lean podría ser conceptualizado a través del siguiente esquema:   

Desde una perspectiva tradicional el enfoque Lean tiende a maximizar las actividades que generan valor en el producto y a reducir las actividades que generan desperdicio. El desperdicio a su vez puede clasificarse como: desperdicio inmediato que deber ser reducido ahora o desperdicio identificado para el cual no hay una mitigación inmediata.

Si hablamos de formas de desperdicio, existen algunas que son clásicas:

  • Trabajadores sobrecargados y estresados
  • Cuellos de botella
  • Espera en cola
  • Handoff
  • Ilusión 
  • Diseminación de la información

Y muchas otros más que están presentes y son particulares a cada equipo.

Por tanto, la labor de un ScrumMaster es contribuir positivamente a crear una cultura dentro del equipo que tienda a valorar el respecto, practicarlo, extenderlo e identificar a través de él las diferentes formas de desperdicio y tratar de mitigarlas. 

Lo opuesto de lo anterior sería una cultura de no-respeto en la cual los desperdicios no son identificados, y si lo son nadie hace nada al respecto, y la motivación por el trabajo mismo es tan baja que el equipo no hace lo más mínimo para mejorar sus prácticas. 

Agile: van Dos Décadas y Todavía hay Confusión

En estos días mucho se ha popularizado bastante el término “Ágil” y se ha mezclado con diferente prefijos y sufijos (agile coach, agile adoption, agile inception, etc.) pero el problema de fondo persiste: la gente y las empresas entran tratando de copiar y usar algo que todavía no acabaron de entender. 

Por eso es que en el rol de ScrumMasters uno de los principales desafíos es educar a las personas para que su entendimiento mejore. Una herramienta útil el Manifiesto Ágil pero este a la vez se queda muy corto pues es intencionalmente conciso y liviano.

Una otra herramienta es educar a través de la terminología que se utiliza frecuentemente en el espacio ágil ligado al desarrollo de software.

Sin embargo, he encontrado que en la práctica las personas y organizaciones tienden a entender mejor la agilidad cuando esta es presentada desde una perspectiva que describa su evolución histórica, es decir comenzando por sus orígenes en el Toyota Production Systems y su evolución hacia el software en conexión con eXtreme Programming. 

Más aún, resulta muy valioso para muchos establecer la reconexión entre los principios de Toyota y las practicas actuales de DevOps [Forsgren18].

Cualquiera que sea el camino escogido para explicar el concepto creo que es importante que se entienda que Agile tiene que ver con:

MENTALIDAD <-> CULTURA (PRINCIPIOS + PRACTICAS)

De igual importancia es explicar que Agile continúa evolucionando hacia otros enfoques como Modern Agile y The Heart of Agile.

Y que es esperable y de hecho deseable que esta evolución continúe pues Agile es en esencia un concepto evolutivo.

Y así Llegamos a Scrum

Si bien es totalmente cierto que Scrum es un marco de trabajo ligero y ágil orientado a grupos de trabajo que construyen productos, también es cierto que su simplicidad conceptual muchas veces hace que se interprete como una simple prescripción de reuniones y uso de un tablero.

Considero que Scrum debe ser entendido desde una perspectiva histórica asociada con las otras disciplinas con las cuales se interseca, de manera simplificada:

SCRUM = LINAJE + INTERSECCIONES

Si hablamos del linaje pues es vital entender que Scrum no es un marco de trabajo revolucionario; por el contrario, proviene de la evolución hacia el software del Toyota Production System que a su vez propició la aparición de Lean que a su vez influenció fuertemente la corriente ágil.

Y si hablamos de las intersecciones Scrum se interseca con una larga lista de disciplinas entre las cuales podríamos nombrar:

  • Teoría de colas
  • Teoría de sistemas
  • Prácticas ingenieriles como XP y DevOps en el mundo del software
  • Teoría de caos
  • Habilidades blandas para la construcción de equipos
  • Coaching

El objetivo pragmático que Scrum es enfocarse en crear un ambiente de aprendizaje continuo en el cual sea seguro experimentar y fallar. Este ambiente de aprendizaje eventualmente beneficia al Equipo, al Product Owner, a la Empresa y a las Prácticas de Desarrollo pues permite la exploración y mejora continua. 

Un corolario de lo anterior es que el ScrumMaster debe mantenerse enfocado dentro de cuatro áreas de acción principales: Equipo, Product Owner, Empresa y Prácticas de Desarrollo [Larman17].

Conclusiones

Si bien es cierto que Scrum se presta y de hecho invita a la adaptación esta debe hacerse dentro de los principios de la agilidad que a su vez se conectan con Lean y el Toyota Production System.

Hacer adaptaciones desconectadas de estos principios muy frecuentemente lleva a resultados subóptimos o a adopciones de Scrum fallidas. Peor aún en algunos casos ha llevado a ver a Scrum como una nueva y mejorada forma para tener mejor control de los empleados y el cronograma.

En el rol de ScrumMasters es vital clarificar estos malos entendidos y hacer que Scrum se utilice para lo cual realmente fue pensado.

Bibliografia 

Womack07 Womack J., Jones D., Ross D., 2007. The Machine That Changed the World: The Story of Lean Production– Toyota’s Secret Weapon in the Global Car Wars That Is Now Revolutionizing World Industry, Free Press; Reprint edition

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

Liker04 Liker J., 2004. The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer, McGraw-Hill

Senge90 Senge P., 1990. The Fifth Discipline: The Art & Practice of The Learning Organization, Doubleday

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

Forsgren18 Forsgren N., Humble J, Kim G., 2018. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, IT Revolution Press

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

La Esencia de la Certificación A-CSM

Introducción

A comienzos de este 2018 comenzó a tomar cada vez más fuerza la certificación A-CSM entre la comunidad mundial de ScrumMasters.

En mi rol de capacitador he tratado de explicarme a mí mismo cuál es la esencia detrás de esta certificación; en este proceso y como ejercicio muy personal encontré útil la metáfora del Circulo Dorado popularizada por [Sinek11], a saber:

¿Por qué se creó esta certificación?

Porque aspiramos a cambiar el entorno de trabajo para hacerlo más humano. 

¿Cómo la certificación beneficiara a los ScrumMasters?

Proveyendo herramientas y conocimiento que permiten avanzar aún más en el rol.

¿Qué se aprende en este curso de certificación?

La lista es muy ampliay tenderá a cambiar con el paso del tiempo y la evolución de Scrum y los dominios en los que se utiliza. 

Una Semana Después del Curso de CSM

Muy comúnmente encuentro entusiasmo en los estudiantes que toman mis cursos y están ansiosos por aplicar el conocimiento que adquirieron en un curso de CSM.

Como con cualquier idea o enfoque novedoso el entusiasmo pronto empieza a disminuir a medida que las ideas teóricas enfrentan realidades diferentes en las cuales no son tan aplicables.

Un Mes Después del Curso de CSM

El entusiasmo de seguir vivo y haberse contagiado al equipo entero se podría traducir en cambios y prácticas que en el mejor caso empiezan a producir más satisfacción y mejores resultados basados en el eje motor de equipos autoorganizados [Hackman02].

Lo contrario desde luego también pudo haber pasado, el entusiasmo se ha diluido y queda solo el consuelo de haberlo intentado.

Seis Meses Después del Curso de CSM

Si la perseverancia del ScrumMaster tuvo frutos se tiene un equipo que empieza a funcionar en un ambiente más humanizante de aprendizaje y mejora continua [Ohno13].

También es posible que solamente resultados subóptimos se hayan observado y esto haya llevado a pensar que Scrum simplemente no funciona o no aplica aquí. 

Un año Después del Curso de CSM

Con varios lanzamientos exitosos el equipo Scrum enfrenta ahora el desafío de seguir vivo dentro de una empresa que no se agilizó.

En un escenario más sombrío no hubo lanzamientos exitosos y la pregunta en el aire es ¿por qué si mejoramos algunas cosas el sistema en su conjunto no mejoró? [Senge90].

Y aquí nos Volvemos a Encontrar en el A-CSM

Un año después simplemente hay más historias por contar, más preguntas por hacer, más conocimiento por debatir y adquirir, más mitos y barreras de aprendizaje por derribar.

Y es entonces donde este curso viene siendo un espacio donde los ScrumMasters puedan reflejarse unos a otros y comparar historias de qué sirvió y qué no en la vida real.

Conclusiones

En mi opinión la esencia de este curso está conectada con la profundización del conocimiento que provendrá de vivencias prácticas complementadas con la experiencia del grupo de ScrumMasters veteranos que ya probaron qué sirvió y qué no.

Finalmente, este curso ofrece la oportunidad de “regresar al dojo por dos días” pero no en el rol de estudiante inicial, sino de caminante que viene a compartir las experiencias de su camino andado.

Bibliografia 

Sinek11 Sinek S., 2011. Start with Why: How Great Leaders Inspire Everyone to Take Action, Portfolio

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

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

Senge90 Senge P., 1990. The Fifth Discipline: The Art & Practice of The Learning Organization, Doubleday