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/

Enfermedad Mortal... La Hora Hombre

Hoy en día, donde se habla bastante sobre los beneficios del Management 3.0, la agilidad, peopleware, desarrollo de personas, los procesos y la mejora continua, seguimos encontrando empresas que trabajan como en la época industrial.

Muchas se autodefinen como ágiles, pero lamentablemente no han podido salir del Management 1.0, a lo sumo se encuentran en un Management 2.0,  combinando prácticas de gestión tradicional con algo de agilidad.

Desarrollos en cascada que comienzan por los requerimientos, pasan seguidamente a los casos de uso (incompletos e inservibles en casi todos los casos), luego al desarrollo, posteriormente al testing y si aún estamos vivos y no cambiaron los requerimientos, a la etapa de implementación, se acomodan en iteraciones y ..... listo .... ya somos ágiles.

Sigue siendo muy común por ejemplo, encontrar que la unidad de medida para estimar el trabajo que se llevará a cabo, es la hora hombre.

Trabajamos 8 horas diarias, que multiplicadas por 5 días nos dan unas relucientes 40 horas semanales. ¿Ya cargaste tus horas en el sistema de producción?

Luego multiplicamos por la cantidad de personas que conforman el equipo (sí, dije personas) y nos da la cantidad de horas para dedicar por semana al proyecto.

Eso sí, no almuerces ni tomes un café porque lo vas a lamentar. 

Pero, ¿necesitamos saber el total de horas?

¿Me sirve de algo?

¿No será mejor conocer cuanto trabajo somos capaces de hacer en un tiempo determinado?

Ahhh ¿Suena mejor no?

Claro que sí.

La hora hombre no es un buen parámetro para dimensionar la cantidad de trabajo a realizar, ya que cada persona realizará las tareas a ritmos distintos. (¿Dije otra vez persona?).

Ed Catmull, cofundador y presidente de Pixar Animation Studios, comenta en su reciente libro Creatividad S.A. que para calcular cuando va a estar listo un largometraje, utilizan como unidad de medida la cantidad de trabajo que realiza una persona en una semana (Ed dijo persona en su libro, no fuí yo).

Por tal motivo en SCRUM utilizamos estimaciones relativas. Para obtener el total de puntos de historia de nuestra pila de producto (Product Backlog).

¿Y que hacemos con eso?

Conociendo cuantos puntos hace un equipo por iteración (velocidad de equipo) podemos determinar una fecha tentativa de entrega.

Finalmente podemos ponernos de acuerdo con el cliente, y en base a sus prioridades, ordenar el Product Backlog y armar un cronograma muy básico que visualice lo que podríamos ir entregando a lo largo de las iteraciones.

Conclusión

Los directivos de las empresas deberán hacer grandes esfuerzos para mejorar la gestión de los proyectos y no quedar atrapados en un paradigma dominante que no les permitirá abrirse al cambio.

La microgestión, gestión por el miedo, gestión del tipo "dirigir y controlar", ausencia de liderazgo y estructuras verticales en las que se organizan la mayoría de las empresas, son el principal camino hacia la mala gestión.

Implementa nuevas metodologías. Los clientes, la empresa y nuestros equipos te lo agradecerán.

La importancia del Taskboard fìsico

Uno de los elementos mas importantes para visualizar nuestro proceso, es el tablero de Scrum o Taskboard. En él se refleja el estado de la iteración en curso.

Lamentablemente no todos ven la importancia de tener el Taskboard visible en la oficina y hoy en día es reemplazado por alguna de las tantas herramientas informáticas que ofrece el mercado.
He escuchado mas de una vez que nuestros Taskboards físicos están pasados de moda.

Oído en una empresa:   "Parece muy viejo eso".

Oído en otra:   "Hay que utilizar herramientas informáticas".

Dejo unas fotos de la planta de Toyota,
Si no te parece familiar, te cuento que fueron los primeros en visualizar sus procesos en sus fábricas utilizando el método KANBAN (tarjeta en japonés).

