Quiero un Scrum Master Especializado

Muchas veces da la sensación de que el rol del Scrum Master se está convirtiendo en una figura algo devaluada y fácilmente sustituible dentro de los equipos de Scrum.

Parece que el trabajo que realiza un Scrum Master es tan trivial que cualquiera puede desempeñarlo con sólo unas meras pinceladas de la metodología. He oído hablar incluso de equipos que se turnan el rol de Scrum Master de un sprint a otro (personalmente me parece anti-scrum).

No soy Scrum Master y nunca he desempeñado dicho rol.

Sólo soy un miembro más del equipo de desarrolladores, y aun así quiero revindicar la figura del Scrum Master. Trasmitir la importancia de que para vivir un buen Scrum es vital la existencia de un buen Scrum Master, con las habilidades adecuadas, y a ser posible formado y experimentado.

Es cierto que los equipos de Scrum son auto-organizados.

Aun así la figura del Scrum Master es fundamental. El trabajo que debe realizar al margen de los sprints requiere gran dedicación y esfuerzo.

A veces se simplifican las funciones reales de un Scrum Master, reduciéndolas a una mera organización y moderación de reuniones.

¿Es el Scrum Master un simple Moderador de Reuniones?

Responsabilidades y Tareas del Scrum Master

Nos centramos tanto en los roles, sprints, backlogs, burndown chart, time boxing, meetings, etc. que al final acabamos obviando las importantísimas actividades que debe realizar el Scrum Master.

El Scrum Master tiene un papel fundamental en la dinámica de un equipo Scrum aunque sus actividades no se reflejen como tareas del Sprint Backlog.

No todos estamos capacitados para desempeñar dicho rol. Por eso se quieren equipos multidisciplinares. No somos expertos en todo, nos especializamos.

Cada miembro del equipo está especializado en programación/desarrollo, experiencia de usuario, calidad, etc. El Scrum Master también debe especializarse. Su actividad debe ser realizada por gente con las aptitudes, habilidades y conocimientos adecuados.

El Scrum Master es el responsable de organizar junto con el Product Owner un buen Product Backlog.

Es el responsable de que al llegar al Estimation Meeting (o Sprint Planning Parte I), las User Stories estén priorizadas y con tamaño de Sprint.

Durante los sprints el Scrum Master sigue trabajando con el Product Owner en el crecimiento y mantenimiento del Product Backlog.

Estas tareas las realiza de forma paralela al Sprint y no suelen reflejarse en el Sprint Backlog.

Quizás la problemática sea precisamente que el Scrum Master está realizando unas tareas que no se suelen introducir en el Sprint Backlog. Pasan muy desapercibidas. Llega un momento que parece que sólo existe el trabajo que aparece en el Sprint Backlog.

Entre algunas responsabilidades del un Scrum Master figuran:

  • Actuar de enlace entre Team y Product Owner.
  • Trabajar con el Product Owner en la creación de un buen Product Backlog.
  • Mantener vacío el Impediment Backlog (que en todas las Daily Meetings intentamos volver a poblar).

 

La Piedra Angular de Scrum

La tarea de creación y mantenimiento del Product Backlog realmente es la piedra angular de la Metodología Scrum.

La Estimation Meeting es la reunión más importante de Scrum y a la vez es la reunión mas maltratada y descuidada.

Muchos equipos la consideran innecesaria, eliminándola de su Scrum. Sí, ya se que Scrum es flexible y se puede moldear (es maravilloso disponer de una metodología tan flexible que incluso puedo trasformar todas sus reglas). Pero eliminar esta actividad destroza casi por completo esta metodología Agile.

 

La Importancia del Estimation Meeting

Actividades imprescindibles del Estimation Meeting:

  • El Product Owner y el Scrum Master explican cada User Story.
  • Tras cada explicación el equipo asigna User Story Points.
  • Selección de las User Stories del Sprint en función de los Puntos de Historia.

Se trata de la única reunión de planificación donde la presencia del Product Owner es inexcusable (en cuanto empieza la división en tareas su presencia es opcional).

Es muy importante que el equipo tenga claras todas las User Stories, y para esto no vale con preguntar que si alguien tiene dudas.

Las dudas se resuelven asignando Puntos de Historia.

Si cuando todo el equipo valora en 8 puntos otro valora en 100 está claro que algo no se ha entendido correctamente.

