Blog

Competencias Básicas de un ScrumMaster

Introducción

Un ScrumMaster no es solamente una persona que toma un curso de dos días y con esto siente que ya concluyó su aprendizaje de Scrum. Por el contrario es alguien que aborda Scrum con humildad intelectual y curiosidad infinita.

La humildad intelectual consiste en primero aceptar que no se conoce todo, que hay mucho mas que aprender y que incluso lo que se conoce puede estar equivocado, desactualizado o simplemente puede no ser aplicable al contexto actual.

La curiosidad infinita hace que un ScrumMaster esté siempre en constante aprendizaje, que busque nuevas ideas, técnicas y conocimiento de diferentes disciplinas para ampliar su repertorio.

En el extremo opuesto a la humildad intelectual esta la noción de que ya no hay nada que nadie puede enseñarle a un “experimentado” ScrumMaster. Un indicador clarísimo de que la curiosidad infinita dejó de existir para un ScrumMaster es hecharle un vistazo a su biblioteca personal y ver que esta leyendo.

Las competencias básicas de un ScrumMaster cambiaran con el tiempo y se irán enriqueciendo con diferentes experiencia, además de ser altamente contextuales. Pero lo que no debería cambiar es la actitud de abordar Scrum con humildad intelectual y curiosidad infinita.

Facilitación

El ScrumMaster puede facilitar el trabajo del equipo a través de varias formas que incluyen:

  • Ayudarlos a comunicarse más efectivamente descubriendo/redescubriendo la herramienta más efectiva de comunicación: el habla
  • Ayudarlos a que reconozcan cuando es mejor permanecer en silencio escuchando y aprendiendo de lo que otros tienen que decir
  • Ayudarlos a darse cuenta que la adopción de Scrum requerirá de un profundo cambio en el sistema organizacional 

El tercer punto es especialmente importante pues el sistema organizacional es él que propicia el comportamiento de los individuos y si éste no es cambiado no habrá una adopción duradera de Scrum. 

Ejemplificando lo anteriormente dicho, si el sistema organizacional está diseñado para premiar y motivar la participación individual mas no el trabajo en equipo entonces Scrum tiene pocas chances. Similarmente si el sistema esta diseñado para basarse en controles, supervision y jerarquías entonces tampoco Scrum podrá florecer. 

Técnicas de modelamiento sistémico y en general pensar sistémicamente ayudaran a que el equipo y sobre todo la alta gerencia de la organización se den cuenta de la necesidad del cambio y los impactos que este tendrá [Senge90].

En el tema de la facilitación de decisiones de grupo existen varias técnicas que un ScrumMaster puede considerar utilizar [Schwarz16], algunas de las más comunes son estas:

  • Voto con los cinco dedos de la mano
  • Voto de aprobación/reprobación con el pulgar arriba/abajo
  • Voto con puntos en un papelógrafo 
  • Pararse en algún lugar de un salon
  • Protocolo para la toma de decisiones

Independientemente de las técnicas que un ScrumMaster decida utilizar es importante recordar que en su papel de facilitador no le corresponde imponer o forzar una decision en el equipo [Schein13]. 

Coaching

Muchas veces la facilitación es confundida con el coaching siendo ésta una disciplina mucho más amplia y estudiada [Adkins10] que incluye facetas como:

  • facilitación que implica el ayudar a que grupos de personas se puedan comunicar más efectivamente para llegar a acuerdos que satisfagan a la mayoría
  • enseñanza de una habilidad o capacidad con la expectativa de que los demás puedan aprenderla y también utilizarla
  • tutoría que consiste en informal o formalmente guiar el paso de conocimiento y experiencia hacia un aprendiz

El coaching abarca también algo más amplio y poderoso que las facetas anteriores pues implica la habilidad del coach de guiar a las personas en su propio descubrimiento.

El coaching implica que las personas que lo reciben sean capaces de formularse a sí mismo preguntas poderosas que los hagan pensar y descubrir sus propias respuestas.

Cabe hacer notar que el valor del coaching no esta necesariamente en encontrar respuestas sino en la exploración misma, en el proceso mental que implica el cuestionamiento interno que a la vez es el disparador del verdadero aprendizaje.

Si hablamos de equipos que tratan de ser autoorganizados a menudo ellos encuentran desafíos como:

  • estar tan acostumbrados a la mentalidad de recibir ordenes y ser controlados que simplemente no pueden cambiar su mentalidad
  • están acostumbrados a operar en un sistema organizacional cargado de títulos jerárquicos, planes de carrera, ascensos, etc. que en esencia provoca la competencia interna y la envidia
  • tener miembros del equipo que eran managers y estaban acostumbrados a dar ordenes y preparar reportes pero que carecen de conocimiento actualizado que les permita hacer trabajo técnico

Uno de las contribuciones más significativas que podría hacer un ScrumMaster desde la disciplina del coaching es precisamente ayudar a que un equipo descubra  como autoorganizarse para vencer los desafíos anteriores [Hackman02].

Debido a que no hay una formula garantizada o algo así como “mejores prácticas” la labor del coach es siempre dependiente del factor humano, y de la creatividad, colaboración y entendimiento de quienes reciben sus servicios

Parte de hacer coaching con un equipo tiene que ver con hacerle notar a la gente que el estado actual de conocimiento, creencia y valores deberá cambiar y esto implicará dejar ir algo. 

El que dejar ir muchas veces implica renunciar a la zona de confort o la ilusión del conocimiento o control; precisamente es porque éste dejar ir es tan difícil que el coach no puede ni debe obligar al equipo a adoptar Scrum.

Un punto central en el coaching es la diferencia entre ideas propias y prestadas [Kimsey11]. Las primeras son las que la gente misma descubre, abraza, cree en ellas y las defiende; las segundas en el mejor de los casos pueden ser inspiradoras pero al no ser propias no se quedan y no provocan el cambio verdadero.

Como coach el objetivo siempre debe ser posibilitar que el equipo mismo genere sus propias ideas para cambiar el status quo y verdaderamente adoptar Scrum [Hackman02].

Sirviendo al Equipo de Desarrollo

El ScrumMaster sirve al Equipo de Desarrollo a través de diferentes maneras. Sin embargo una constante es la aplicación del Liderazgo Servicial.

El Liderazgo Servicial es un estilo de liderazgo que básicamente invierte la pirámide jerárquica tradicional en la cual los empleados sirven a los jefes, en su lugar los líderes serviciales buscan ayudar a los empleados −que ahora son colegas al mismo nivel− para que desarrollen todo su potencial y enriquezcan sus vidas.

El ScrumMaster actúa como Líder Servicial en situaciones como las siguientes:

  • Escucha a los demás cuando necesitan ser escuchados
  • Ayuda a los demás para que ellos mismos remuevan sus impedimentos
  • Con humildad intelectual reconoce que no lo sabe todo pero que está dispuesto a aprender
  • Hace preguntas ingenuas que nadie más se anima a preguntar
  • Se ofrece de voluntario para tareas que nadie más gusta de realizar 

Cada enfatizar a manera de advertencia que ser un Líder Servicial no quiere decir hacer cosas cómo actualizar el tablero para el equipo o ser la única persona que habla en los eventos. De hecho lo anterior puede considerarse como anti-patrones del accionar de un ScrumMaster.

El ScrumMaster como Líder Servicial puede cultivar la actitud de voluntariado del equipo, un escenario típico es ofrecerse como voluntario para tareas que nadie quiere tomar durante el Sprint Planning Two. 

Desde luego el ofrecerse como voluntario no quiere decir que el ScrumMaster sea la persona con el mayor conocimiento sino solamente que es la persona con la actitud de servir a los demás.

Esta actitud de voluntariado de parte de ScrumMaster si se repite constantemente eventualmente acaba contagiando a otros miembros del equipo que poco a poco van descubriendo que es gratificante tomar tareas que no conocen.

Otro escenario clásico es cuando el Product Owner o algún cliente o stakeholder quiere presionar al equipo con el afán de incrementar la velocidad de desarrollo pidiendo incluso que el equipo trabaje horas extra.

