Scrum: Cediendo el mando y control al equipo

Un proceso que toma esfuerzos

2 October 2013



Hace aproximadamente un año comenzamos a migrarnos a una forma de trabajo completamente diferente, llamada “Scrum,” ha sido un proceso lleno de ganancias, retrospectivas, mejoras y aprendizajes. Este framework ha implicado cambio un radical en nuestra forma habitual construir software y de relacionarnos como personas y trabajadores del conocimiento [2].

Son muchos los aspectos que cambian, y que pueden ser consultados en la guía de scrum, pero este post se centra en el principal aspecto en el que se centra el agilismo: "las personas" (El manifiesto ágil comienza con: "Personas e interacciones sobre procesos y herramientas," ver más en http://agilemanifesto.org/iso/es/), y dentro de esas personas el El Team Developer.

Dentro de Scrum tenemos varios roles interviniendo en la construcción del producto:
  • Los stakeholders: cuyas expectativas y necesidades son priorizadas por el Product Owner
  • El Product Owner : Encargado de lograr y transmitir la visión al equipo, decidir que se construye del producto, y del ROI del mismo
  • El Scrum Master: Encargado del proceso de scrum, remover impedimentos y realizar coach al equipo
  • Y El Team Developer (equipo de desarrollo): Encargado de autoorganizarse y construir el producto
En este camino de Scrum, el cual por no ser prescriptivo, pone un límite y deja definiciones abiertas donde uno se mueve con libertad, he observado que uno de los aspectos más complejos de comprender y asimilar es el equipos auto-organizados. Digo complejo, pues estamos acostumbrados a un esquema  Mando y Control (en inglés Command & Control[1]) donde el Gerente de Proyecto es quien comanda la misión y el éxito o fracaso de ella dependerá de los lineamientos que él dé, decidiendo:
  • qué hacer
  • cómo hacerlo
  • quién debe hacerlo
  • cuándo hacerlo
El éxito también dependerá del equipo, las herramientas, los stakeholders, etc., pero en el ambiente de gerencia de proyectos y organizacional, es Vox Populi que un buen gerente es factor determinante y principal para el éxito del mismo.

Ahora si pensamos en el nuevo esquema, en el que las responsabilidades de la gerencia de proyectos es fraccionada:
  • El camino a seguir es dado por el Product Owner, definiendo el qué y el cuándo.
  • El scrum master es un líder servicial que busca que se cumpla el proceso definido y se encarga de que el equipo sea cada vez mejor y tenga todas las herramientas e insumos para completar el trabajo comprometido removiendo los impedimentos
  • El equipo decide libremente (de lo ítemes de backlog priorizados para el sprint) con qué se compromete y cómo va realizarlo.
Bajo este esquema, queda el rol de la gerencia de proyectos inoperante y convirtiéndose en un reto profesional el hecho de pasar de Gerente de Proyectos (líder, amo y señor de la visión, del equipo, de la táctica y la estrategia) a Scrum Master (líder al servicio del equipo).

Y es por esto este post se centra en ceder el control, y el Gerente de Proyecto cede toda esa supremacía tan anhelada por algunos, a un ente con mayor poder: "al equipo", pues este siendo un sistema complejo encuentra mejor la forma de autoregularse y controlarse de forma que va encontrando mejores caminos y formas para crecer como equipo y hacer crecer el producto.

Y hasta acá suena todo muy poético, pero es un proceso que toma esfuerzos tanto desde el punto de vista del gerente de proyecto que se transforma en Scrum Master (si así lo desea) como desde el equipo que antes eran personas que recibían órdenes y directrices a ser responsables del cómo y quién debe hacerlo, pasando de un "organismo subyugado" a un "organismo consciente de sí mismo, estableciendo y encontrando sus propias reglas, en crecimiento, evolución y mejora" generando equipos para organizaciones 3.0.

A continuación enumeraré aspectos claves en esta transformación:

Ventajas
  • El compromiso con lo que se va adquirir durante el sprint lo adquiere el equipo y no otros externos a él.
    • En el planning el equipo escucha lo que se desea construir, realiza la estimación, decide hasta donde es capaz de llegar y define la forma de construir.
  • Durante la construcción el equipo decide qué construir, cómo construirlo y quien debe hacerlo. En ocasiones Scrum Master orienta al equipo para que estén siempre construyendo lo que tiene mayor prioridad y mayor riesgo, evitando desenfoque del equipo.
  • Durante la ejecución del sprint el equipo tiene las herramientas (el tablero kanban, los burndown charts) que le permiten saber si lograrán o no el compromiso.
  • En la reunión de review, el equipo realiza la entrega del producto construido al Product Owner y a los Interesados, recibiendo directamente la retroalimentación por el trabajo realizado.
  • Igualmente, durante el review se reciben los honores por lograr el trabajo comprometido en el planning, o se pasa la pena de no lograrlo. (antes estos honores y penas eran del gerente de proyecto -- y por la forma tradicional de construir software, por lo general eran penas). La review también tiene el poder de realizar la motivación sobre el equipo, pues los aplausos le dará la razón en su forma de alcanzar la victoria y los fracasos le darán los elementos para mejorar en el próximo sprint (generalmente de 2 semanas) y lograr la victoria perdida en el vigente.
  • En la retrospectiva guiados por el scrum master, el equipo encuentra como mejorar en Productividad, Calidad y Felicidad; identificando mejoras en su proceso de construcción, y en su forma de relacionarse como equipo, con el Scrum Master y el Product Owner.

Desventajas y riesgos
  • Equipos que no se quieran comprometer y que elijan trabajar muy por debajo de su capacidad.
  • Equipos que no estén dispuestos a aprender y a poner en prácticas las retrospectivas.
  • Miembros de equipo que no se comprometan, pues a pesar de que estuvieron en el planning y junto con sus compañeros delimitaron el producto a construir durante la ejecución del sprint dejan a sus compañeros "solos / tirados" no realizando tareas con el profesionalismo requerido, es decir, inyectando bugs, trabajando a mucho menos capacidad de lo normal, etc.
  • Mala comprensión de la autoorganización y autogestión, creyendo que esta característica no implica deberes, ni responsabilidades.
  • Scrum Master aun con chip de gerente de proyectos, interesado en controlar al equipo y decirle exactamente qué, quién, cómo y cuándo hacer las tareas.
  • Creer que esto ocurrirá por arte de magia con solo decir las palabras mágicas: Scrum : equipos auto-organizados, falso, se requiere de mucho acompañamiento, coach y de personas receptivas y decididas a entender las reglas y compromisos que esto implica.

Beneficios
  • Un compromiso alto sobre lo que se va a construir . . .
  • Responsabilidad asignada a quien tiene el poder de lograr el resultado.
  • Un sistema complejo (el equipo) es dominado por reglas impuestas por ellos mismos y no bajo la autoridad y liderazgo del gerente de proyecto.
  • El equipo no requiere de reuniones de seguimiento, pues el equipo con sus gráficas y radiadores de información saben en qué punto están y si van a lograr los objetivos.
  • Como resultado de lo anterior, el equipo se "presiona" a si mismo (de forma natural) para lograr las metas trazadas conjuntamente.
  • EL ÉXITO DE LO QUE SE VA A CONSTRUIR DURANTE EL SPRINT NO ES RESPONSABILIDAD DEL SCRUM MASTER (antes gerente de proyecto - e insisto, si es que quiso cambiar de rol -) SINO QUE ES ENTREGADA AL EQUIPO.

Referencias

[1] Field Manual 6-0, Mission Command: Command and Control of Army Forces. Headquarters United States Army, Department of the Army, Washington, DC, 2003.

[2] Cyment, Alan. El espíritu de Scrum,  El arte de amar los lunes. V0.2 http://es.scribd.com/doc/84799747/El-espiritu-de-Scrum


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Jorge Hernán Abad Londoño, CSM, 10/2/2013 7:51:55 AM
El original se encuentra en : http://lecciones-aprendidas.blogspot.com/2013/08/scrum-cediendo-el-mando-y-control-al.html

You must Login or Signup to comment.