Se suelen asignar cuatro horas a esta reunión, pero el objetivo debería ser acabar en el mínimo tiempo posible. Su duración es un indicador de lo bien trabajado que está el Product Backlog.

 

Situación ideal al llegar a un Estimation Meeting

Para poder desarrollar de forma eficiente y fluida dicha reunión es muy importante una buena preparación del Product Backlog:

  • El Product Backlog debe estar compuesto por User Stories con tamaño de un Sprint (por supuesto las épicas no deben existir).
  • Si una User Story es prioritaria y no cabe en el Sprint es un indicador de que debía de haberse descompuesto en varias User Stories.
  • El tamaño de una User Story se identifica fácilmente con los User Story Points. Si supera la capacidad del Sprint se debe descomponer.
  • Si se localiza alguna User Story demasiado grande es conveniente aplazarla al siguiente Sprint para trabajar su descomposición fuera del Estimation Meeting.

 

El Trabajo del Scrum Master

Para desarrollar estas actividades es requisito imprescindible llegar al Estimation Meeting con un Product Backlog bien elaborado y trabajado.

Es el trabajo más importante del Scrum Mater. Y no consiste en una simple moderación de reuniones.

La preparación de un buen Product Backlog implica un trabajo paralelo al Sprint. El Scrum Master trabaja con el Product Owner para crear y mantener el Product Backlog. Para descomponer las historias grandes que se evidenciaron en el anterior Estimation Meeting en historias más granulares. Para permitir un Estimation Meeting fluido y un entendimiento rápido de todas las historias.

Lo ideal sería que incluso las User Stories se describieran mediante scenarios de los aceptance tests (ayudados por expertos de calidad), para plantearse un Product Backlog basado en Acceptance Test Driven Development (ATDD).

Anuncios