En su rol de Líder Servicial el ScrumMaster puede invitar a quien quiera presionar al equipo a realizar un ejercicio de modelaje sistémico en un papelógrafo. 

En este ejercicio se listará la variable “velocidad” y las demás variables como calidad, motivación, colaboración y otras que se verán impactadas cuándo el equipo trate de acelerar el desarrollo.

Normalmente con este tipo de modelaje es claro que la velocidad no viene sin consecuencias y esto hace abandonar la idea de exigir que el equipo se mueva más rápido.

Implementaciones que se hacen a la rápida generan Deuda Técnica que es una analogía inventada por Ward Cunningham. Al igual que un préstamo bancario existen intereses que si no se pagan acaban incrementando la deuda y eventualmente llevan al colapso del acreedor.

Algo muy similar ocurre con el código que al escribirse rápida y desprolijamente va acumulando Deuda Técnica que eventualmente hace el código inmantenible o simplemente demasiado costoso de cambiar y mantener estable. 

No tener tiempo para refactorizar o construir el código sin pruebas es el primer paso a la introducción de la Deuda Técnica. Los postulados de Código Limpio, con las prácticas que recomienda basadas en su vez en Extreme Programming, son la mejor forma conocida hasta ahora de poder evitar la acumulación de Deuda Técnica [Martin08].  

Una parte crucial del servicio que el ScrumMaster presta al Equipo de Desarrollo es precisamente ayudar a que descubra cómo crear código limpio [Martin11]. Para ayudar en este descubrimiento el ScrumMaster tiene a su disposición las disciplinas del coaching, la tutoría, la facilitación y la enseñanza.

Organizaciones que están cómodas tolerando que sus desolladores generen cualquier tipo de código con tal que funcione presentan un tipo de deuda al cual llamó Deuda Organizacional.  

He observado que las prácticas de Extreme Programming propuestas hace veinte años  [Beck99] usadas con disciplina y constancia conducen a la creación de código limpio y un consiguiente Incremento del Producto de mayor calidad.

Si bien todas la prácticas de Extreme Programming tienen sentido existen algunas de ellas que desde mi experiencia son imprescindibles, estas son:

  • Test Driven Development
  • Integración continua 
  • Refactorización 
  • Cliente sentado con el equipo
  • Liberaciones frecuentes

La habilidad de tener un Incremento del producto potencialmente liberable al final de cada Sprint puede ser influenciada por las prácticas ingenieriles del un Equipo de Desarrollo de las siguiente maneras:

  • Teniendo un conjunto de pruebas automatizadas que puedan correrse exitosamente incontables veces al día garantiza que el Incremento esta probado e integrado
  • Incorporando a través de la refactorización constante el conocimiento más actualizado que tienen los desarrolladores acerca del domino del problema, la tecnología y el vocabulario del cliente
  • Teniendo liberaciones a producción cada vez más cortos y frecuentes que clientes sentados con el equipo puedan evaluar rápidamente

Sirviendo al Product Owner

Un Product Owner puede utilizar varias técnicas para colaborar y comunicarse con el Equipo de Desarrollo y con el cliente, técnicas tales como:

  • Ayudar al equipo a ver el panorama completo del producto que están construyendo a través de la creación de un Product Roadmap [Pichler16]
  • Descubrir con los clientes y otros interesados que características tendrá el producto a través de User Story Mapping [Patton14]
  • Trabajar con los clientes y otros interesados en el planeamiento estratégico del producto empleando Impact Mapping [Adzic12]

A su vez el ScrumMaster puede apoyar al Product Owner haciendo cosas como estas:

  • Asesorando a la gerencia para realizar los cambios necesarios como por ejemplo concederle total autoridad sobre el producto al Product Owner
  • Animando al Equipo de Desarrollo a colaborar con el Product Owner para juntos refinar constante y consistentemente el Product Backlog
  • Ayudándole a seleccionar las herramientas más simples, baratas y eficientes para su trabajo
  • Aconsejando a los clientes colaborar directamente en los desarrolladores en el día a día 
  • Educando a los clientes y el Equipo de Desarrollo acerca de que las determinaciones que tome el Product Owner respecto al orden del Product Backlog deben ser respetadas

Sirviendo a la Organización 

El ScrumMaster puede apoyar al equipo a responder ante los impedimentos de varias maneras, entre ellas:

  • Constantemente preguntando si existen impedimentos, por ejemplo en el Daily Scrum
  • Manteniendo los impedimentos visibles, por ejemplo en un papelógrafo en el área de trabajo del equipo
  • Ayudando a que el equipo hable acerca de los impedimentos y piensen en posibles mitigaciones

Sin embargo hay impedimentos organizacionales mucho más grandes que pueden afectar el accionar de cualquier equipo, impedimentos como por ejemplo:

  • Demasiada burocracia
  • Una mentalidad de comandar y controlar que demanda demasiados reportes del equipo
  • Fechas impuestas por un agente externo al equipo
  • Presión para llegar a una fecha establecida sacrificando la calidad del producto y afectando las vidas personales de los desarrolladores
  • Tendencia a que el trabajo se especialice y se vayan creando silos de conocimiento

Para erradicar los impedimentos anteriormente nombrados Scrum eventualmente requerirá de un rediseñó organizacional que implicará cambios radicales como estos:

  • No más Project Managers ni Oficina de Gestión de Proyectos
  • No más departamento de Quality Assurance con pruebas manuales
  • No más banca de recursos sin proyecto
  • No más pensamiento inmediatista enfocado en proyectos
  • No más outsourcing
  • No más distribución de los miembros del equipo en lugares geográficamente separados

Cabe enfatizar que en Scrum no tenemos una figura central de poder que reportar el progreso del equipo a la gerencia. 

Algunas prácticas de Project Management como disciplina puede que sean necesarias pero el equipo mismo será quien las realice sin tener una única figura de Project Manager.

En general buscamos distanciarnos completamente del enfoque Taylorista bajo el cual se tiene una figura central de poder que le dice a los demás que hacer. 

Existen algunos comportamientos de los clientes que pueden contribuir grandemente al éxito del Equipo Scrum, comportamientos tales como:

  • Estar disponible, involucrado y colaborar de cerca con el equipo
  • Entender que la calidad no viene gratis
  • No exigir que toda característica imaginable sea incluida en el producto
  • Reconocer y adoptar la adaptabilidad en el ciclo de desarrollo del producto 

Opuestamente hay otros comportamientos de los clientes que no contribuyen al éxito del equipo, comportamientos como por ejemplo:

  • Pedir un requerimiento, olvidarse de él y esperar a que sea entregado para recién opinar
  • Crear capas y capas de intermediaros que los separen cada vez más de los desarrolladores
  • Insistir en que se cumpla en su totalidad un alcance inicialmente definido
  • Pedir exactitud y precision en las estimaciones
  • Exigir velocidad en el desarrollo 

Finalmente, si la organización adopta Scrum sólo parcialmente acabará perdiendo beneficios tales como:

  • El rediseñar la organización completamente para incorporar prácticas de management modernas
  • La oportunidad de pagar Deuda Técnica, Organizacional y de Conocimiento
  • El desarrollo del verdadero potencial de las personas
  • La pérdida de ventajas competitivas frente a organizaciones más pequeñas pero más ágiles

Conclusiones

Muy comúnmente he visto la confusion de pensar que el rol del ScrumMaster es simplemente terminología nueva para reciclar la clásica idea de una figura de poder y autoridad, lejos de eso el ScrumMaster es alguien que sirve a los demás y no se sirve de ellos para crecer el mismo.

Para que ese rol de Lider Servicial sea realmente efectivo para el equipo y la organización se requieren cambios profundos que parten desde el rediseño del sistema organizacional hasta tener a bordo a la gente correcta.

Desde luego los cambios anteriores no podrán materializarse sin el total respaldo de la alta gerencia que debe estar convencida de que el cambio es necesario (a veces inevitable) y ve en Scrum el vehículo adecuado.

Finalmente, cambios profundos requieren tiempo y perseverancia y en este sentido el ScrumMaster debe ser paciente con el equipo, con la organización y desde luego consigo mismo. 

