Mis reflexiones acerca del Global Scrum Gathering Austin 2019

Del 20 al 22 de mayo se llevó a cabo en Austin-Texas la conferencia Global Scrum Gathering Austin 2019 que contó con asistencia de aproximadamente 1600 personas y docenas de speakers.

Como siempre fue un placer asistir y conocer a nuevas personas y reencontrar a viejos conocidos que no había visto en mucho tiempo. Más allá de lo social la conferencia me dejó algunas impresiones que resumo en este post.

Un Open Keynote espectacular

Daniel Pink abrió la conferencia con un keynote basado en su último libro. Su keynote fue por decirlo en un termino magistral por la calidad de su contenido, la forma con la cual lo presentó, la conexión que estableció con la audiencia y la fluidez de su presentación.

Hacia mucho tiempo que no había tenido la suerte de asistir a un keynote en el cual la audiencia al final se ponía de pie para ovacionar al keynoter.

Desde luego las conferencia ágiles han tenido muchos otros excelentes keynoters pero Pink llevó el evento a nuevas alturas. Es interesante también recalcar que el Scrum Alliance ha crecido y madurado lo suficiente como para poder financiar la presencia de un keynoter de este calibre abriendo su conferencia.

El mito de las historias de usuario escritas

En el segundo día de la conferencia se armó un Open Space en el cual hubo una charla de TDD, lamentablemente se me escapa de la memoria el nombre de quien presentó el tema. Pero lo interesante del asunto para mi fue que durante esa presentación habían participantes que cuestionan TDD como práctica y preguntaban donde quedaba la documentación escrita, como encajaba todo esto con JIRA y como se deberían escribir historias de usuario.

Y entonces apareció Chet Hendrickson.

Chet dijo que como una de las personas que estuvo ahi cuando se inventaron las “historias” estas no se escriben, no son documentos, son por el contrario conversaciones valiosas entre desarrolladores y usuarios.

La clarificación de Chet involucro un pedido, que la gente y las empresas sean más corteses y dejen de llamarle “historias” o “historias de usuario” a lo que hacen pero que no tengan nada que ver con la idea original que él y los demás propulsores de XP crearon décadas atrás.

Para mí esta intervención de Chet fue la que ilumino el día y creo personalmente que debemos considerarnos afortunados de que los creadores del movimiento todavía estén presentes para clarificar malos entendidos. A su vez debemos considerarnos desafortunados por los múltiples malos entendidos que ahi allá afuera respecto a la agilidad en su conjunto.

LeSS es el secreto mejor guardado

Algunos colegas CSTs y LeSS Friendly Scrum Trainers decidieron financiar y atender un stand donde se promocione LeSS. Si bien ninguno de los dos co-creadores de LeSS estuvieron involucrados, pues promocionar LeSS no es de su interés, es la percepción de muchos trainers y consultores (evito usar la palabra coaches) de que LeSS es el “secreto mejor guardado” y que hay que empezar a revelarlo pues tiene el potencial para realmente de-escalar Scrum.

SaFE no esta funcionando

Una percepción generalizada entre la gente con la que tuve la oportunidad de hablar es que SaFE en general no acaba resolviendo los problemas que se suponía tenia que resolver.

Las razones son varias, van desde la elevada complejidad sistema hasta el resurgimiento de ideas que en los ’90s probaron ser ineficaces.

Sin embargo también es la percepción de la mayoría de los colegas con los que puede hablar del tema que SaFE se esta vendiendo muy bien, las empresas lo comprar y hay muchos quienes lo venden.

Entonces cómo corolario puedo inferir que SaFE funciona para quien lo vende y enseña pero no necesariamente para quién lo compra y trata de usarlo.

El Scrum Alliance apunta a ser realmente global

Quedaron atrás los días en los cuales ésta era una conferencia intima y pequeña organizada por voluntarios por amor a Scrum. En los tiempo actuales se ve un crecimiento y una mirada cada vez más hacia otros países donde se pueda expandir aun más Scrum.

En mi humilde opinion el Scrum Alliance tiene el capital económico y cuenta con el acceso al capital intelectual que permitiría esta expansion global. El tiempo dura si sus lideres pueden articular una estrategia válida que les permita alcanzar este fin.

