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

Trabajando con el Product Backlog

Introducción

El Product Backlog es uno de los artefactos con los cuales trabaja el Product Owner pero no es de propiedad exclusivamente suya, de hecho cualquier miembro del Scrum Team debe tener acceso al Product Backlog pero el Product Owner es quien decide el orden de los items.

Si el backlog fuese secreto provocaría poca visibilidad por parte del Equipo de Desarrollo y lo que es peor no permitiría que todos los miembros del equipo contribuyan con ideas y opiniones recortando así la creatividad.

El Product Backlog, al igual que los demás artefactos, es propiedad del Scrum Team y para que éste lo pueda usar en su trabajo diario. Al ser un artefacto ligado con la táctica es necesario que todos en el equipo puedan verlo y sentirlo presente en el día a día.

Además de lo anterior el Product Backlog tiene otras características, tales como: ser finito, contener items que son diferentes entre sí en valor y nivel de especificación, ser dinámico, y ser alcanzable en un horizonte de tiempo corto.

Como tal el trabajo del Product Owner consiste en tener el Product Backlog ordenado incorporando el conocimiento más actual que viene del aprendizaje y la retroalimentación de los clientes. El trabajo del Scrum Mater será guiar al Product Owner y los desarrolladores para que el Product Backlog mantenga las características descritas en el párrafo anterior.

Producción versus Resultado

La producción es medible y observable, aun cuando el software es un elemento abstracto, pues esta ligada a la cantidad de algo que se produjo dentro de un Sprint. 

Por ejemplo podemos decir que en un Sprint cualquiera se implementaron X cantidad de items, se escribieron Y lineas de código, se escribieron Z pruebas automatizadas, o el porcentaje de cobertura de pruebas es del W%.

El resultado es más intangible y subjetivo pero aun así puede ser apreciado aunque no necesariamente se mida numéricamente. 

El mejor ejemplo de resultado es la percepción de si el equipo Scrum está construyendo el producto correcto que resolverá los problemas y necesidades de los clientes. Ligado a lo anterior está la percepción de los clientes que gustan del producto y lo compraran cuando este terminado.

Si bien es cierto que no se puede llegar al resultado sin la producción es económicamente mas conveniente tratar de alcanzar el mayor resultado con la menor cantidad de producción posible. La clave para esto es que el Product Owner pueda identificar que items del Product Backlog implementar primero. 

Existen varios atributos que pueden tener los items del Product Backlog que permiten ver si contribuyen mayor resultado, por ejemplo:

  • items que tienen un componente visual, es decir que los usuarios finales pueden ver en el producto e interactuar con el
  • items que al verlos en el producto los usuarios finales los conectan inmediatamente con una posible solución a un problema o necesidad que ellos tienen
  • items que un gran número de usuarios potencialmente utilizaran

Demás esta decir que cualquier item que se espere que produzca resultados positivos tiene que tener insertada la calidad. 

Definiendo Valor

El valor de los items puede definirse desde diferentes perspectivas pero es importante no perder de vista que siempre debe estar conectado a algo que los clientes puedan ver y pagar por él.

Muchas veces los desarrolladores tienden a pensar que primero deben hacer todo el trabajo de las capas más inferiores, que tiene valor solo técnico, para en varios Sprints posteriores recién empezar a implementar items que los clientes puedan ver. 

En este punto es frecuente que los clientes hayan cambiado de opinion o pidan cambios en los items pero estos cambios ahora son costosos pues hay que bajar varias capas y tocar mucho código. La consecuencia natural es que los desarrolladores se resistirán lo mas posible a hacer cambios restringiendo de esta manera la adaptabilidad del producto.