Bibliografia 

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

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

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

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

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

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

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

Martin08 Martin C. R., 2008. Clean Code: A Handbook of Agile Software Craftsmanship, Prentice Hall

Martin11 Martin C. R., 2011. The Clean Coder: A Code of Conduct for Professional Programmers, Prentice Hall

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

Fowler18 Fowler M., 2018. Refactoring: Improving the Design of Existing Code, 2nd Edition, Addison-Wesley Professional

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

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

Adzic12 Adzic G., 2012. Impact Mapping: Making a Big Impact with Software Products and Projects, Provoking Thoughts

Eventos de Scrum, Artefactos y Transparencia

Introducción

Los pilares de Scrum (inspección, adaptación y transparencia) inspeccionan grandemente el comportamiento de las personas en los eventos y desde luego trazan la linea matriz a la hora de emplear los artefactos.

Cabe señalar que más importante que un evento ocurriendo a tiempo es importante que durante el evento realmente ocurra la inspección y la adaptación posibilitada por la transparencia.

La adaptación, inspección y transparencia son mecanismos poderosos que con el tiempo pueden (y deben) alterar para mejor la forma de los eventos y artefactos. 

Inspección, Adaptación y Transparencia en los Eventos de Scrum

En el Daily Scrum el equipo tendrá la oportunidad de verse las caras y sincronizar para el día. Más aún, los miembros del equipo tendrán la oportunidad de escuchar que acerca de que están haciendo los demás miembros, como esta progresando el Sprint para todos y observar como se siente la gente en ese día.

Lo anterior sólo será posible si la gente que participa en este evento esta realmente presente en el momento (física y mentalmente). Al estar presentes en el momento se incrementan las chances de inspeccionar el trabajo y proponer adaptaciones pero desde luego lo anterior no seria posible si no existe un alto grado de transparencia y confianza para decir las cosas [Rubin12].

En el Sprint Planning la transparencia en necesaria para cosas tan vitales como que  todo el equip manifieste que realmente ha entendido del Objetivo del Sprint. La inspección permitirá al equipo hacer preguntas que clarifiquen su entendimiento de que hay que hacer y la adaptación permitirá crear un plan que parezca realista en ese momento del tiempo con el conocimiento que se tiene disponible.

Inspeccionar cualquier plan creado durante el Sprint Planning ya durante el Sprint es vital hacer adaptaciones pues de esta forma se añadirá realismo. Añadir realismo a un plan creado, en lugar de defenderlo a capa y espada, se alinea mejor con la agilidad [Auer02].  

En el Sprint Review los clientes tendrán la oportunidad de ver y principalmente utilizar el Incremente en el cual trabajó el equipo durante el Sprint.

Cabe hacer notar que la única forma de realmente ver como el cliente usuaria el producto es hacer que éste lo utilice, escuchar sus comentarios, dialogar y observar sus reacciones y expectativas.

De hecho lo anterior ofrece la oportunidad perfecta para tener transparencia, inspeccionar el grado de satisfacción (o no satisfacción) del cliente y realizar las adaptaciones necesarias en el Product Backlog.

Existen varios mitos acerca de este evento que vale la pena nombrar con el afán de desmitificarlos:

  • Primer mito, sólo el equipo muestra software funcionando pero el cliente no puede tocar el teclado
  • Segundo mito, en esta evento el equipo muestra software funcionando para el Product Owner que luego en otra reunión posterior le mostrará el producto al cliente y luego volverá al equipo con la retroalimentación que recoja
  • Tercer mito, el cliente sólo ve software funcionando en estos eventos y no debe ser molestado durante el Sprint 

En la Retrospectiva del Sprint una vez más la transparencia será vital para que cada miembro del equipo pueda manifestar su opinión sincera e inspeccionar todos juntos como equipo factores tales como:

  • el Sprint en general
  • el equipo
  • las relaciones e interacciones entre miembros del equipo
  • las relaciones e interacciones con personas externas al equipo
  • las relaciones e interacciones con el cliente
  • su forma de trabajo
  • los resultados que se alcanzaron
  • los puntos a mejorar

Si bien es cierto que la lista anterior podría seguir creciendo y nunca está completamente definida el objetivo es cultivar el espíritu de mejora continua [Ohno13]. 

Será precisamente ese espíritu de mejora continua el que hará que el equipo busque sin descanso eliminar desperdicios, construir un producto de calidad y mejorar en la práctica de su oficio. 

Las retrospectivas tendrán como uno de sus resultados principales el proveer ideas para realizar adaptaciones para el siguiente Sprint. Otro de los resultados de una retrospectiva es la celebración, aprecio y reconocimiento por las cosas que salieron bien en el Sprint.

Las retrospectivas no son sin embargo eventos en los cuales la gente del equipo deba quedarse callada mientras haya uno o dos que dominen la discusión. Tampoco es un evento en el cual se deba tener violencia en la comunicación, ataque o criticas hacia las personas o su trabajo [Lencioni02].

El ciclo de transparencia, inspección y adaptación debe también aplicarse a las retrospectivas para que así el equipo las vaya mejoran con el pasar del tiempo.

El Sprint y el Incremento 

Comencemos recordando que en Scrum un Sprint es un periodo de tiempo, generalmente menor a cuatro semanas, durante el cual el equipo trabaja de manera alineada para construir un Incremento del producto.

Durante el Sprint el Objetivo del Sprint no debería cambiar porque sino el equipo podría acabar construyendo varias piezas desconectadas del mismo producto. 

Tener un objetivo que sea lo suficientemente amplio pero que no cambie en su esencia permite mantener el alineamiento del equipo y contribuye a la consistencia del mismo.

Un objetivo que no cambia también puede contribuir a que el cliente tenga claridad respecto a que esperar al final del Sprint. Nótese en este punto que el alcance no es lo mismo que el objetivo, la idea siempre es pensar Lean y lograr el mismo objetivo pero con menos alcance.

La salida del Sprint es una pieza de software bien construida cuyos componentes cumplen con la Definición de Terminado y esta en condiciones de ser utilizada, más aún puede ser instalada y ejecutarse establemente en un ambiente de producción.

Lo anterior es de vital importancia porque:

  • permitirá recolectar retroalimentación real de los clientes y usuarios
  • hará evidente la capacidad y conocimiento del equipo
  • llevará al equipo un paso más cerca de la visión del producto 

Liberar públicamente un Incremento del Producto tienen repercusiones en otras áreas del negocio como: mercadeo, legal, finanzas, infraestructura, y otras; por tanto ésta es una decisión que debe ser tomada por el Product Owner.

De hecho es el Product Owner que en función del mercado, la infraestructura, los clientes y otros interés, dede trazar la estrategia de liberaciones públicas. Cualquiera que sea la frecuencia de liberaciones públicas definidas en esa estrategia no excusa al equipo de construir un Incremento del Producto potencialmente liberable al final de cada Sprint.

Sprint Planning

El evento de Sprint Planning se divide en dos mitades, la primera de ellas a la cual llamamos simplemente Sprint Planning One se enfoca en entender y discutir el quese hará durante el Sprint.

El que del Sprint esta alineado con el Objetivo del Sprint y normalmente es el Product Owner quien puede explicarlo mejor al equipo.

Nótese que la explicación del que esta conectada más al porque el cliente necesita las funcionalidades que se implementarán en el Sprint y como éstas potencialmente contribuirán valor al producto. 

La explicación se debe mantener en un nivel de abstracción lo suficientemente alto como para no entrar en la minucia y extender ésta parte de la reunión demasiado. Hablar de la minucia es precisamente el trabajo de comunicación que deberán hacer ya dentro del Sprint los desarrolladores con los clientes a mediada que avancen con la implementación.

La segunda parte del Sprint Planning, que es llamada de Sprint Planning Two, el Equipo de Desarrollo se concentra en discutir como se organizaran para realizar el trabajo y cuanto de este es factible terminar en el Sprint. 

Lo anterior implica que el Equipo de Desarrollo deberá descomponer items grandes, incorporar realismo estimándolos, y postergar para después items menos importantes [Beck00].

