domingo, agosto 25, 2013

Scrum: Cediendo el mando y control AL EQUIPO

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 en www.scrum.org, 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) 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 de 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 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 si 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:
  1. 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.
  1. 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 amigos "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.
  1. 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:


8 comentarios:

  1. Muy buen post!
    mi tema preferido :) :) :)

    Solo me gustaría sumar un comentario, en realidad dos :)
    y ambos tienen que ver con un enfoque sistémico
    1-Un sistema complejo,no tiene un solo líder, hay tantos líderes como nodos tenga esa red, se decir como integrantes tenga el equipo, porque cada uno tiene algo valioso para aportar. Y al trabajar desde este enfoque vamos a entender eso de que "la función del liderazgo es producir más líderes, NO más seguidores", en otras palabras dar lugar a que emerjan esos comportamientos que lideran el cambio. Entonces creo que la principal función de un Scrum Master o Gerente de Proyecto (o como quieran llamarse) es crear esas condiciones para que emerjan líderes. Y esto va de la mano de otra idea muy aplicable a todos los contextos, y que la vi muy resumida en este post:
    http://metacool.com/the-heart-of-leadership/
    y que tiene que ver con el "liderazgo servicial" del cual siempre se habla, que es actuar para hacer la diferencia, que es hacer ese cambio positivo, que sin tu acción no hubiese ocurrido. Lo cual implica inteligencia para dar cuenta "cuando" debes actuar, y tambien humildad, para darte cuenta cuando NO debes actuar, porque hay otros líderes que ya estan haciendo el cambio.

    2-La confianza es un elemento central en todo este proceso de cambio. Porque lo cierto es que en esta forma de trabajo, la gestión "tradicional" (por llamarle de alguna forma)y quienes trabajan de esa forma se ven desafiados por 3 cambios radicales que necesitan hacer: a)"liberar" mas que controlar (como bien vos lo explicas), b)dejar de lado el "comando y control" para dar lugar a que emerjan equipos autogestionados (como tambien lo explicas) y c) dejar de lado el recelo y la desconfianza, para empezar a confiar no solo en el potencial de los individuos sino en el poder de cambio de los equipos autogestionados.

    y aunque dije 2 puntos que queria agregar, ahora se me viene a la mente un tercer punto :)

    3-Scrum es mucho mas que una forma de trabajo que te permite aumentar tu productividad al entregar en el menor tiempo posible el mayor valor para un cliente. Scrum tiene otras 2 facetas sumamente vitales en los ambientes de trabajo de hoy en dia: a) es un framework para promover e incentivar la innovación y b) es un enfoque que te permite entender y trabajar con la complejidad,¿y a donde voy con todo esto? Es que son los equipos autogestionados los que te permiten trabajar en ambientes complejos, cuya colaboración incentiva la innovación, todo lo cual redunda en mayor productividad.

    Perdon por la extensión del comentario :)
    y gracias por incentivar nuestras reflexiones!

    Vero.

    ResponderBorrar
  2. Wow, tan valioso el post como el comentario.
    Creo que el tema es uno de los más complejos en nuestra cultura... venimos acostumbrados a que alguien más tome las decisiones y muchas veces ni sabemos que tenemos el potencial para que eso cambie. "Estamos acostumbrados al látigo" El reto es seguir los pilares ágiles de transparencia y coraje para fomentar que los gerentes de proyecto se transformen en líderes serviciales, en lograr que entiendan que un equipo feliz es más productivo y comprometido. Un punto clave para los que están cambiando a una aproximación ágil es ver lo que pasa en la reunión diaria: ¿gira en torno al "scrum master"?¿de alguna manera le rinden cuentas?¿Qué tono de voz utiliza cuando habla (algo como regañando)?

    Saludos

    Leo

    ResponderBorrar
  3. Gracias Vero y Leo sobre sus comentarios.. tenemos mucho que aprender de esto.. es un cambio grande para todos nosotros...

    que nos ha costado, pero que si nos ayudamos entre todos llegaremos mas rápido...

    Toca leer y debatir mas sobre sistemas adaptativos complejos y organizaciones 3.0...

    espero pronto profundizar más en esto..

    una brazo a ambos..

    ResponderBorrar
  4. Muy buen artículo.

    Realmente es un reto, sobretodo para el (nuevo) scrum master en su tarea de aprender a "ceder" sin caer en la tentación de señalar con el dedo y dictaminar quién
    hará qué cosa y cómo la realizará. En ocasiones le da la sensación de que sino selecciona quién hará determinada tarea entonces quizá otro desarrollador no muy experimentado pudiera tomar una tarea que pudiese luego generar retraso en la entrega (siempre ve riesgos).
    También piensa que sino le explica al desarrollador cómo hacer su tarea, entonces no se reutilice determinado componente que ya existe y se repita el código, por decir un ejemplo básico.
    Sin embargo, esta faceta se aprende, se adquiere :-). Creo que si nos cuesta mucho delegar, no nos debemos preocupar ya que poco a poco iremos cediendo y confiando en el equipo, la confianza es
    fundamental!!!
    Muy bueno el tip de Leo, eso de mirar el daily y los tonos de voz, jajajaj, estoy totalmente de acuerdo que eso dice muchísimo

    ResponderBorrar
  5. Jorge, dirigir o no dirigir, ¡esa es la cuestión!
    Excelente tu planteamiento sobre transformación. Precisamente, la pregunta es ¿cómo lograr esa metamorfosis? Bien dices que el “rol de la gerencia de proyectos queda inoperante y se convierte en un reto profesional pasar de gerente de proyectos a Scrum Master”. ¿Cómo hacer que ese cambio no se quede en un mero “regateo”, que no se quede en una evolución trunca o, dicho de otra forma, en una mera mutación involutiva? No queremos que el resultado sea algo así como “gerenscrummaster de proyectos”…algo como lo que sucede en La Mosca, aquella película de 1986, dirigida por David Cronenberg, con Jeff Golblum y Geena Davis.
    Está claro que el gerente de proyectos de hoy puede ser un Scrum Master, pero lo que conlleva ir de un punto a otro no es algo lineal. Es precisamente el punto que abordo en mi próximo artículo, en el cual me daré la libertad de citar al tuyo, muy a lugar por cierto.
    Lo que sí creo que debemos dejar claro desde ya es que si bien no hay un rol de gerencia de proyectos en Scrum (y en muchos otros métodos ágiles), es erróneo pensar, como lo hacen muchos, que en un proyecto conducido con Scrum no se hace gerencia del proyecto. De hecho, este es un factor de resistencia al cambio, a esa transformación que necesitamos. Como lo dices en tu post, buena parte, sino todas las responsabilidades del gerente, se distribuyen en estos nuevos roles que hoy estamos jugando en Scrum. Creo que en eso tú, los foristas que me han precedido y yo, estamos de acuerdo.
    Otro punto a tener en cuenta y que tocas en el apartado de Desventajas, es el de la autoorganización. Pero este asunto, estimado, será algo que abordaremos en profundidad más adelante.
    Salud@s,
    Lucho

    ResponderBorrar
  6. Lucho y Andre...

    Excelentes sus comentarios y estas reflexiones, nos ayudan a comprender este nuevo paradigma que se basa en Manifiesto, valores y principios donde nos basamos en la transparencia y profesionalismo, y si tenemos las personas competentes para hacer su trabajo ¿por qué desconfiar? ...

    esperare Lucho tu post... y referenciame con tranquilidad, al igual yo lo haré .. y Andre, en este esquema el equipo toma vida y logra ir más allá de los límites impuestos por la gerencia tradicional.


    saludos y seguimos en contacto.

    ResponderBorrar
  7. Excelente post como siempre Jorge, grandes contribuciones de todos ... Acá va la mía:
    Un factor a tener en cuenta en este mundo globalizado son las distintas culturas e idiosincrasias de cada país o región.
    He tenido la suerte de colaborar como SM con equipos de EEUU, Europa, India, Uruguay, Argentina y Perú.
    Mis conclusiones son las siguientes:
    1) En EEUU y Europa están acostumbrados a estructuras de gestión y comunicación horizontales donde toda opinión cuenta. Estos equipos de Scrum han demostrado llegar a la auto-gestión en forma natural y rápida.
    El trabajo del SM radica en fomentar la colaboración, solidaridad y trabajo en equipo ya que son personas más independientes que muchas veces prefieren trabajar solas.

    2) En Uruguay y Argentina los equipos se resisten a la autoridad por lo que Scrum ha caido muy bien.
    En una charla con mi trainer Alan Cyment en Montevideo, me describió Scrum como un modelo "Pseudo-Socialista" en el que el poder y hasta las utilidades, idealmente deberían ser repartidos dentro del equipo de Scrum.
    A diferencia de 1er grupo, son más desorganizados y conflictivos por lo que el SM debe trabajar en mantener un espíritu de organización y armonía en el equipo.
    3) En Perú e India el liderazgo es más vertical y los equipos están acostumbrados a recibir órdenes.
    Para lograr equipos auto-gestionados el SM los debe coachear, darles confianza y cambiarles el paradigma tradicional. Es un proceso más largo que requiere mucho mayor involucramiento e "imaginación" por por parte del SM.

    Esta es mi experiencia y obviamente no se puede generalizar.

    En conclusión el SM debe armar una estrategia de colaboración teniendo en cuenta las costumbres de los equipos dictadas por su marco cultural y social.

    Saludos cordiales,
    Agustin

    ResponderBorrar
    Respuestas
    1. Gracias Agustin por tu feedback, nos ayudas a todos a entender este mundo complejo.. un abrazo

      Borrar