Por el contrario sí el abordaje arquitectónico permite desde el principio ver el producto y realizar cambios rápido se tiene dinamismo y adaptabilidad. Precisamente es en este escenario en el cual se puede tener items con mejor definición de valor, items como por ejemplo:

  • items que permitan realizar operaciones o flujos completos
  • items que permitan aprender como interactuaran los clientes con el producto
  • items que permitan descubrir nuevos clientes o descartar clientes que se consideraba que iban a utilizar el producto
  • items que ayuden a reducir el riesgo de que algún item no se vaya a usar una vez implementado completamente
  • items que permitan descubrir que tan frecuentemente serán utilizados

Un otro factor importante es considerar que en un producto están involucrados diferentes grupos y cada uno puede percibir el valor de manera diferente. Así por ejemplo:

  • Los stakeholders del negocio pueden pensar que el valor se conecta a vender el producto a la mayor cantidad de gente al mejor precio
  • Los usuarios y clientes perciben el valor de un producto que resuelve sus problemas y necesidades
  • El Equipo de Desarrollo ve el valor de implementar items que los desafíen técnicamente o por el contrario puedan implementar con su conocimiento actual

La labor del Product Owner consiste en balancear estos intereses para que los items acaben contribuyendo valor para todos los grupos involucrados.

El valor también puede conectarse con indicadores econométricos como por ejemplo estos:

  • costo total de propiedad es decir cuánto le constara al cliente adquirir y operar el producto a lo largo de su vida útil. Aquí es importante hacer notar que un producto con baja calidad sera muy costoso de operar y su horizonte de vida es mas corto.
  • costo de retraso que tiene que ver no solo con llegar tarde a un mercado con el riesgo de ser sustituidos por competidores, sino también con el costo interno de pagar salarios y otros gastos por un tiempo extendido.
  • margen entre cuento dinero esta costando desarrollar el producto y cuanto se espera recuperar y en cuanto tiempo

Ordenando Items

Ordenar los items del Product Backlog no es una tarea que debe considerarse tomando solamente una única perspectiva, por ejemplo ordenarlos tomando en cuenta el tiempo estimado de implementación de los items.

Pensando sistemicamente [Senge90] el Product Owner deberá identificar cuales son las variables relevantes y luego analizar si prioriza una por encima de las otras cual será el impacto. Por ejemplo, un item puede tomar poco tiempo para implementarse pero una vez implementado produce poco impacto en los usuarios.

Estos son algunos ejemplos de variables o criterios relevantes:

  • alineamiento estratégico con el objetivo que persigue el producto, es decir items que nos acerca mas a alcanzar la vision del producto
  • valor de negocio percibido a través de items que harán que por ejemplo el producto se vaya distinguiendo de la competencia y el negocio mejore su imagen 
  • valor para el usuario final determinado por el grado en que el item ayude a resolver un problema o mitigar un dolor
  • el tiempo de comercialización que se conecta a la noción de cuanto tiempo total pasa desde que se construye un item, se distribuye y se empieza recuperar la inversion  

Creando y Refinando Items

Los items como tal pueden provenir de fuentes diversas como por ejemplo estas:

  • Grupos de clientes que manifiestan sus necesidades y problemas que originan ideas de solución traducidas en items
  • Requerimiento regulatorios como leyes y políticas de gobierno que fuerzan a que el producto incluya ciertas características
  • Aprendizaje a través de validación de supuestos que derivan en items que si se deben incluir en el producto
  • Defectos que se acarrean de Sprints pasados o peor aun de una versión previa del producto que ya esta en producción 
  • Cuestiones técnicas como componentes, librerías, parches de seguridad, plataformas, etc. que si bien tienen un valor técnico presentan un riesgo de tiempo y desvío de enfoque importante

Una forma dinámica e iterativa de crear nuevos items es utilizar el concepto de un estudio de diseño en el cual se dibuja y se hablar acerca del item, como si se estuviese diseñando alguna parte de una casa en el estudio de un arquitecto. Bajo este enfoque se dibuja cómo debería lucir el item dentro del producto, se habla de porque y quién lo utilizara, se exploran alternativas, y se comentan riesgos y desafíos.