Las estimaciones no deben buscar la precisión y menos aún ser utilizadas por los jefes como un compromiso al cual estarán sujetos los miembros del equipo. Si esto acaba ocurriendo la tendencia lógica será que los desarrolladores inflen sus estimaciones como mecanismo de defensa.

En lugar de lo anterior la idea con las estimaciones es que se utilizaran como un indicador interno del equipo para tener una percepción de que podría o no caber dentro del Sprint.

Más importante todavía que las estimaciones es tener presente en este evento y durante todo el Sprint el concepto de flujo que se apoya grandemente en tener piezas pequeñas de trabajo moviéndose constantemente [Goldratt14]. 

Las estimaciones pueden realizarse usando diferentes técnicas y unidades pero el principio básico es mantenerlas simples y ligeras para que estimar y reestimar no sea un proceso penoso y conflictivo.

En mi experiencia las estimaciones con unidades de tiempo medidas en semanas, días, y horas es la que mejor funciona puesto que el tiempo es una unidad universalmente entendida y no conlleva ambigüedad [Jeffries00]. 

Al final del Sprint Planning Two el equipo debería acabar teniendo un plan no extremadamente detallado y con estimaciones precisas, sino más bien un plan lo suficientemente bueno como para hacer sentir a los miembros del equipo confiados en que podrán implementar los items más valiosos de su Sprint Backlog durante el Sprint [Patton14]. 

Daily Scrum

El Daily Scrum es diferente de una reunión tradicional de reportes de status debido a que:

  • No tiene la aspiración de reportar sólo con palabras el estado, impacto y calidad del trabajo que se esta realizando
  • No es para hablar acerca de un plan estático creado hace tiempo y como se está avanzando en función de ese plan
  • Debe ocurrir con la gente parada en un circulo, cara a cara, sin laptops ni celulares, y distantes del lugar donde ocurre el trabajo (gemba) 

El simple hecho de que este evento se realizará lejos del gamba ya conlleva de por si un grado de subjetividad pues el equipo no estará mirando el trabajo. Para que la inspección se vuelva realmente efectiva después de esta reunión habrá que “ir y ver” el trabajo [Ohno13].

Quizás uno de los grandes aportes de este evento es que hace que todo el equipo reconozca que para estar realmente empapados del trabajo necesitan ir y ver donde realmente ocurre, pero para permanecer comunicándose efectivamente y sintiendo el lado humano del trabajo necesitar pararse en un circulo para hablar, reír y compartir.

Por otro lado este evento tiene algunas restricciones introducidas con el fin de hacer que fluya mejor para el Equipo de Desarrollo, éstas restricciones son:

  • No jefes o gerentes presentes
  • Sin dispositivos electrónicos de ningún tipo
  • Debe terminar dentro de un timebox de sólo 15 minutos
  • No esta permitido culpar o juzgar a otros miembros del equipo en el círculo 
  • Sin “superiores”, todos somos iguales en el círculo

Para mantener este evento dentro del tiempo límite existen ciertas técnicas que pueden ayudar:

  • Hablar solamente acerca de los logros de ayer, los objetives para hoy y los impedimentos sólo si existiesen
  • Todos hablando cara a cara en un círculo
  • Posponer para después conversaciones largas 

Sprint Review

El Sprint Review es el evento formal en el cual el equipo presentará el Incremento a los clientes o usuarios finales para validar hipótesis y ver si el producto está avanzando en la dirección correcta. 

La definición anterior ha causado muchos problemas y confusiones pues muchas veces se ha entendido como el único momento en el cual los clientes pueden ver el producto en construcción. 

Volviendo a los pilares fundamentales de Scrum (inspección, adaptación y transparencia) nos daremos cuenta que la idea es tener retroalimentación constante y ésta se logra mostrando el producto lo más frecuentemente que se pueda (idealmente cada día y varias veces dentro de cada día).

El otro gran componente esta en el verdadero significado de “mostrar”, la retroalimentación más realista viene de clientes que tocan el teclado y el mouse e interactuan con el producto

Sin embargo, tener el Sprint Review al final de un Sprint es un excelente punto de inicio para equipos que están empezando con Scrum ya que ayuda grandemente a acercarse al cliente y crear el hábito de que debe ver el producto mientras se esta construyendo.

Existen algunas actividades clave antes y durante de este evento: 

  • Preparar un salón y tener toda la logística preparada para que el clientes pueda interactuar con el producto
  • El Equipo Scrum observara detenidamente como el cliente interactuará con el producto
  • El Producto Owner deberá explicar, generar y responder preguntas acerca de como el Incremento se conecta con los objetivos del negocio
  • El ScrumMaster facilitará el evento para hacer que fluya de forma dinámica, entretenida y productiva para todos

A su vez este evento producirá algunos resultados clave:

  • La validación de que el producto está avanzando en la dirección correcta y se necesita perseverar por algunos Sprints más
  • La indicación de que el producto no esta cumpliendo las expectativas del cliente o no va en camino de resolver sus problemas por lo cual el producto deberá pivotar 
  • La apreciación de las capacidades técnicas reales del Equipo de Desarrollo que les permite construir software cumpliendo con la Definición de Terminado

Continuando con la anterior, el trabajo del Product Owner y del equipo en general se basa en un conjunto de hipótesis que mientras más tiempo tarden en validarse más riesgo implicarán, de ahí la importancia del Sprint Review como mecanismo a través del cual los clientes usarán el producto para dar retroalimentación oportuna. 

Sprint Retrospective

Este evento de retrospectiva persigue que el equipo en su conjunto reflexionen acerca de sus prácticas, métodos, interacciones y disciplina para ver como podrían mejorar para el siguiente Sprint.

Al ser un evento de autocrítica y a la vez de valoración de lo que salió bien, require de valores cruciales como transparencia, sinceridad y empatía.

Precisamente será labor del ScrumMaster facilitar este evento para fluya dentro del respeto a los valores nombrados. 

Responsabilidades adicionales del ScrumMaster como facilitador de este evento incluyen:

  • Ayudar al equipo a mantenerse enfocado al rededor del tema central que es la inspección del equipo mismo, sus procesos y dinámicas internas
  • Mantener la discusión balanceada entre lo positivo del Sprint pasado y los puntos a mejorar
  • Ayudar a que el equipo mantenga la discusión alrededor de los problemas sin culpabilizar a nadie y más bien hablando de como se podrían mejorar las cosas
  • Mantener las retrospectivas vivas, dinámicas y entretenidas usando técnicas de facilitación efectivas y continuamente innovarlas [Roden15]

Existen acuerdos que ayudan a que el ScrumMaster pueda contribuir con los puntos anteriores, dos de los más importantes en mi experiencia son: hacer que esta sea un evento privado de sólo el equipo y mantenerlo corto (menos de 45 minutos). 

No tener retrospectivas o simplemente tenerlas pero mal facilitadas acaba degradando el poder creativo y la cohesion del equipo, pues problemas subyacentes se vuelven cada vez más agudos hasta el punto de fracturar las relaciones interpersonales y consecuentemente el trabajo mismo.

Las retrospectivas podrían también llegar a realizarse en función de los sucesos que las disparen, es decir en lugar de solamente tenerlas en un evento formalmente programado para el final del Sprint el equipo podría tener reuniones cortas y puntuales cada vez que identifiquen un punto de mejora tal como lo hacen en Toyota [Womack07].

Product Backlog

Para el Product Backlog el Product Owner tiene las siguientes responsabilidades:

  • Liderar su descubrimiento inicial con la participación de clientes y patrocinadores clave
  • Mantener el Product Backlog vivo y siempre reflejando su entendimiento más actualizado del producto, el mercado y el cliente
  • Ordenar el Product Backlog de manera de centrar el tiempo y capacidad del Equipo de Desarrollo en los items que vayan a retornar más valor una vez implementados

A su vez para el Product Backlog el ScrumMaster es responsable de:

  • Hacer coaching a los dos otros dos roles para que vean el Product Backlog como una herramienta valiosa de comunicación y ordenamiento de trabajo que va contribuir valor
  • Hacer coaching a los dos otros roles para que juntos mantengan el Product Backlog pequeño y con solamente el mínimo necesario de detalle

