El Problema de los Scrum Master

“Los Scrum Master están matando Scrum!”

¿de que va esto?

Cada día son más y más las organizaciones que comienzan a usar Scrum como framework ágil para enfrentar sus proyectos de tecnología, lo cual es bueno pero…

También son cada día más los Profesionales que veo ejerciendo el rol de Scrum Master en equipos que intentan ser ágiles y en donde el Scrum Master esta…muy demasiado lejos de su rol..

¿Qué pasa cuando pones a un Scrum Master en un equipo que no es ágil y donde el propio Scrum Master está aprendiendo Scrum o acaba de aprender Scrum?

Pues en la mayoría de los casos el equipo no termina haciendo Scrum, no se viven los valores o principios ni el pensamiento ágil, todo termina siendo un fracaso y la empresa termine diciendo… “eso de la agilidad son cuentos, no funciona!” o creen estar haciendo Scrum cuando no tienen ni la mitad de los reales beneficios.

Y es que la verdad a estas alturas no estamos para discutir si la agile funciona o no… agile funciona! existe evidencia, estudios, empresas, ejemplos, etc… lo que no funciona es como las empresas están intentado primeramente hacer agile (agile software delivery)

¿Que está pasando entonces?

Bueno varias cosas…
1° Se está llenando de Scrum Master sin experiencia o sin un pensamiento ágil por varias razones:
A.- Empresas envían a sus Jefes de Proyectos a cursos de Scrum en donde al cabo de 2 días terminan certificados o no…y finalmente la empresa piensa que ya tiene un Scrum Master y lo peor es que el antiguo jefe de proyecto también termina creyendo eso….pero en realidad su Pensamiento no cambio!
B.- Profesionales con buena intención están tomando cursos y certificándose de Scrum Master, como evolución de su carrera profesional, basándose en la demanda de roles del mercado. (lo que están muy bien). Pero la falta de experiencia y muchas veces no cambiar la forma de pensar les termina pasando la cuenta.

2° Supongamos que el nuevo Scrum Master si aprendió, tomo las prácticas y valores de la agilidad, las hizo suyas y es cómo ve la vida desde ahora!
A.- La empresa en realidad no entiende el Rol del Scrum Master y le sigue exigiendo y midiendo como un Jefe de Proyecto, obligándolo a seguir actuando y pensando de esa forma.
B.- Lo asignan a ser Scrum Master de 10 equipos…o es Scrum Master para 1 equipo pero Jefe de Proyectos en 3 más. Por tanto no llega un punto en que pueda desarrollar bien su rol.

Conclusión: Los Scrum Master están matando Scrum!

Bueno….en realidad no…

Lo que está matando Scrum es:

  • La Faltan de profesionales con experiencia, aunque en mi caso, valoro más que la experiencia las ganas, valores y principios, el pensamiento ágil, el querer cambiar las cosas y no dejar de aprender.
  • La fuerte demanda del Rol y el oportunismo (poco criterio) de organismos por vender certificaciones de Scrum Master lo que termina desprestigiando este bonito rol.
  • La falta de guía y humildad que nuevos Scrum Master están teniendo y creer que la agilidad son solo prácticas para memorizar y no una forma diferente de pensar y enfrentar los desafíos.
  • El poco entendimiento de las organizaciones respecto de las implicancias de hacer Scrum o ese “trade off” cosas a las que debes renunciar, dejar de hacer o cambiar para obtener los beneficios de Scrum.

¿Qué podemos hacer?

1° Educar a las organizaciones y dejarles claro que:

  • Las “metodologías” ágiles vinieron para quedarse.
  • Su adopción va más allá de la técnica, va en el involucramiento entre TI y Negocio respecto de nuevas formas de colaboración, comunicación y trabajo.
  • Los líderes y managers no pueden quedar fuera de su adopción y son vitales para que su adopción funcione en cualquier compañía. Por tanto, deben educarse.
  • Son mucho más un tema de desarrollo de software, TI y Negocio necesitan involucrarse y trabajar juntos por objetivos comunes.
  • Implican fuertemente cambiar la forma en que se piensa, decide y trabaja.

