Tag: scrum

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 

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

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

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

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