Finalmente los Desarrolladores para el Product Backlog serán responsables de lo siguiente:

  • Proveer estimaciones y principalmente reestimaciones que contribuyan realismo
  • Refinarlo semanalmente en el evento de Backlog Refinement Meeting
  • Clarificar sus items con los creadores originales del requerimiento

Las responsabilidades anteriormente nombradas para cada rol sirven también para hacer énfasis en que el Product Backlog, al igual que los demás artefactos de Scrum, son elementos articuladores entre los roles.

El Product Backlog como tal debe tener las siguientes características:

  • Es dinámico y cambiará constantemente en función del aprendizaje del equipo y el descubrimiento del cliente
  • Esta ordenado y se reordenará constantemente con el afán de poner la energía del equipo en la implementación de primero los items más importante para el negocio 
  • Es finito y alcanzable en un horizonte cercano de tiempo
  • Es público y cualquier miembro del equipo puede verlo y editarlo pero solo el Product Owner puede cambiar el orden 

Muchas veces las metáforas son útiles para que un equipo acabe entendiendo un artefacto y lo aplique adecuadamente en el día a día [Auer02]. En tal sentido he encontrado útil asociar el Product Backlog con la metáfora de una lista de supermercado que lógicamente es dinámica, se ordena por prioridades dictadas por tiempo, dinero y preferencias, es finita, y es visible para toda la familia. 

Dentro del Product Backlog existen componentes a los cuales prefiero llamar simplemente items que deben cumplir con ciertas características:

Están orientados al cliente

  • Contribuirá valor al producto una vez implementado
  • No se detallan usando documentos sino que se conversa acerca de ellos
  • Se deben descomponer en items más pequeños que puedan ser implementados manteniendo un flujo constante

De manera general podemos considerar que los items en el Product Backlog son marcadores de posición para tener conversaciones acerca de ellos y su potencial valor en el producto. El punto es que esos items son promesas de conversaciones en lugar de documentos estáticos escritos a detalle [Larman17]. 

Sprint Backlog

El Sprint Backlog tiene las siguientes características esenciales:

  • Es creado por el Equipo de Desarrollo que lo utilizará activamente durante el Sprint
  • Contiene solamente información primaria para no sobrecargarlo demasiado
  • Puede contener estimaciones que son indicativas pero no compromisos inamovibles 

Es más que seguro que el Sprint Backlog ira cambiando a medida que los desarrolladores empiecen a trabajar en los items para el Sprint. 

Por lo anterior los desarrolladores son totalmente responsables de reestimar las tareas −en las cuales se descompusieron los items− cuando lo crean necesario, seguir descomponiendo, o cambiar el orden de las tareas. 

Sin embargo el Product Owner debe ser necesariamente consultado si tales cambios implicaran un impacto en la profundidad o anchura del alcance de la implementación del item. 

Definición de Terminado

Tener una Definición de Terminado común a varios Equipos Scrum se hace necesaria por las siguientes razones:

  • Brindará claridad para todo el mundo acerca de qué se considera realmente terminado lo cual eliminará posibles malos entendidos y desconexiones
  • Ayudará a que los equipos se comuniquen mejor a través del código ya que todos llamarán terminado a lo mismo

Aún cuando todos los equipo parten de una Definición de Terminado común es posible que algún equipo decida modificarla para hacerla más estricta o para llevarla cada vez más cerca a un ambiente de producción [Humble10].

No se puede decir que una Definición de Terminado sea buena o mala, pero si es cierto que ers más valiosa cuanto más cercana está de poner código en producción en tiempos cada vez más cortos [Forsgren18].

De manera más general, un equipo Scrum puede decidir modificar su Definición de Terminado por los siguientes motivos:

  • Un equipo encontró una Definición de Terminado aún más poderosa y ahora desea contagiar a otros equipos
  • Durante su retrospectiva un equipo observó que su Definición de Terminado no es lo suficientemente estricta o todo lo contrario
  • En el Sprint Review se están presentando items con deuda técnica o funcional 

Conclusiones

Inspección, adaptación y transparencia son mecanismos poderosos que Scrum emplea dentro de su forma de trabajo adaptativa que busca acomodarse bien al cambio del alcance. 

Cambio que a su vez ocurre por la naturaleza dinámica del mercado y/o por la incertidumbre respecto a que esperan realmente los clientes que haga el producto para ellos.

Estos tres pilares están presentes en los eventos y artefactos de Scrum y deben ser empleados por el Equipo Scrum como parte de su diario accionar.

La carencia de estos pilares no sólo limitara Scrum sino que trae consigo el riesgo de creer −inocente o mal intencionadamente− que se esta haciendo Scrum cuando en realidad es Scrum sólo de nombre.

Finalmente, Scrum no se basa en herramientas pesadas ni caras sino que tiene como eje motor al equipo y su sistema de principios, creencias y valores.

Bibliografia 

Rubin02 Rubin K., 2012. Essential Scrum: A Practical Guide to the Most Popular Agile Process, Addison-Wesley

Auer02 Auer K., Miller R., 2002. Extreme Programming Applied, Addison-Wesley

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

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

Beck00 Beck K., Fowler M., 2000. Planning Extreme Programming, Addison-Wesley Professional

Goldratt14 Goldratt E. M., 2014. The Goal: A Process of Ongoing Improvement, The North River Press

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

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

Roden15 Rosen 15., 2015, Fifty Quick Ideas to Improve Your Retrospectives, Neuri Consulting LLP

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

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

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

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

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

Roles en Scrum

Introducción

Una de las principales contribuciones de Scrum es que definió más claramente tres roles que son los que se encuentran dentro de un equipo, enfatizando que tres y sólo tres roles son necesarios.

Sin embargo con el paso de los años estos tres soles han sido mal entendidos principalmente porque las organizaciones tratar de hacer una equivalencia directa con cargos jerárquicos existentes. 

El primer punto de cambio proviene de que precisamente las organizaciones deben darse cuenta de que tienen que cambiar su estructura jerárquica formal hacia algo más ligero y simple. 

Los roles tampoco fueron creados para hacer un plan de carrera ya que ellos coexisten con el mismo nivel de jerarquía y autoridad dentro del equipo. Dicho de otra manera, cada rol esta en relación de pares con los otros dos roles. 

El equipo

En principio hay que hacer notar que en terminología Scrum existen dos equipos:

  • El Equipo Scrum que aglutina a todos los roles
  • El Equipo de Desarrollo que aglutina a los Desarrolladores

Personalmente creo que esta separación conceptual contribuye muchas veces confusión ya que la gente empieza a preguntarse cosas como ¿si soy Desarrollador a que equipo pertenezco?

Considero entonces que es mucho más sencillo utilizar el termino Equipo para referirse a las personas que trabajan juntos en el desarrollo de un producto [Larman17].

Tamaño del equipo

La preferencia siempre es tener equipos pequeños puesto que esto facilita la colaboración e interacción efectiva. Esta demás decir que un equipo pequeño se comunicara efectivamente si todos sus integrantes trabajan desde la oficina y comparten la misma mesa.

Sin embargo cuando un equipo es demasiado pequeño, digamos dos personas, no existe suficiente diversidad de opinion ni tampoco suficiente gente para cada rol. Un equipo demasiado pequeño también tiene menos posibilidades de avanzar rápido pues simplemente no hay suficientes desarrolladores que escriban código.

En el otro extremo, un equipo que se acerca o pasa la decena de integrantes se vuelve ineficiente debido a: problemas de comunicación y coordinación, malos entendidos, desocupación, y  especialización excesiva.

Por tanto llegamos a que un tamaño recomendable de equipo debería ser de más o menos siete integrantes incluyendo todos los roles. Sin bien la teoría dice que podemos aumentar o reducir dos personas mi recomendación es que tengamos siete como el número máximo de integrantes para un equipo.

Los Tres Roles

Los tres roles de Scrum son los siguientes:

  • ScrumMaster
  • Product Owner
  • Desarrollador