Finalmente puedo decir sin lugar a duda que asistir a esta conferencia fue una experiencia intelectualmente refrescante, de aprendizaje y validación/revalidación de muchas ideas y conceptos, de reencuentro y caras nuevas. En general la recomiendo ampliamente y la próxima cita para mi será en Nueva York en mayo del 2020.

Sirviendo a La Empresa

Introducción

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

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

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

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

El Cambio Organizacional si es Posible

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

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

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

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

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

Escalando Scrum

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

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

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

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

Conclusiones

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

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

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

Bibliografia

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

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

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

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

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

Sirviendo al Product Owner

Introducción

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

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

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

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

Pasos para Descubrir el Producto y el Product Backlog

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

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

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

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

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

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

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

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

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

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

Ver el Backlog Como Sólo una Lista

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

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

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

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

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

Herramientas Para Mantener un Product Backlog

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

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

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

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

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

Tratar de Incluir al Product Owners en el Equipo

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

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

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

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

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

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

Conclusiones

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

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

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

Bibliografia

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

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

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

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

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

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

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

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

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

Sirviendo al Development Team

Introducción

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

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

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

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

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

La Panacea de la Autoorganización

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

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

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

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

El Reto de la Autoorganización Constante

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

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

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

  • Autonomia
  • Maestria
  • Propósito

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

Mitos Acerca de Equipos Autoorganizados

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

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

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

Dinámicas de los Equipos

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

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

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

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

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

Evitar la Homogeneidad, Tratar la Diversidad 

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

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

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

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

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

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

La Obsesión de Medir el Rendimiento del Equipo

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

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

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

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

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

Formando Equipos Nuevos

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

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

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

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

Definición de Terminado Creada por el Equipo

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

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

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

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

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

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

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

El Valor de las Practicas de Ingeniería

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

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

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

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

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

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

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

Conclusiones

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

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

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

Bibliografia

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

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

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

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

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

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

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

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

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

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

Agile Coaching

Introducción

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

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

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

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

Respetando la Agenda del Cliente

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

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

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

Manteniendo la Neutralidad

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

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

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

Coaching Stances

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

Lyssa Adkins [Adkins10] identificó las siguientes posturas:

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

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

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

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

Técnicas de Coaching

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

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

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

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

Conclusiones

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

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

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

Bibliografia

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

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

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

Facilitación Agil

Introducción

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

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

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

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

Estar o No Estar de Acuerdo

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

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

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

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

Esquematizando un poco este modelo:

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

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

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

Técnicas Para Ayudar a la Convergencia

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

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

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

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

Facilitación de la Escucha

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

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

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

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

Conclusiones

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

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

Bibliografia 

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

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

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

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

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

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

Additional Readings for Self-Study

AGILE & SCRUM

These are great books that have been written in the last years about Agile and Scrum. They are together a great collection of wisdom and inspiration for making your learning path enjoyable; it is highly advisable that you start/continue reading some of the books in this list:

  • Agile Software Development, Principles, Patterns, and Practices (Robert C. Martin)
  • Agile Software Development with Scrum (Ken Schwaber and Mike Beedle)
  • Agile Project Management with Scrum (Ken Schwaber) 
  • Scrum Mastery: From Good To Great Servant-Leadership (Geoff Watts)
  • Agile Product Management with Scrum: Creating Products that Customers Love (Roman Pitchler)
  • Essential Scrum: A Practical Guide to the Most Popular Agile Process (Kenneth S. Rubin)

FOR SCRUMMASTERS

Please note that knowing Scrum well doesn’t automatically make an individual a great ScrumMaster but it is definitely required that you as a ScrumMaster be extremely knowledgeable in Scrum. These books present knowledge that you as a ScrumMaster are required to have:

  • Scrum and XP from the Trenches 2nd Edition (Henrik Kniberg)
  • Kanban and Scrum – making the most of both (Henrik Kniberg) 
  • The Great ScrumMaster: #ScrumMasterWay (Zuzana Sochova)
  • Ship It! A Practical Guide to Successful Software Projects (Jared Richardson and William Gwaltney Jr.)
  • Release It!: Design and Deploy Production-Ready Software (2nd Edition) (Michael T. Nygard)
  • The Agile Samurai: How Agile Masters Deliver Great Software (Jonathan Rasmusson)