2° Guiar a los nuevos Scrum Master con temas como:

  • Entender que certificarte como Scrum Master es solo el primer paso a agile y jamás ha pretendido ser una consagración, es solo el primer escalón.
  • Busca un referente, guía, redes, alguien que te pueda ayudar a recorrer este largo camino.

    Si eres o fuiste Jefe de Proyecto:
  • Entiende que tu foco son básicamente 3 cosas, que el Scrum Team se desarrolle como un equipo agile y mejore continuamente, Que el developmente Team y el Product Owner piensen y trabajen en un enfoque “Value Driven” y no “Plan Driven” y por último ser un agente de cambio fuera del equipo.
  • Tu foco no debe estar en el objetivo del Sprint (ese es el pensamiento de un jefe de proyectos que vive la urgencia del hoy y pone toda su energía en cumplir los compromisos de la gantt)
  • Tu foco inicial debe estar en el desarrollo del equipo, debes preguntarte constantemente ¿Cómo me hago dispensable para el equipo?, ¿Cómo desarrollo capacidades en ellos para que puedan perseguir y lograr sus objetivos?
  • Y por último…lee, comienza a leer.


Saludos!

Sponsored Post Learn from the experts: Create a successful blog with our brand new courseThe WordPress.com Blog

Are you new to blogging, and do you want step-by-step guidance on how to publish and grow your blog? Learn more about our new Blogging for Beginners course and get 50% off through December 10th.

WordPress.com is excited to announce our newest offering: a course just for beginning bloggers where you’ll learn everything you need to know about blogging from the most trusted experts in the industry. We have helped millions of blogs get up and running, we know what works, and we want you to to know everything we know. This course provides all the fundamental skills and inspiration you need to get your blog started, an interactive community forum, and content updated annually.

Management 3.0

Redefiniendo el Liderazgo, la gestión del sistema por sobre la de las personas.

Nunca olvides que mejores principios, no mejores prácticas, es lo que realmente necesitan las organizaciones. 

— Management 3.0

¿Que es un equipo ágil?

En pocas palabras se podría definir como un equipo de alto desempeño, cross-funcional, auto-gestionado, con altos niveles de cooperación, comunicación, mejora continua y orientados a entregar valor al cliente.

Tener un equipo así no es fácil, requiere tiempo, dedicación e involucramiento por parte de los lideres o managers de cualquier organización, pero no un involucramiento del tipo Command & Control, sino uno dedicado a desarrollar equipos empoderados y orientados a la resolución de problemas. Muchos lideres o jefes o managers cual quiera sea su rol aun prefieren dedicarse al “micro-management” y decirte a sus equipos el como trabajar y que hacer todo el tiempo, y mientras mas parecido lo hagan a como el jefe dijo…mejor evaluados son, aun que quizás lo que hicieron no tiene valor para la compañía, en consecuencia terminan liderando equipos dependientes de cada palabra o acción que comanden, sesgando su visión de managers a una operacional y no a una estratégica como debería ser.

Todo lo anterior para mi describe a un no muy buen.. Líder o Gerente.

Bueno por otro lado hay lideres o gerentes que si buscan desarrollar a sus personas, equipos, ponerles objetivos y que ellos como profesionales busquen la mejor forma de lograr esos objetivos. Lamentablemente esto no se enseña en las escuelas de negocio o de management  y depende de la propia habilidad del Líder o Gerente desarrollar estas capacidades en sus equipos.

aproximadamente en 2011 Jurgen Appelo  http://jurgenappelo.com/  lanzo el libro Management 3.0 “Leading Agile Developers, Developing Agile Leaders”  https://goo.gl/Bh4bUb 