Cada uno de estos roles tiene un enfoque diferente:

  • ScrumMaster enfocado en Scrum, la gente, los procesos adaptativos, el cambio organizacional, la motivación, el trabajo en equipo
  • Producto Owner enfocado en el producto, el cliente, el mercado, la estrategia, el mediano y largo plazo
  • Desarrolladores enfocados en en la calidad del código, en las prácticas técnicas, la táctica, en aprender el lenguaje especifico del cliente, y el aprendizaje constante

No existen roles adicionales ni deberían existir; no existe por ejemplo el rol de Manager o Project Manager pues el equipo se maneja a si mismo y no hay una figura central de autoridad.

Tampoco existe roles de Lideres Técnicos o Arquitectos porque las decisiones técnicas se toman en base al consenso y conocimiento de los desarrolladores. 

El liderazgo como tal existe pero es primero rotativo dependiendo del tema o coyuntura y segundo voluntario pues la gente decide a quien seguir. 

Derechos y Responsabilidades del Product Owner 

El Product Owner tiene los siguientes derechos:

  • Abortar el Sprint si identifica que el Incremento del Producto perdió todo  valor de negocio para el cliente
  • Tener la palabra final acerca del orden del Product Backlog
  • Pedirle a los desarrolladores que en cualquier día del Sprint le muestren software funcionando, bien construido y corriendo en un ambiente integrado preferentemente de producción

El que un Product Owner no pueda ejercer sus derechos es un indicador claro de que algo no esta funcionando bien y es labor suya y del resto del equipo (e incluso la organización en su conjunto) trabajar para que pueda ejercerlos.

Si bien el Producto Owner tiene derechos también tiene obligaciones, alguna de ellas son:

  • Maximizar el potencial retorno de la inversión identificando características del producto y ordenando esas características en una lista (Product Backlog)
  • Trabajar dedicadamente para que el Product Backlog sea visible, pequeño, adaptativo y claro para todo el equipo y clientes
  • Conectar a los desarrolladores con los clientes que originaron los requerimientos para que puedan hablar directamente y facilitar la comunicación de primera mano
  • Ser el guardian de la vision del producto, es decir, ser quien tenga claro que está construyendo el equipo, para quien, en cuanto tiempo y con que impacto esperado
  • Mantener el Product Backlog ordenado y alineado con los objetivos de negocio que se persiguen con la construcción del producto

Nótese que no menciono como una de las responsabilidades del Product Owner el escribir historias de usuario ya que éste es uno de los malos entendidos más grandes acerca de este rol.

Las historias de usuario no se deben escribir por las siguientes razones [Larman10]:

  • El lenguaje escrito no es la forma más eficiente y económica de comunicación
  • Historias de usuario detalladas con lenguaje escrito eliminan la necesidad de comunicación oral, debate y creatividad colectiva
  • Mucha escritura hace que el equipo invierta tiempo excesivo analizando y redactando documentos convirtiendo Scrum en una cascada dividida en fases
  • Al escribirse las historias se disminuye significativamente la necesidad de que el cliente hable con los desarrolladores y viceversa, en Scrum queremos exactamente lo opuesto “colaboración con el cliente”

Las historias, porque el nombre correcto es “historias” y no “historias de usuario”, se crearon para tener presente un patrón de comportamiento en el cual los desarrolladores interactúan con los clientes de manera frecuente [Beck99]. 

Derechos y Responsabilidades del ScrumMaster

El ScrumMaster tiene derechos tales como:

  • Llamar la atención del equipo cuando hacen algo completamente desviado de la esencia de Scrum pero lo llaman Scrum
  • Tener el respaldo del nivel más alto de gerencia para tratar de cambiar el sistema organizacional dentro del cual opera el equipo
  • Tratar de extender Scrum muchos más allá del equipo para contagiar a toda la organización y provocar su transformación 

Es importante hacer notar que el simple hecho de empezar con Scrum es de por si disruptivo para muchas organizaciones todavía ancladas en prácticas Tayloristas. Como corolario de lo anterior no se puede esperar que al adoptar Scrum todo siga como antes, por el contrario Scrum −si su adopción es exitosa− acabará transformando una organización que comenzará a emplear prácticas de administración modernas [Hamel07]. 

Las obligaciones del ScrumMaster incluyen por ejemplo:

  • Crear, cultivar y expandir un ambiente de aprendizaje continuo donde el equipo se sienta cómodo experimentando, fallando y aprendiendo
  • Cambiar al equipo y las dinámicas de la organización
  • Ayudar a que el equipo se comunique efectivamente entre sus miembros pero también externamente con los clientes y el resto de la organización
  • Colaborar con el equipo para despejar obstáculos
  • Contribuir para el equipo se mantenga enfocado y cercano al lugar donde realmente ocurre el trabajo (gemba) 
  • Insertar en el equipo la mentalidad de siempre andar buscando y eliminando formas de desperdicio [Ballé14] 

Derechos y Responsabilidades del Desarrollador

Los desarrolladores tiene derechos como por ejemplo:

  • Sentirse cómodos y respaldados para decir “no se” 
  • Ser capaces de autoorganizarse y decidir por si mismos como hacer el trabajo
  • Invertir tiempo, esfuerzo y energía para crear un producto de software bien construido que los haga sentir orgullos de su trabajo y dominio de su artesanía

Que los desarrolladores entiendan sus derechos y tengan el respaldo de la organización para hacerlos valer es vital. De nada serviría que los desarrolladores crean tener estos derechos y la gerencia se los quite o simplemente les diga como hacer la cosas y los presione al punto de no dejarlos invertir tiempo y esfuerzo para crear software con calidad.

El conocimiento de la artesanía de software es vital pues sólo a través de él los desarrolladores aprenden los fundamentos de su oficio, fundamentos que deberían pasarse de generación en generación y no redescubrirse para cada producto. Artesanos de software con conocimiento del oficio muchas veces son necesarios para capacitar al equipo [Mancuso15].

Si hablamos de las responsabilidades de los desarrolladores, estas incluyen entre otras:

  • Aprender una segunda, una tercera y de ser posible hasta una cuarta especialidad técnica para así poder construir más efectivamente al equipo
  • Aprender el lenguaje y terminología del dominio de conocimiento con el que se esta trabajando para comunicarse eficientemente con el cliente
  • Construir software utilizando prácticas modernas para el desarrollo de software [Beck99]
  • Evitar desperdicios en el trabajo y procesos que retrasen la retroalimentación y comunicación efectiva con el cliente
  • Manifestar su opinión cuando se sienten sobrecargados o cuando sienten que el producto esta yendo en la dirección equivocada 

Características del Equipo de Desarrollo

El Equipo de Desarrollo debe reunir ciertas características para realmente funcionar bien [Larman08], características tales como:

  • De larga vida, que quiere decir que los miembros del equipo se conocen de hace mucho y viene trabajando años juntos
  • Co-ubicado, que literalmente implica que todos los miembros del equipo trabajan desde la misma oficina y se están sentados compartiendo la misma mesa de trabajo
  • Sin jefes formalmente asignados, esto implica que no hay una jerarquía impuesta sino lideres naturales que el resto del equipo decide seguir dependiendo de las circunstancias
  • Autoorganizados, que pone el poder (y la responsabilidad) en los miembros del equipo para decir como se organizaran para llevar a cabo el trabajo
  • Empoderados, que quiere decir que los miembros del equipo toman decisiones técnicas por si mismo sin tener que consultar o ser aprobados por alguna otra persona

Las características anteriores parecen ser muy caras y contradicen la tendencia de tener outsourcing y equipo geográficamente distribuidos, pero si lo pensamos bien, hacemos las cuentas, y le preguntamos a la gente de los equipos que hacen el trabajo encontraremos que tienen sentido.

Desde una perspectiva sistema, si tenemos un equipo visto como un sistema que tiene miembros pasajeros, que esta globalmente distribuido, que tiene jefes, que recibe ordenes, y que require aprobaciones entonces acabamos con un sistema más complejo, jerárquico, lento y burocrático. 

Scrum desde luego no quiere lo anterior sino más bien persigue la noción de simplicidad sistémica donde un equipo opera de la manera más efectiva posible con la menor complejidad.

El Product Owner es una Sola Persona