SCRUM MASTERS COACHING AND OTHER SKILLS

There are soft skills like coaching, facilitation, motivation, mediation and non-violent communication that need to be developed in order that you as a ScrumMaster can better serve your team. This list presents some books that can help you to learn about those skills: 

  • Leading Teams: Setting the Stage for Great Performances (J. Richard Hackman)
  • Co-Active Coaching, Changing Business, Transforming Lives (Henry Kimsey-House and Karen Kimsey-House)
  • The Skilled Facilitator: A Comprehensive Resource for Consultants, Facilitators, Managers, Trainers, and Coaches (Roger Schwarz)
  • Humble Inquiry: The Gentle Art of Asking Instead of Telling (Edgar H. Schein)
  • Getting Naked (Patrick Lencioni)
  • Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Lyssa Adkins)
  • Agile Retrospectives: Making Good Teams Great (Esther Derby and Diana Larsen)
  • Fifty Quick Ideas To Improve Your Retrospectives (Tom Roden, Ben Williams, and Nikola Korac)
  • Leaders Eat Last: Why Some Teams Pull Together and Others Don’t (Simon Sinek)
  • Nonviolent Communication: A Language of Life (Marshall B. Rosenberg)
  • Innovation Games: Creating Breakthrough Products Through Collaborative Play (Luke Hohmann)
  • Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers (Dave Gray, Sunn Brown, and James Macanufo) 

FOR PRODUCT OWNERS

Product Owners are a vital part in a Scrum Team, without them it will be almost impossible to build a great product that delights customers. Knowing enough about this role to mentor and guide Product Owners is one of the Scrum Masters responsibilities. The techniques, responsibilities, and expectations for the Product Owner role are well described in these books:

  • Product Mastery: From Good To Great Product Ownership (Roman Pichler)
  • Start with Why: How Great Leaders Inspire Everyone to Take Action (Simon Sinek)
  • User Story Mapping: Discover the Whole Story, Build the Right Product (Jeff Patton)
  • Beyond Requirements: Analysis with an Agile Mindset (Kent McDonald)
  • Product Mastery: From Good To Great Product Ownership (Geoff Watts)
  • Impact Mapping (Gojko Adzic)
  • Fifty Quick Ideas to Improve Your User Stories (Gojko Adzic)

FOR DEVELOPERS

Scrum Teams need great developers because otherwise Scrum will fall short. The software development profession needs techniques to help professionals to evolve and perfect their craft; this list of books provides great material for technical people to read and learn how to acquire/evolve their software development practices:

About Software Craftsmanship

  • The Software Craftsman (Sandro Mancuso)
  • Apprenticeship Patterns: Guidance for theAspiring Software Craftsman (Dave Hoover)
  • The Clean Coder:ACode of Conduct for Professional Programmers (Robert C. Martin)
  • Clean Code:AHandbook ofAgile Software Craftsmanship (Robert C. Martin)
  • CleanArchitecture:ACraftsman’s Guide to Software Structure and Design (Robert C. Martin)
  • The Pragmatic Programmer: From Journeyman to Master (Andrew Hunt and David Thomas)

About eXtreme Programming

  • Extreme Programming Explained: Embrace Change (Kent Beck)
  • Planning Extreme Programming (Kent Beck & Martin Fowler)

AboutTest Driven Development

  • Test Driven Development: By Example (Kent Beck)
  • Test-Driven Development:APractical Guide:APractical Guide (David Astels)
  • Growing Object-Oriented Software, Guided by Test (Steve Freeman and Nat Pryce)
  • Essential Test-Driven Development(Robert C. Myers)

About Refactoring

  • Refactoring: Improving the Design of Existing Code (Martin Fowler)
  • Refactoring Workbook (William C. Wake)
  • Refactoring: Ruby Edition (Jay Fields, Shane Harvie, Martin Fowler and Kent Beck)
  • Refactoring to Patterns (Joshua Kerievsky)
  • Refactoring HTML: Improving the Design of Existing WebApplications (Elliotte Rusty Harold)
  • Refactoring Databases: Evolutionary Database Design (Scott J Ambler and Pramod J. Sadalage) 