El cual explora claramente como el management es uno de los principales problemas o limitantes de tener equipos ágiles y también enseña una series de practicas que cualquier manager podría usar para desarrollar este tipo de equipos.

Por el titulo del libro podríamos decir que aun estaba muy orientado al software a pesar de que si releemos la definición que di arriba de equipo ágil, esta es en realidad aplicable a cualquier negocio y debería ser el sueño de cualquier Buen Manager.

El libro, sus ideas y las practicas descritas en él funcionaron bastante bien y comenzó a generarse todo un movimiento que busca finalmente tener equipos ágiles dentro de las empresas, ok…saquemos la palabra ágil ya que aun se relaciona mucho solo con el software…y déjenme decirlo de nuevo…

El libro, sus ideas y las practicas descritas en el funcionaron bastante bien y comenzó a generarse todo un movimiento que busca finalmente tener equipos motivados, auto-gestionados, de alto desempeño y felices.

En 2014 Jurgen publico el libro Woukout https://goo.gl/zDTT1j el cual describe una serie de juegos, herramientas y practicas para tener trabajadores motivados, comprometidos, mejores gerentes ( y menos gerentes también).

Finalmente en 2016 salio el libro Managing for Hapiness: Games, Tools and Practices to motivate any team  https://goo.gl/MHT3gj

entonces..

¿Que es Management 3.0?

El Management 3.0 es un movimiento de innovación, liderazgo y management que reinventa la forma de hacer liderazgo y ejecutar el management como grupo y no como una responsabilidad que descanse solo en los gerentes.

Describe y provee herramientas para desarrollar equipos de alto desempeño que trabajen junto a los managers para lograr los objetivos de negocio, dando prioridad a la motivación intrínseca de los trabajadores y su felicidad.

Enseña y describe formas de organizar y desarrollar equipos, conocerlos, motivarlos, generar y compartir conocimiento, dar espacio para experimentación, auto-organización,etc.

Todo lo anterior aplica perfecto para cualquier organización!

Posee mas de 30 practicas descritas en https://management30.com/practice/

Y mundialmente se hacen constantemente Cursos y Workshops de Management 3.0 a lideres, gerentes, ejecutivos, etc.

Las Fuerzas en Scrum

En Scrum existen 3 fuerzas representadas por cada uno de los roles que Scrum prescribe. Cada fuerza tiene un propósito y razón de ser y el Scrum Team debe buscar el equilibro de estas fuerzas.

¿Cuales son estas fuerzas?

  • do the right thing, hacer lo correcto, fuerza representada por el Product Owner a traves del manejo y priorización del Product Backlog, el le dice al Development Team que es en lo que deben trabajar, es decir, que es lo correcto por hacer.
  • do the thing right, hacer las cosas bien, fuerza representada por el Development Team, ellos deben enfocarse en hacerlo bien técnicamente, ellos saben y son los expertos en construir el producto o descubren cual es la mejor forma de construir el producto.
  • do it agile, hacerlo ágil, fuerza representada por el Scrum Master, el ayuda a todo el equipo a trabajar de manera ágil y a desarrollar el pensamiento ágil.

Estas fuerzas deben estar en equilibrio siempre si queremos hacer Scrum correctamente (por algo Scrum tiene estos roles no?)

Si por ejemplo solo nos enfocáramos en las fuerzas de do the right thing y do it agile estaríamos generando productos sin la calidad técnica necesaria, por tanto con una deuda técnica importante que haría que en el corto plazo nuestro producto fuera inmantenible y una bomba de tiempo.

Por otro lado si nos enfocamos solo en do the right thing y do the thing right, estaríamos generando el producto que el Product Owner quiere, pero muy probablemente con un exceso de análisis y tecnicismos que le quitarían agilidad al proceso, ya que el software siempre es mejorable, así como al arquitectura etc y si buscaríamos hacer siempre lo optimo técnicamente, no terminaríamos en varios Sprint haciendo que el Time to Market fuera excesivo.