Existen varias razones para concentrar la responsabilidad de Product Ownership en una sola persona, una de las más importantes es que una persona en lugar de un comité acorta el proceso de toma de decisiones y ayuda a mantener la integridad del producto.

El concepto de tener una persona con capacidad total de decisión sobre el producto no es nuevo, de hecho se inspira en el Chief Engineer de Toyota que tiene todo la responsabilidad sobre el desarrollo y puesta en producción de un vehículo.  

Aún cuando pensamos o necesitamos escalar Scrum para múltiples equipos lo más recomendable es mantener un solo Product Owner y un sólo Product Backlog para un producto que será desarrollado por centenares de desarrolladores [Larman17].

Un Product Owner para ser efectivo en su rol debe realmente estar inmerso en el mercado y entender a cabalidad sus necesidades, más importante todavía debe ser capaz de anticipar los movimientos del mercado. 

El Product Owner Tiene la Palabra Final Acerca del Producto

Aún cuando los usuarios, los clientes, y los ejecutivos pueden tener opiniones respecto al rumbo del producto, es la prerrogativa del Product Owner decidir que va o no en el Product Backlog y en que orden. 

Como el Product Owner tiene la palabra final sobre el producto él debe buscar tener ciclos cortos de retroalimentación para validar sus ideas e hipótesis acerca del producto.

Los ciclos cortos de retroalimentación a su vez tienen dos precondiciones:

  1. Tener software funcionando en todo momento
  2. Tener acceso a clientes o usuarios reales en todo momento

Si lo anterior no es posible todavía mi sincera recomendación es trabajar hasta conseguir que si lo sea porque no hay sustituto para la retroalimentación real

La retroalimentación real que recolecta el Product Owner de los usuarios finales, el mercado e inclusive el equipo, le permite redireccionar el curso del producto o validar que se está avanzando en la dirección correcta, pivotear o perseverar en terminología de Lean Startup [Reis11].

Sólo Product Owner Aprueba Trabajo para el Equipo de Desarrollo

El Equipo de Desarrollo esta compuesto por desarrolladores a tiempo completo que trabajan en un sólo producto a la vez y es el Product Owner quien decide que se trabajara en cada Sprint, romper esta regla trae consecuencias como:

  • Pérdida de enfoque del equipo con el consiguiente costo de reenfoque
  • Demasiadas distracciones porque el trabajo viene desde multiples fuentes causando retrasos, peleas internas, retrabajo, y confusión de prioridades

Cabe hacer énfasis en que si bien el Product Owner es quien aprueba que trabajo se hará, ya a la hora de hacer el trabajo los desarrolladores deben comunicarse directamente con los clientes para así entender que se debe hacer e ir recolectando retroalimentación a medida que avanzan con el trabajo.

De hecho una de las grandes confusiones con el rol del Product Owner es pensar que él es el único que puede y debe hablar con los clientes, si esto acaba ocurriendo el Producto Owner se convertirá en el recurso critico que provocará un cuello de botella y consecuentemente retrasará el flujo de trabajo [Goldratt90].

Desde la teoría de la comunicación se sabe que mientras más nodos se añadan en un canal de comunicación más tarde y distorsionado llegará el mensaje. Es por esta razón que tampoco conviene tener un Product Owner que este de hombre en el medio entre el equipo y el cliente. 

Conclusiones

Los roles de Scrum son solo tres y deben mantenerse así pues no se necesitan más. Cuando se observan problemas en la adopción de Scrum buscar en el número de roles o añadir más personas normalmente no es la solución, el problema muchas veces está en otro lugar.

Tres roles implican simplicidad y es que en esencia Scrum es minimalista y Lean, es importante siempre recordar lo anterior para no complejizar el Equipo Scrum con nuevos roles o figuras de poder innecesarias.

Los roles son solamente eso roles pero no cargos jerárquicos que limitan responsabilidad y derechos de manera estricta. Al final el trabajo en equipo y la colaboración debe sobreponerse por el encima del dogma que puede llevar a que alguien diga “yo no hago ese trabajo porque no esta definido dentro de mi rol”.

Bibliografia 

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

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 

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

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

Mancuso15 Mancuso S., 2015. The Software Craftsman: Professionalism, Pragmatism, Pride, Prentice Hall

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

Reis11 Reis E., 2011. The Lean Startup, Crown Business

Goldratt90 Goldratt E. M., 1990. Theory of Constrains, The North River Press

Teoría de Scrum

Introducción

Scrum no es un marco de trabajo novedoso ni que se haya inventado siquiera en la década presente, por el contrario ya fue teorizado por Schwaber y Beedle el 2001 [Schwaber01]. Sin embargo pese a su antigüedad su popularización se ha dado recién en los últimos años. 

La tardía entrada de Scrum en varios países y contextos no es necesariamente un síntoma de atraso tecnológico o cognitivo, por el contrario trae la ventaja de que Scrum llega ahora más pulido y cargado de experiencias de cosas que se intentaron pero no acabaron funcionando bien y que por eso mutaron hacia otros conceptos.

También es oportuno mencionar que Scrum no se creo de la nada sino que más bien viene fuertemente influenciado por Toyota, Lean y Extreme Programming. Considero necesario hacer esta puntualización para no pensar que Scrum es solamente unas pocas páginas de teoría ligera. 

Scrum: Una definición corta

Scrum es un marco de trabajo ligero con el cual un equipo de funcionalidad cruzada desarrolla productos de manera iterativa e incremental.

Scrum: Una definición más larga

Scrum esta basado en el poder sinérgico y creativo de un equipo, no es un marco de trabajo de aplicación individual ni tampoco se adapta bien para grupos de personas aleatoriamente reunidas que no son un equipo.

Debido al fuerte componente humanista que implica el trabajo en equipo, las interacciones y resultados que se logran dentro de un equipo Scrum difícilmente son directamente extrapolables hacia otros equipos de incluso la misma empresa y peor aún de otras empresas.

En este sentido podríamos decir que Scrum es altamente situacional y dependiente del contexto temporal. Lo anterior podría hacer parecer que Scrum es sui generis pero en realidad es como cualquier deporte de equipo en el cual cada partido es diferente.

Al igual que con los deportes en equipo ocurre con Scrum que las reglas de juego son simples y conceptualmente sencillas de entender pero luego requieren práctica, pasión, constancia, adaptabilidad y disciplina para poder jugar bien en el contexto del desarrollo de un producto. 

Elementos clave de Scrum

Scrum tiene tres elementos clave, a saber:

  1. Entregar software funcionando al final de cada Sprint
  2. Inspeccionar y hacer adaptaciones diariamente
  3. Confiar en el equipo

Imaginemos ahora que ocurriría si estos tres elementos claves no estarían presentes:

  1. Al no tener software funcionando al final de cade Sprint no se estaría respetando la Definición de Terminado y se estaría creando la falsa impresión de que estamos avanzando cuando en realidad existe gran acumulación de deuda técnica.
  2. Cada día se trataría de trabajar de acuerdo al plan inicialmente creado sin tomar en cuenta variaciones producidas por el cliente, el mercado, la tecnología o la misma gente del equipo; consecuentemente el equipo no sería adaptativo y por el contrario caería en la mentalidad rígida de ejecutar un plan sin importar lo demás. 
  3. Al no haber confianza la gerencia cae en el síndrome de pedir reportes detallados para tratar de entender con métricas y palabras escritas el código. La desconfianza también puede existir dentro del equipo donde sus integrantes no se apoyan ni piden ayuda debido a disfuncionalidades subyacentes.

Valores de Scrum

Un equip Scrum es de por si diverso en términos de género, conocimiento, experiencias de vida, edad cronológica, etc. Tanta diversidad es beneficiosa pues ofrece oportunidades de aprendizaje, variedad de opiniones y puntos de vista.

Sin embargo, la diversidad pueden hacer que un grupo de personas nunca llegue a cuajar como equipo si las personas no tienen un sistema de creencias común; es precisamente a este sistema de creencias que los creadores de Scrum llaman Valores de Scrum [Schwaber04].

Los Valores de Scrum son:

  • Enfoque
  • Coraje
  • Compromiso
  • Apertura
  • Respecto