About Design Patterns

  • Patterns of EnterpriseApplicationArchitecture (Martin Fowler)
  • Smalltalk Best Practice Patterns (Kent Beck)
  • The Design Patterns Smalltalk Companion (Sherman Alpert)
  • Implementation Patterns (Kent Beck)
  • Design Patterns in Ruby (Russ Olsen)
  • Design Patterns: Elements of Reusable Object-Oriented Software (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides)
  • xUnit Test Patterns: Refactoring Test Code (Gerard Meszaros)

About Object Oriented Design

  • Object Design: Roles, Responsibilities, and Collaborations (Rebecca Wirfs-Brock and Alan McKean)
  • Designing Object-Oriented Software (Rebecca Wirfs-Brock, Brian Wilkerson and Lauren Wiener)
  • Practical Object-Oriented Design in Ruby:AnAgile Primer (Sandi Metz)
  • Smalltalk, Objects, and Design (Chamond Liu)

About Legacy Code

  • Working Effectively with Legacy Code (Michael Feathers)
  • Object-Oriented Reengineering Patterns (Serge Demeyer, Stéphane Ducasse and Oscar Nierstrasz)
  • Beyond Legacy Code: Nine Practices to Extend the Life (and Value) ofYourSoftware (David Scott Bernstein)

About Continuous Integration

  • Continuous Integration: Improving Software Quality and Reducing Risk (Paul M.Duvall, Steve Matyas and Andrew Glover)
  • Continuous Delivery: Reliable Software Releases through Build, Test, and DeploymentAutomation (Jez Humble and David Farley)
  • The DevOps Handbook: How to Create World-ClassAgility, Reliability, and Security in Technology Organizations (Gene Kim, Patrick Debois, John Willis and Jez Humble)

FOR TESTERS

Scrum doesn’t recognize nor prescribe the role of Tester; on the contrary, there are practices and techniques that can help the whole team to focus in inserting quality while building software, creating automated tests and automate the continuous delivery pipeline. These books present a very comprehensive description for this approach:

  • More Agile Testing: Learning Journeys for the Whole Team (Lisa Crispin and Janet Gregory)
  • Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin and Janet Gregory) 
  • Fifty Quick Ideas To Improve Your Tests (Gojko Adzic, David Evans and Tom Roden)

FOR LEADERS

Scrum is great for transforming teams and creating a vibrant and motivating working environment that eventually starts infecting other departments/divisions of the organization. Upper management needs to be influenced by leaders that can convince them to help to sustain the Agile transformation. These books present some great insights for leaders on how to change things for better in traditional organizations:

  • The Fifth Discipline: The Art & Practice of The Learning Organization (Peter M. Senge)
  • The Future of Management (Gary Hammel)
  • The Fifth Discipline: The Art & Practice of The Learning Organization (Jeffrey Pfeffer and Robert I. Sutton)
  • Reinventing Organizations (Frederic Laloux)
  • Out of the Crisis (W. Edwards Deming)
  • Rework (Jason Fried and David Heinemeier Hansson)
  • Remote (Jason Fried and David Heinemeier Hansson)
  • The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win (Gene Kim, Kevin Behr, and George Spafford)
  • Turn the Ship Around! (L. David Marquet)
  • The Goal: A Process of Ongoing Improvement (Eliyahu M. Goldratt, Jeff Cox, and David Whitford)
  • Maverick (Ricardo Semler)
  • Management 3.0: Leading Agile Developers, Developing Agile Leaders (Jurgen Appelo)
  • How to Change the World: Change Management 3.0 (Jurgen Appelo)
  • The Leader’s Guide to Radical Management: Reinventing the Workplace for the 21st Century (Stephen Denning)

FOR ENTREPRENEURS

ScrumMasters might be in the position of deciding to form their own companies; this happened to many that instead of transforming organizations decided to form something new form the beginning. These books present great inspiration and case studies:

  • Joy, Inc.: How We Built a Workplace People Love (Richard Sheridan)
  • The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses (Eric Reiss)
  • Creativity, Inc.: Overcoming the Unseen Forces that Stand in the Way of True Inspiration (Ed Catmull and Amy Wallace)
  • Liftoff: Launching Agile Teams & Projects (Diana Larsen and Ainsley Nies)

FOR PROJECT MANAGERS