Las siguientes fotos fueron tomadas en el año 2011, en el sector de servicio técnico y retiro de unidades, en la Ciudad Autònoma de Bs As, Argentina.

¿Que te parece?

Enfermedad Mortal... La evaluación de desempeño.

Ya hemos leído bastante acerca de los roles en SCRUM. Hay mucho escrito al respecto, y en resumen sabemos que la metodología propone tres roles: Product Owner, como representante del cliente; el Equipo, quien se encargará de desarrollar el producto que el cliente espera y, el Scrum Master, quien será el facilitador del equipo y velará (entre otras cosas) para que se sigan las buenas prácticas que propone la metodología.

Uno de los aspectos mas importantes para que el Equipo funcione como tal, es la motivación.

Acá quiero detenerme para comentar algo que los japoneses ya tienen bien claro desde el año 1950 y que fue uno de los principios que el Dr Edwards Deming les enseñó. 

La evaluación de desempeño, evaluación del comportamiento, calificación por méritos o calificación anual, destruyen el trabajo en equipo.

¿Pero porqué el Dr Deming afirmaba tal cosa?

Deming denominó a esta práctica muy común de las empresas occidentales: Enfermedad Mortal, y su efecto es devastador.

Según el Dr Deming:

Alimenta el comportamiento a corto plazo, aniquila la planificación a largo plazo, desarrolla el miedo, derriba el trabajo en equipo y alimenta las rivalidades.

Deja a las personas amargadas, desechas, heridas, apaleadas, desoladas, descorazonadas, incapaces de trabajar durante varias semanas después de recibir su calificación. No es justo, ya que adscribe a las personas de un grupo unas diferencias que pueden estar totalmente causadas por el sistema dentro del que trabajan.

La idea de una calificación por méritos es seductora. El sonido de las palabras cautiva la imaginación: se paga por lo que se obtiene; se obtiene lo que se paga; se motiva a la gente a que lo haga lo mejor posible, por su propio bien, para salvaguardar su propia vida. Quien pierde es la organización.

Conclusión

Las metodologías ágiles brindan formas eficaces de gestionar los proyectos de desarrollo de software, organizar el trabajo y desarrollar los equipos de trabajo para que éstos sean mas eficientes y productivos. 

Sin duda, esto debe estar acompañado de un compromiso por parte de las empresas, para que las personas se sientan orgullosas de su trabajo.

La dirección de las empresas debería reflexionar acerca de las teorías del Dr Edwards Deming y brindar apoyo a las personas, ya sea reemplazando supervisión por liderazgo, estimular la educación y la automejora de todo el mundo y sobre todo, evaluar el trabajo de los equipos y no de las personas de forma individual. 

Referencias:

Edwards Deming "Calidad, Productividad y Competitividad, La salida de la Crisis".

Herramientas Ágiles II

Tanto si has formado parte de un equipo ágil, o si has facilitando algún proyecto de manera ágil, o si ya lo estas haciendo actualmente, sabrás que el equipo debe reunirse al final de cada iteración para proponer mejoras o cambios a implementar en la siguiente iteración o Sprint. Si. Lo antes posible. Porque queremos hacer mejor las cosas; la mejora continua o filosofía Kaizen de la que ya escuchaste hablar miles de veces. El objetivo es hacer lo que ya estamos haciendo, pero hacerlo mejor.

En scrum esta reunión se llama reunión de retrospectiva y existen varias técnicas ya probadas para lograr reuniones eficientes.

La genial herramienta creada por Corinna Baldauf  nos facilitará la elección de la técnica a utilizar.

Retromat te permitirá seleccionar de manera aleatoria una técnica, buscar una técnica por ID o buscar por palabra clave.

Considero que es excelente ya que te permitirá variar las técnicas y aprender en cada una de ellas.

La técnica de Las Galletas se vé muy divertida.

Mi favorita es La Estrella de Mar.

Te dejo el link para que la investigues: http://plans-for-retrospectives.com/index_es.html?id=27

Retromat fué traducida al español por la comunidad ágil de Latinoamérica.