Las conversaciones pueden quedar registradas en videos y los dibujos en fotografías, todo este material puede ir a un wiki interno. El titulo de el item es el que se anota en una tarjeta que ira dentro del Product Backlog, si se una una herramienta en linea como Google Spreadsheet la lógica es la misma, el titulo del item ira en una celda de una hoja llamada Product Backlog [Larman17].

Para incrementar el envolvimiento y contribuciones de los clientes en el Product Backlog es posible, y de hecho recomendable, tener reuniones semanales o aun mejor tener a los clientes sentados cerca del equip para poder comunicación y retroalimentación fluida

Para refinar los items del Product Backlog resulta muy util realizar juegos colaborativos en los cuales intervendran clientes y el Scrum Team y cuyo objetivo es entender mejor no solo los items sino el porque son necesarios.

El refinamiento de los items debe realizarse como una actividad recurrente para ir incorporando descubrimientos y conocimiento a medida que se adquiere. Tratar de hacer un solo refinamiento para todo el Backlog consume demasiado tiempo y no necesariamente aportara valor pues los items no prioritarios cambiaran y necesitaran de todas maneras ser refinados posteriormente.

El propósito del Product Backlog a veces puede ser mejor comunicado a través de herramientas como: hojas de ruta del producto, wireframes y mapas de historias de usuario [Patton14].

Un producto enorme aun puede ser trabajado a través de un backlog pequeño pero que provea valor siempre y cuando este backlog corresponda al lanzamiento de un producto minimamente viable, un lanzamiento para aprender (globo de ensayo), o un producto con el mínimo de características que lo hagan comercializable. 

Conclusiones

El Product Backlog debe ser un elemento de uso cotidiano y que sirva para centralizar el trabajo y la discusiones del Scrum Team. Mas aun, debe reflejar el entendimiento actual del orden en el cual se quieren implementar los items para producir el mayor impacto posible.

Como tal este artefacto puede tomar formas diferentes pero en esencia no se debe perder de vista que es solamente una lista de cosas por hacer en un horizonte de tiempo finito.

Finalmente, el Product Backlog debe poderse ver, idealmente debe poderse tocar, para que cumpla mejor su función de elemento integrador y facilitador de la comunicación. 

Bibliografia 

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

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

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

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

Validando las Suposiciones del Producto

Introducción

Un producto, cualquiera que éste sea, mientras está en una etapa temprana de su ciclo se basa en muchas suposiciones. Por ejemplo se supone que tenemos el conocimiento, los recursos económicos, y disciplina para construir el producto correcto. 

Desde luego las suposiciones anteriores pueden o no ser ciertas, en el mejor caso si lo son nos llevaran a construir un producto pero ese no es el fin de la historia. También suponemos que conocemos el alcance del producto, quienes lo compraran, cuando dinero pagaran y en que mercado se venderá.

Ese segundo grupo de suposiciones son aun mas inciertas que las primeras pues están conectadas a factores externos variables como fluctuaciones del mercado, competidores y la economía misma de un país.

En esencia crear suposiciones y creer que se materializaran no es equivocado, pero la clave esta en validar si son verdaderas o no lo más pronto posible. Por tanto el gran servicio que un Product Owner presta no sólo al equipo sino a la organización, los clientes y el mercado mismo, es contribuir productivamente a la validación temprana de suposiciones.

Scrum Soporta la Validación de Suposiciones

Uno de los puntos centrales de Scrum es obtener retroalimentación sincera de clientes reales al final de cada Sprint, es precisamente a través de ésta dinámica que Scrum enfatiza la necesidad de validar suposiciones.

En muchos equipos he encontrado la tendencia a esperar un Sprint más para tener más cosas que mostrar a los clientes; desde luego esto no es recomendable y es generalmente un reflejo de que Scrum no se entendió bien o técnicamente el Equipo de Desarrollo esta abordando la construcción del producto usando un enfoque arquitectónico que no permite tener funcionalidad observable al final de cada Sprint.

