Scrum Master o Jefe

Hace bastante tiempo que vengo observando que todavía está confuso el rol del Scrum Master.
En algunas ocasiones escuché sorprendido frases como... Necesitamos alguien que se plante frente al equipo o... en tu experiencia en el rol ¿has despedido a alguna persona?
Con esta última me dí cuenta de que había mas confusión de la que pensaba. Por lo menos tuvo la cortesía de decir persona.

A ver si queda claro, el Scrum Master no despide personas ya que no es una de las funciones del rol, ni tampoco le hace frente al equipo, ni realiza evaluaciones de desempeño.
El Srum Master es un facilitador que aporta su conocimiento y experiencia en metodología SCRUM, para que el equipo aplique correctamente los principios ágiles en virtud del proyecto al que ha sido asignado.
Los principios ágiles en este caso son: armar y estimar el product backlog, respetar las iteraciones, realizar las reuniones diarias, realizar el sprint planning, realizar las reuniones de retrospectiva, finalizar la iteración con un producto potencialmente productivo, para enseñárselo al Product Owner y obtener el feedback necesario para avanzar por el camino correcto.
El Scrum Master facilitará las reuniones mencionadas y además podrá llevar las métricas de velocidad, diseñar el taskboard, mantener actualizado el burndown chart, entre otras actividades.

Listo. Es eso !! Y no es tarea para nada fácil !!
Pero no despedimos personas ni evaluamos el desempeño de las mismas.

Ya te conté sobre las consecuencias de la evaluación de desempeño en esta entrada  La evaluación de desempeño

Espero haber aclarado el tema, y si aún no quedó claro, preguntale a tu jefe.

Enfermedad mortal... ADSGC (Agilidad Dirigida por el Sistema de Gestión de Calidad)

Hace bastante comencé una serie de artículos bajo el título Enfermedad Mortal..., donde te cuento distintas prácticas erróneas en la gestión ágil de proyectos.
En este caso te traigo una práctica que es bastante común, y que indica que se ha perdido el rumbo ágil vaya uno a saber en que momento.

Se me ocurrió llamarlo ADSGC por Agilidad Dirigida por el Sistema de Gestión de Calidad, en donde lo único de agilidad que encontrarás en esta práctica, es lamentablemente, la A de las siglas.

Simplemente significa que la empresa posee o padece, un Sistema de Gestión de Calidad (SGC) y que intenta por todos los medios utilizar prácticas ágiles, muriendo en el intento.
(Queda fuera del alcance de este artículo, evaluar los beneficios de los SGC, si es que los tiene).

El primer síntoma de esta enfermedad, es la excesiva documentación que hay que generar, para que los auditores externos no engrosen su lista de no conformidades al momento de la auditoría, y tener la seguridad de que se pasará la misma exitosamente.

Le sigue de cerca, el concepto, y a veces la imposición, de que la retrospectiva es la reunión en donde se debe encontrar una cantidad mínima de oportunidades de mejora, para retro alimentar el SGC y dejar en evidencia la gran utilidad que tiene el mismo.

¿Te parece que has escrito poca documentación aún, eh? Tranquilo que siempre se puede escribir mas.
Hagamos entonces un reporte de las horas consumidas por los recursos, durante el proyecto.
Si, de los recursos !!!

Y para finalizar te dejo un ejemplo real de oportunidad de mejora cargada en un SGC:

"Falta instructivo para nuevos recursos donde se explique cómo utilizar las herramientas de Microsoft (pon acá la lista de herramientas que quieras)"

¿Muy útil no?

Existen mas enfermedades mortales, pero nos ocuparemos de ellas en los próximos artículos.

Mob Programming

Infinidad de veces nos ha tocado trabajar hasta largas horas, simplemente por haber desarrollado la aplicación o módulo tan necesario para el futuro de la empresa, y de hecho poseer el único Know How sobre las funcionalidades o técnicas de desarrollo aplicadas sobre ese producto milagroso.

Las metodologías ágiles emparejan el conocimiento de los integrantes del equipo, por medio de la tan conocida técnica de XP, que implementada en los equipos ágiles, dá muy buenos resultados a la hora de compartir el conocimiento y evitar héroes en los equipos.

Un interesante concepto llamado Mob Programnimg va mas allá de todo esto.

La técnica se basa en el concepto de que hay una sola máquina para todo el equipo y es uno de los integrantes el que la utiliza para desarrollar.

El resto del equipo observa por el proyector y puede colaborar con el que está codificando, aportando alguna idea.

Cada 15 minutos rotan y pasa a tomar el control otro de los integrantes, hasta que todos han utilizado su tiempo y se vuelve a comenzar el ciclo.

Si bien parece que no es para aplicar durante todo el proyecto, podría implementarse en las primeras etapas del desarrollo, donde se define la arquitectura y los lineamientos técnicos mas importantes del sistema.

De esta manera no solo se extenderá el conocimiento de la solución que se está desarrollando, sino que le permitirá a otros aprender en general sobre el diseño de software, patrones de diseño, bases de datos, algoritmos, refactorización, etc.

¿Que opinas?

¿Sería útil en la empresa donde trabajas?

Acá te dejo el enlace al sitio oficial  http://mobprogramming.org/