7 thoughts on “Quiero un Scrum Master Especializado

  1. Gracias por tu apoyo a los SM.

    Además de lo que cuentas, para mi hay otra tarea fundamental del SM, más asociada al plano humano, y es la de cuidar el equipo. Por asi decirlo, si el Product Owner vela por el producto, entonces el SM vela por el equipo:

    -Defiende el trabajo del equipo frente al PO. Evita que se añadan tareas en mitad de un sprint.

    -Se preocupa por conocer la velocidad real del equipo, para saber con certeza cual es el trabajo que se puede sacar adelante en un sprint. Esto se traduce en mejores planificaciones, y por tanto, pocas o ninguna hora extra.

    -Democratiza el equipo para que se escuche y respete la opinión de todos, de modo que todos se sientan participes y motivados. Reconoce el esfuerzo y el trabajo bien hecho (porque lo ve), y lo transmite hacia arriba (porque allí no lo ven).

    -Resuelve los impedimentos y ayuda a la gente atascada, bien directamente si tiene los conocimientos técnicos, o bien indirectamente promoviendo el trabajo en parejas.

    -Promueve las buenas prácticas para mejorar la calidad y la adaptabilidad al cambio.

    No se si la teoria de Scrum habla de esto, pero después de trabajar 3 años con Scrum esto es lo que me gustaría que hiciera mi SM. Todos los que trabajamos en el mundo del software deberíamos darnos cuenta de lo importante que es un buen SM, y luchar por defender este rol en estos términos. Ya que somos muchos los programadores aquí en España y, por tanto, poco valorados, al menos asegurémonos de disfrutar nuestro trabajo.

    • Gracias por tus comentarios, la verdad es que amplían y clarifican bastante la información del artículo.

      Yo entendía la lista de tareas del SM (Scrum Master) que tu detallas como lo básico de un SM. Daba por supuesto que cualquiera que utilice Scrum entiende todas esas tareas como parte básica del SM. En los proyectos de mi empresa creo que al menos esas tareas del SM están muy aprendidas. En este artículo trato de hacer más hincapié en que además de todo eso, no tenemos que olvidar una parte que a veces se descuida, la creación y mantenimiento de un buen PB.

      Imaginemos la utopía de un equipo perfecto en el que todos usan buenas prácticas, nadie se atasca porque los impedimentos se resuelven solos, el equipo es muy comunicativo, la velocidad del sprint está controlada, el PO asume que no debe cambiar cosas en mitad del sprints y el equipo no necesita ser defendido.

      Aun así ¿sería necesario el SM?
      Yo creo que si, porque aun quedan tareas del SM que a veces parece que se descuidan, las que he detallado sobre mantener los requisitos del cliente en forma de PB. Requieren dedicación, esfuerzo, habilidad para hacer las preguntas apropiadas al PO, habilidad para reflejarlas en un buen PB, etc.

  2. Buen artículo!
    Mi crítica a los story points: cuando el equipo es reamente multidisciplinar, se puede dar fácilmente el caso de que entendamos perfectamente una user story pero no sepamos valorar qué esfuerzo técnico lleva hacerla. Ejemplo: puedo entender la user story “diseñar el botón de la aplicación con look&feel XX” pero si no tengo ni idea de diseño gráfico seguramente no sabré cuánto esfuerzo lleva. En equipos pequeños y con gente muy especializada, ¿de verdad interesa usar story points? Yo pienso que no aportan mucho. Para mí aporta más que se valore como “fácil”, “medio”, o “difícil” y se estime si se ve factible que entre o no en el sprint.

    • “Según expertos estadísticos el ser humano no es capaz de elegir con fiabilidad un estado en una escala de más de cinco valores.”

      Parece que la medida ideal sería una escala de tipo “muy fácil, fácil, normal, difícil y muy difícil”.

      En Scrum es clave asignar puntos de historia en una Estimating Meeting previo al Sprint Planning. Pero esto no quiere decir que sea vital usar el Planning Poker o la estimación basada en la Serie de Fibonacci. Existen muchas forma de asignar puntos (se dice que algunos usan tallas de camisa).

      El sistema a utilizar si que debería decidirlo el equipo según sus necesidades.

      Yo tampoco le veo mucho sentido a el valorar historias de las que no tengo ni idea, por corresponderse a un tipo de trabajo que no realizo. Si no tengo ni idea de dibujar ¿como voy a saber lo que cuesta dibujar los gráficos para una UI? ¿Qué aporta mi opinión en este tema?. Pero quizás si me atrevo a valorarlas, se descubran dudas que los que sí que saben no se habían planteado, nunca se sabe.

      Asignando puntos indirectamente se consigue lo realmente importante:

      • Se descubre si las historias se entienden bien (la típica pregunta de ¿hay alguna duda? no sirve para nada).
      • Nos da una idea subjetiva de la velocidad (por eso no estoy seguro si las escalas con pocos valores ayudan a esta estimación de velocidad).

      El sistema de puntos mientras que sea subjetivo, veloz, no implique semanas aplicando tecnicas complicadas de estimación, sirva para debatir y para valorar cuantas historias entran en cada Sprint; que cada equipo use el que quiera.

  3. Gracias por el artículo. ¿Y cuanto esfuerzo crees que require ser Scrum Master de un proyecto? ¿O dicho de otro modo, en cuantos proyectos o como de grandes debe de estar un Scrum Master?

    ¿Le ves algún problema a que un Scrum Master sea tb developer (por ej. al 50%?

    Por cierto, igual sería más fácil de leer si hubiese secciones dentro de estos posts tan largos, a mi me cuesta un poquillo.

    • Las ideas principales que quería trasmitir es “hay que dejar de considerar que el SM es tan solo un moderador”.

      No me había planteado tus preguntas. La verdad introducen un buen debate.

      Sería un ejercicio interesante determinar cuanto esfuerzo y dedicación requiere el trabajo de SM. Pero yo creo que todas estas preguntas se deberían valorar en cada caso concreto o tipo de proyecto.

      Se decida lo que se decida, creo que lo importante es que quién asuma rol de SM esté preparado para hacer ese rol y pueda hacerlo bien (de la misma forma que el programador en lenguaje X sabe muy bien programar en X).

      Lo de 50% SM y 50% developer, en mi opinión creo que también depende de cada caso concreto.

      Creo que nada impide que un buen SM también pueda ser un buen programador o al revés. Algunos rechazan esta dualidad durante los sprints, porque argumentan que el SM no debe influir en las decisiones técnicas. Pero yo creo que por esto precisamente se llaman roles. No veo ningún problema si el experto en SM también es un experto en lenguaje X por ejemplo.

    • >> “Por cierto, igual sería más fácil de leer si hubiese secciones dentro de estos posts tan largos, a mi me cuesta un poquillo.”

      Gracias por la recomendación, soy nuevo en esto de los blogs, acabo de empezar y tengo que acostumbrarme. Ya me han dicho que son exageradamente largos, estoy trabajando en esto 😉 , quiero evitar el enrollarme tanto, con el formato tampoco acierto, me falta rodaje.

      Gracias por el consejo.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s