Introducción

Un Scrum Master 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 Scrum Master 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” Scrum Master. Un indicador clarísimo de que la curiosidad infinita dejó de existir para un Scrum Master es hecharle un vistazo a su biblioteca personal y ver que esta leyendo.

Las competencias básicas de un Scrum Master 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 Scrum Master puede facilitar el trabajo del equipo a través de varias formas que incluyen:

• Ayudarlos a comunicarse más efectivamente descubriendo/re-descubriendo 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, supervisión 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 Scrum Master 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 Scrum Master decida utilizar es importante recordar que en su papel de facilitador no le corresponde imponer o forzar una decisión 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 auto-organizados 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 Scrum Master desde la disciplina del Coaching es precisamente ayudar a que un equipo descubra  como auto-organizarse 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 Scrum Master 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 Scrum Master 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 Scrum Master.

El Scrum Master 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 Scrum Master 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 Scrum Master 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 Scrum Master 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 Scrum Master presta al Equipo de Desarrollo es precisamente ayudar a que descubra cómo crear código limpio [Martin11]. Para ayudar en este descubrimiento el Scrum Master 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 Scrum Master 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 Scrum Master 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 confusión 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 Scrum Master 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

Artículo Original: https://percella.com/2019/02/11/competencias-basicas-de-un-scrummaster/