Aunque estos valores son creencias y no algo tangible, son imprescindibles para un equipo que quiere realmente adoptar Scrum. Más aún, estos valores deben también estar presentes dentro de la empresa en la cual opera el equipo Scrum. 

Las personas dentro de cada rol deben realmente vivir en su día a día estos valores para que estos estén presentes en cada evento y artefacto de Scrum. 

Así por ejemplo durante el Sprint el equipo necesita mantenerse enfocado, tener el coraje de innovar, comprometerse con el objetivo del Sprint, estar abierto a aprender nuevas cosas y mantener una relación de respecto con las demás personas. 

Proceso de Control Empirico

Scrum implementa un proceso de control empírico basado en observaciones de la realidad en lugar de basarse en planes ficticios quedados en el tiempo. 

Es de esta manera que llegamos a que empirismo en Scrum significa trabajar basados en experiencias, hechos y observaciones y no confiar ciegamente en una planificación detallada realiza antes de empezar a trabajar.

El empirismo se basa en tres pilares fundamentales:

  • Inspección
  • Adaptación
  • Transparencia

Aplicando inspección posibilitada a la vez por transparencia el equipo Scrum hace adaptaciones (diariamente o al menos en ciclos cortos) en su forma de trabajo, sus interacciones, sus prioridades y en el alcance realizable dentro del Sprint.

Aunque tenemos empirismo ciertas cosas como: la duración del Sprint, los miembros del equipo, o el stack tecnológico; son definidas al principio de un Sprint y deberían mantenerse constantes (salvo excepciones) para no introducir demasiada disrupción.

De manera general en Scrum buscamos mantener un delicado balance entre lo empírico y lo definido. Constantemente tratamos de mejorar el lado definido de las cosas a través de ideas que salen del aprendizaje y experimentación constante.

Scrum es un Marco de Trabajo

Como fue definido por sus creadores [Schawaber07] y [Schawaber12]  Scrum es un marco de trabajo con el cual la gente puede trabajar de manera adaptativa para tratar de resolver problemas complejos, la resolución de estos problemas de forma productiva y creativa esta orientada a la creación de productos que aporten el mayor valor posible a sus consumidores finales.

Yendo un paso más atrás un marco de trabajo es una estructura básica que sirve de soporte a un sistema, un concepto, una idea o un texto. Por tanto un marco de trabajo se utiliza porque encima de él se quiere construir algo más. 

Scrum al ser definido como un marco de trabajo puede ser extendido y complementado con otros conceptos y herramientas. En este sentido Scrum es en realidad un meta-marco de trabajo que incorpora elementos empíricos de control.

Los elementos empíricos de control son los que precisamente nos indicarán si las extensiones que hacemos con el marco de trabajo son beneficiosas o por el contrario distorsiona el marco de trabajo y lo alejan de su esencia.

Scrum no es una metodología y menos una metodología ágil como comúnmente se cree. Es más, los creadores de Scrum nunca pretendieron crear una metodología pues una metodología es un conjunto de pasos científicamente estudiados que al ser aplicados siguiendo un orden metódico garantizan un resultado. 

Un marco de trabajo, en oposición a una metodología, esta minimalistamente definido e invita a la creatividad y complementación con herramientas, ideas, y prácticas importadas de otras disciplinas.

En términos simples: 

  • un marco de trabajo invita a la creatividad y require trabajo efectivo en equipo
  • una metodología invita al cumplimiento y requiere supervision y control efectivo.

Otra distinción fundamental es que en una metodología métricas duras y precisas son piezas fundamentales mientras que en un marco de trabajo toman relevancia la colaboración, el trabajo en equipo y la comunicación

Scrum requiere práctica dedicada

Debido a que Scrum es un marco de trabajo ligero conceptualmente fácil de entender  mucha gente y organizaciones tienden a subestimarlo y realizar solamente adaptaciones cosméticas.

Desde luego los cambios cosméticos son los más simples y en teoría baratos de hacer, el gran problema con ellos es que no acaban cambiando sistemicamente el diseño organizacional que es imprescindible para que Scrum florezca. Un problema secundario pero no menos importante es que los cambios cosméticos acaban creando desilusión después de un tiempo y la consecuentemente la falsa impresión de que Scrum no funciona.

La simplicidad conceptual de Scrum también provoca la falsa impresión de que es solamente un tema de leerse quince páginas, asistir a un curso de dos días y pasar un examen a libro abierto. Muy por el contrario Scrum tiene muchas pero muchas disciplinas aliadas y conocimiento complementario que solamente puede ser adquirido a través de la lectura, investigación y práctica constante.

Haciendo una analogía con la practica del yoga, una persona no puede esperar todos los beneficios que provee esta disciplina ancestral sin practicarla diariamente y un practicante devoto de yoga es además un lector e investigador que entiende a cabalidad los principios y fundamentos de su disciplina. 

Conclusiones

Scrum todavía tiene un camino muy largo por recorrer en su evolución teórica que se enriquece con la practica constante traducida en producción intelectual de contenido, basta ver nada más la cantidad de libros y otros materiales que llevan como tema central Scrum y han sido producidos en la última década. 

Sin embargo uno de los riesgos latentes es que Scrum sea mal entendido y consecuentemente mal aplicado, por eso el énfasis de este texto en los principios, valores, esencia e influencias que recoge Scrum.

Mucha gente afirma que para adoptar Scrum se requiere un cambio de paradigma mental, yo pienso que hay en realidad habría que empezar por un cambio de paradigma organizacional sistemático para de ahi recién derivar el cambio de comportamiento que consecuentemente acabará cambiando el paradigma mental.

Finalmente, adoptar Scrum es similar a adoptar cualquier otra disciplina, deportes o arte que apasiona a sus seguidores y que requiere tiempo, esfuerzo, dedicación y práctica constante para obtener sus verdaderos beneficios. 

Bibliografia 

Schwaber01 Schaber K., 2001. Agile Software Development with Scrum

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

Schwaber07 Schaber K., 2007. The Enterprise and Scrum

Schwaber12 Schaber K., 2012. Software in 30 Days: How Agile Managers Beat the  Odds, Delight Their Customers, and Leave Competitors in the Dust


Explicando Scrum con analogias

Recientemente tuve la oportunidad de colaborar con el Scrum Alliance para grabar un webinar en el cual explico, o al menos trato de hacerlo de la forma más simple posible, los roles de Scrum y el marco de trabajo usando analogías de deportes, música y otros ambitos.

El webinar esta disponible en el sito del Scrum Alliance y ojala sirva para aportar algo más de claridad sobre este tema.

No uso PowerPoint pero…

Recientemente tuve que preparar un slide deck con el contenido que imparto en mis cursos de CSM. Digo tuve porque era un requisito para una certificación.

Encontré la experiencia un tanto desafiante pues no acostumbro preparar slide decks en lo absoluto pues en mis clases utilizo técnicas de Training from the Back of the Room.

Sin embargo fue un ejercicio mental interesante tratar de poner por escrito algo del conocimiento que imparto.

Si alguno de Ustedes lectores tomó un curso de CSM conmigo encontrará que el slide deck difiere un tanto del contenido que imparto. Esto se debe a varios factores, quizás el más relevante sea que el slide deck debe estar alineado con los contenidos oficiales más actualizados del Scrum Alliance.

Bueno sin más preámbulo aquí comparto mi slide deck disponible en SlideShare, espero que les sea util aunque este en ingles.

Primer tour del 2019 en Costa Rica

Del 17 al 22 de junio estaré de regreso por Alajuela para dictar una serie de cursos, el primero de ellos sera un CSPO, el segundo un CSM y el tercero un A-CSM.

Como en anteriores ediciones de estos cursos el hotel donde se realizaran sera el Hampton Inn & Suites San Jose Airport.

Me queda en la memoria el grato recuerdo de la gente que participo en el anterior A-CSM donde profundizados el conocimiento de Scrum.

Y desde luego también recuerdo con afecto al lindo grupo de gente que fue parte del último CSM que dicté en tierra Costarricense.

Ahi nos vemos en junio, pura vida!!