The Project Manager responsibilities are somehow diluted among the Scrum Roles but in several organizations a new title has emerged: Agile Project Manager. Understanding the transition/transformation to this role might help to redefine current Project Manager’s careers. This short list of books provides light on the matter:

  • The Software Project Manager’s Bridge to Agility (Michele Sliger and Stacia Broderick)
  • Agile Project Management: Creating Innovative Products (James A. Highsmith)
  • Agile and Iterative Development: A Manager’s Guide (Craig Larman)

FOR RECRUITERS

Bringing the right people on board has always been challenging and more so for self-organizing Scrum Teams, these books provide some great ideas on the subject:

  • Hiring Geeks that Fit (Johanna Rothman)
  • Hiring The Best Knowledge Workers, Techies & Nerds: The Secrets & Science Of Hiring Technical People (Johanna Rothman)

TOYOTA AND LEAN THINKING

The Lean Thinking has been influenced by the car industry and has great contributions to the Agile way of building software. These are highly recommended readings for expanding your knowledge about Lean:

  • The Toyota Way (Jeffrey Liker)
  • Taiichi Ohno’s Workplace Management: Special 100th Birthday Edition (Taiichi Ohno)
  • Lean Product and Process Development (Allan C. Ward and Durward K. Sobek II)
  • The Lean Manager: A Novel of Lean Transformation (Michael Ballé and Freddy Ballé)
  • Lead With Respect: A Novel of Lean Practice (Michael Ballé and Freddy Ballé)
  • Leading Lean Software Development: Results Are not the Point (Mary Poppendieck and Tom Poppendieck)
  • Lean-Agile Software Development: Achieving Enterprise Agility (Alan Shalloway, Guy Beaver and James R. Trott)
  • Lean Software Development: An Agile Toolkit (Mary Poppendieck and Tom Poppendieck)
  • Implementing Lean Software Development: From Concept to Cash (Mary Poppendieck and Tom Poppendieck)

KANBAN

Kanban might be a great alternative for some teams/organizations where Scrum might not be the best choice. These books presents the fundamentals of the Kanban philosophy and methods:

  • Kanban Workbook: A Practical Guide to Using Kanban (Samantha Laing and Karen Greaves)
  • Real World Kanban: Do Less, Accomplish More with Lean Thinking (Mattias Skarin)
  • Kanban: Successful Evolutionary Change for Your Technology Business (David J. Anderson)

CULTIVATING TEAMS

People are not resources, they never were and Scrum strongly emphasizes this more humane vision about software professionals. Recognizing the importance of individuals leads to the next challenge: how to help groups of individuals to evolve into great teams of happy people. These books don’t prescribe a “silver bullet” approach but instead present some interesting ideas:

  • Drive: The Surprising Truth About What Motivates Us (Daniel H. Pink)
  • Peopleware: Productive Projects and Teams (Tom DeMarco and Timothy Lister)
  • The Five Dysfunctions of a Team: A Leadership Fable (Patrick Lencioni)
  • The Ideal Team Player: How to Recognize and Cultivate the Three Essential Virtues (Patrick Lencioni)
  • Creating Great Teams: How Self-Selection Lets People Excel (Sandy Mamoli and David Mole)
  • Corps Business: The 30 Management Principles of the U.S. Marines (David H. Freedman)

READINGS ON SCALING SCRUM

Scaling Scrum is a controversial topic because many believe that Scrum cannot and should not be formalized and modeled like a cookie-cutter that produces identical teams with comparable results and motivation. Still some interesting books like these have been written on the topic:

  • Large-Scale Scrum: More with LeSS (Craig Larman and Bas Vodde)
  • Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum (Craig Larman and Bas Vodde)
  • Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum (Craig Larman and Bas Vodde)
  • Lean Enterprise: How Performance Organizations Innovate at Scale (Jez Humble, Joanne Molesky, and Barry O’Reilly)
  • Lean from the Trenches: Managing Large-Scale Projects with Kanban (Henrik Kniberg)

TRAINING & ADULT EDUCATION

If you’re curious about the activities and exercises that were used during this two-day ScrumMaster training course, here are some books that present all the science and thinking behind them:

  • Using Brain Science To Make Training Stick (Sharon L. Bowman)
  • Brain Rules (Updated and Expanded): 12 Principles for Surviving and Thriving at Work, Home, and School (John Medina)

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