Existen suposiciones técnicas que el Equipo de Desarrollo debe validar lo mas pronto posible, la mas común de ellas es que podemos poner código en producción fácilmente [Humble10].

Scrum a través del empoderamiento que concede al Equipo de Desarrollo para tomar decisiones técnicas favorece el que éste pueda invertir en aprender cómo poner código en producción desde los primeros dias del primer Sprint.

Una otra suposición técnica es que todo código que se construya luego se podrá probar a mano de forma rápida, eficaz y exhaustiva. Desde luego esta es una suposición muchas veces herrada pues el testo manual es lento, puede tener errores y omisiones. 

Una vez más Scrum fomenta que el Equipo de Desarrollo mejore sus prácticas de ingenieria para que inserte la calidad en el producto mismo a través de pruebas automatizadas [Jeffries00].  

Enfoques para la Validación de Suposiciones

Decidir qué suposiciones son las que se validaran primero tiene una influencia directa en el ordenamiento del Producto Backlog y por eso el Product Owner debe estar consciente de que existe varios enfoques. Estos son tres de los mas comúnmente empleados:

  • Validar primero las suposiciones que implican el mayor riesgo de negocio
  • Validar primero las suposiciones que implican el mayor riesgo técnico
  • Validar primero las suposiciones que ofrecen las mayores posibilidades de aprendizaje

Balancear la incertidumbre en estas tres esferas (negocio, técnica y conocimiento) es complicado pues el Product Owner tiende a priorizar el negocio por encima de las otras dos. Si esta acaba siendo la tendencia en todos los Sprints muy probablemente el Equipo de Desarrollo acabara construyendo un producto plagado de deuda técnica y acarreara hacia el futuro una deuda de conocimiento. 

Parte de la labor del Scrum Master es colaborar con el Product Owner para que el balance entre esas tres dimensiones se mantenga. La receptividad y pensamiento sistemico en el Product Owner son esenciales en este punto para poder entender y aceptar lo que el Scrum Master trate de exponer [Schwaber04].

Para decidir cual enfoque escoger muchas veces resulta util ver que tenemos disponible, es decir, si quiero validar riesgos de negocio tengo que tener disponible usuarios reales, si quiero validar riesgos técnicos tengo que tener la infraestructura o dispositivos, si quiero aprender tengo que tener disponibilidad de tiempo y recursos de aprendizaje.

En función de lo que haya disponible, sea más barato o sea mas accesible se podrá tomar una decision de que suposiciones validar primero. 

Conclusiones

El trabajo en ciclos, el empoderamiento, la retroalimentación, la comunicación constante, y el espíritu de colaboración son algunos de los elementos que ofrece Scrum para permitir validar suposiciones lo más pronto posible.

Un buen Product Owner debe conocer y utilizar estos elementos y estar siempre dispuesto a cambiar el rumbo del producto en función de lo que vaya aprendiendo.

Una suposición también importe a considerar es que el Product Owner es el adecuado para el producto, quizás esto no sea cierto y una vez más Scrum a través de la transparencia y el coraje ofrece la oportunidad de que el mismo Product Owner pueda darse cuenta de que alguien más puede tomar su lugar. 

Finalmente y reiterando lo antes mencionado, suponer no es malo pues es parte del ciclo de desarrollo de un producto, lo que es malo es no validar esas suposiciones a tiempo y generar gran desperdicio con un producto construido que no sirve a las necesidades de los clientes o simplemente es el producto equivocado.

Bibliografia 

Humble10 Humble J., Farley D., 2010. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Addison-Wesley

Jeffries00 Jeffries R., Anderson A., Hendrickson C., 2000. Extreme Programming Installed, Addison-Wesley Professional

Schwaber04 Schaber K., 2004. Agile Project Management with Scrum