lunes, 11 de marzo de 2013

Tres claves para comenzar a implantar prácticas ágiles con éxito

En este post destacaré lo que considero esencial para empezar con éxito una iniciativa de incorporación de prácticas ágiles en un equipo. Anticipo que mis opiniones se alejan del agilismo radicalizado, contrario a cualquier opción que no sea conseguir una implantación purista de alguna metodología ágil específica. Este post, limitado obviamente por mi humilde experiencia :-), ofrece una reflexión sincera de ese lado oscuro del agilismo :-), que incomoda un poco por no ser todo lo ideal que quisiéramos. Es cierto que dependiendo del contexto del equipo, la implantación podría tener menos o más obstáculos, sin embargo, en  mi opinión hay tres aspectos básicos que siempre deberían tenerse en cuenta para comenzar con buen pié. Durante la implantación no conseguiremos que el equipo desatienda su trabajo normal o que disminuya significativamente su capacidad de trabajo, con lo cual debemos ser muy cuidadosos en cuanto a evitar crear ruido que afecte el desempeño del equipo. A continuación describo tres claves para tener en cuenta al comenzar a implantar agilismo.

1. La implantación debe hacerse a nivel de equipo y de cada producto o servicio encargado al equipo

Esta clave la he desarrollado en detalle en mi anterior post Getting Started en agilismo: un enfoque centrado en el equipo.  En este post explicaré otros dos aspectos claves.

2. Contar con un líder de la implantación en cada equipo
En un contexto ideal tendríamos a todo el equipo motivado y comprometido en la implantación de prácticas ágiles, auto-convencidos de las ventajas que conseguirán y dispuestos a probar y ajustarse a nuevas formas de trabajo. Lamentablemente esta situación no es la más frecuente y no nos bastará con la actitud heroica de algunos miembros del equipo. Es importante que exista un líder reconocido de la iniciativa de implantación, me refiero a la figura de Scrum Master, el rol propuesto por Scrum, sin embargo, sabemos (o deberíamos saber) que un Scrum Master no se hace en un curso de 20 horas :-). Es decir, pretender que exista o surja de inmediato un Scrum Master desde dentro del equipo no es realista. El rol Scrum Master tiene dos ingredientes: conocimiento en agilismo (y experiencia) y liderazgo. Por eso, es más sensato y pragmático pensar que podemos conseguir un líder dentro del equipo y delegar el conocimiento a alguien externo al equipo (como veremos a continuación), especialmente al comienzo de la implantación del agilismo en el equipo. Pero ¿quién debería asumir este liderazgo?. Podría ser un jefe tradicional que esté dispuesto a iniciar una conversión hacia dicho rol de Scrum Master, contando con la posible ventaja de tener ya desarrolladas habilidades de liderazgo. Por otra parte, podría ser otro miembro (no jefe), que dejara sus actividades para dedicarse exclusivamente (o en gran medida) a liderar la implantación de prácticas ágiles. Lo importante es que quien desempeñe este rol sea efectivamente líder y que en lo posible no mezcle su labor de apoyo a la implantación de prácticas ágiles con los trabajos encargados al equipo. Lamentablemente, en mi experiencia, lo que usualmente he llegado a conseguir es que sea el mismo jefe, y sin abandonar su rol de jefe :-), quien actúe como líder de la implantación del agilismo. Eso es lo que hay :-), y si no es posible "revolucionar" este aspecto (al menos al iniciar la introducción del enfoque ágil) prefiero comenzar con esta situación no tan favorable en lugar de entenderlo como un obstáculo insalvable que no permita al equipo iniciar la implantación.

3. Disponer de un coach que apoye al líder y al equipo durante la implantación
Reconociendo la dificultad para que en un equipo dispongamos de una persona con conocimiento y experiencia en implantación de prácticas ágiles el coach complementará al líder y entre ambos soportarán la figura ideal de Scrum Master. De todas formas, el coach debería ser un apoyo transitorio, y en la medida que el líder de la implantación en el equipo adquiera conocimiento y experiencia, el coach se iría haciendo prescindible hasta extinguirse, momento en el cual realmente tendríamos en el líder la persona que desempeñaría de forma fiel el rol Scrum Master. Incluso dicho Scrum Master podría a llegar a tener menor dedicación o exclusividad a un equipo y poder realizar dicho rol para más equipos. El coach podría ser alguien de la organización, un Scrum Master ya formado, sino debería ser un consultor externo. En cualquier caso, el coach debe ser capaz de apoyar y orientar al líder tanto en la preparación de la implantación (diagnóstico, preparación de un roadmap, posible formación en prácticas ágiles para el equipo, selección de herramientas, etc.) como durante los primeros sprints de mejora ayudando a evaluar las prácticas implantadas y resolver desafíos que aparezcan. El coach debería ofrecer una alta disponibilidad para el líder y es recomendable que al comienzo también actúe presencialmente junto al líder en sus interacciones con el equipo.

Los roles de Scrum son los que me gustaría poder implementar en todo equipo, tienen una lógica incuestionable, sin embargo, en la práctica, especialmente para equipos ya formados y trabajando de forma más "tradicional", es muy difícil conseguir implantarlos de inmediato (ver Roles de Scrum Parte I y Parte II). Mi propuesta está más alineada con los planteamientos de Extreme Programming, donde se reconoce el rol Manager (un facilitador o líder, no un jefe tradicional) y el rol Coach.



Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com 

domingo, 10 de marzo de 2013

Getting Started en en enfoque ágil: un enfoque centrado en el equipo

Una de las claves para una implantación exitosa del agilismo es que éste debe cultivarse y desarrollarse a partir de los equipos. A continuación, explicaré en más detalle que implicaciones tiene este planteamiento.

Favorecer transformación ágil del equipo
No es sensato pretender que por imposición y a través de directivas originadas fuera de los equipos éstos vivan el agilismo. Haciéndolo así a lo más conseguirías "adoptar" prácticas ágiles pero no producirías una "transformación" ágil. La implantación del agilismo NO debe hacerse como históricamente se ha hecho con las metodologías implantadas a nivel corporativo, confiando que todos los afectados estarían motivados y comprometidos con la nueva propuesta de forma de trabajo.

Formar equipos estables
Afirmar que el enfoque ágil se hace a nivel de equipo conlleva implícitamente formar equipo, es decir, un conjunto reducido de personas que colaboran en torno al trabajo en uno o más productos o servicios. Los equipos deberían estar compuestos por no más de 10 integrantes. Una de las principales razones de esta limitación es que se promoverá la estrecha comunicación entre los integrantes, y en lo posible cara a cara, esto con equipos grandes presenta problemas de eficacia y eficiencia. También deberíamos promover que dichos equipos tengan una cierta estabilidad, es decir, podría tratarse de equipos que puntualmente y por un corto tiempo se forman para abordar cierto proyecto y luego, terminado el proyecto se separan (para trabajar en otros equipos), pero obviamente muchas ventajas del enfoque ágil se potencian teniendo equipos estables trabajando en los mismos productos o servicios a lo largo del tiempo (o al menos con cierta constancia).

Implantación a nivel de equipo y de cada "línea de trabajo" encargada al equipo
Supongamos que ya tenemos resuelto el hecho que el foco debe estar en el equipo, que la implantación pondrá atención a las particularidades de cada equipo según su contexto. Con esto estaríamos preparados para definir nuestra estrategia de implantación. Sin embargo, un obstáculo frecuente es que un equipo no trabaja solo en una línea de trabajo sino que en varias (o peor aún, en demasiadas :-). Una línea de trabajo es cualquier agrupación de trabajo, orientada principalmente a su seguimiento. Una línea de trabajo puede ser un producto o servicio, un proyecto o cualquier agrupación del trabajo. Si el equipo está encargado de varias líneas de trabajo, la implantación del enfoque ágil debería considerar las particularidades del trabajo en cada línea de trabajo y según esto adaptar la metodología de trabajo según las necesidades específicas de cada línea de trabajo. También existe otras variantes en cuanto a diversidad en una misma línea de trabajo, por ejemplo, si es un producto o servicio es de gran envergadura podrían estar trabajando a la vez diferentes equipos, cada uno en un área determinada, es decir, un mismo producto o servicio podría tener varias líneas de trabajo en paralelo y coordinadas. Lectura recomendada "Agilismo en contextos multiproyecto".

Si no se reconoce la diversidad de contextos a nivel de equipo y de sus productos o servicios, volveríamos a caer en el error de dar soluciones que generen sobreproceso (o falta de proceso), que es justamente uno de las principales críticas que hacen a las iniciativas de mejora de provenientes de definiciones de proceso corporativas. Por ejemplo, determinar si es conveniente o no estimar (o cómo estimar), o si usar Kanban o Scrum, disyuntivas como estas no tiene sentido abordarlas a un nivel más allá del de equipo y producto o servicio, pues existirá el riesgo de no ofrecer soluciones ajustadas a las necesidades de cada contexto. Estas ineficiencias constituirán desperdicios, "waste" en el sentido Lean.

Estrategia de implantación (Revolución o Evolución) del enfoque ágil en el equipo
Demos un paso adicional, supongamos que ya estamos centrados en implantar el enfoque ágil a nivel de equipo y más aún, atendiendo a las particularidades de cada trabajo del equipo (en las diferentes líneas de trabajo de las cuales se encarga). En este punto la implantación del enfoque ágil requiere adicionalmente seleccionar una estrategia para llevar a cabo la incorporación de prácticas ágiles.

Mi post "Revolución o evolución hacia la agilidad" detalla mi opinión respecto de la estrategia de implantación. Aunque se pudiesen tener todas las condiciones favorables para hacer una revolución en la forma de trabajar de tu equipo, probablemente no se podrá hacerla de un día para otro, con lo cual lo recomendable es hacer la implantación de forma incremental, evolucionando las formas de trabajo del equipo.

Roadmap ágil del equipo
Hace mucho tiempo que me alejé de los debates respecto al purismo o radicalismo en cuanto a métodos ágiles. Lo considero infructuoso, al menos para quienes quieren aprovechar los beneficios del enfoque ágil en la práctica. Ser o no ser ágil, aplicar Scrum o aplicar Kanban, usar Puntos u Horas Ideales, usar la herramienta X, la Y o la Z, etc. son debates que en general nos distraen de lo que pienso que es más importante: poder llevar exitosamente el enfoque a la práctica. Siguiendo una estrategia evolutiva se debe establecer un Roadmap hacia la agilidad, diagnosticar la situación del equipo en cada una de sus líneas de trabajo y definir un "Improvement Backlog" para cada las líneas de trabajo. Un Improvement Backlog es una lista ordenada de mejoras que podrían introducirse en la metodología de trabajo de tu equipo. Gran parte de estas mejoras estarán basadas en las prácticas ágiles propuestas por los diversos métodos ágiles (ver una lista en Carta de prácticas ágiles). Agilev Roadmap es un sitio que hemos desarrollado para que un equipo pueda realizar de forma asistida un diagnóstico y evaluación de prácticas ágiles.

Integración continua de prácticas ágiles en el trabajo del equipo
En cada momento el equipo tendrá una metodología de trabajo, la cual deberá evaluarse en términos de su efectividad de acuerdo con las decisiones que se ilustran en la siguiente figura. La introducción de nuevas prácticas ágiles implicará "Hacer ..." cosas nuevas, pero al mismo tiempo deben evaluarse las prácticas actuales (sean tradicionales o ágiles) para decidir si es conveniente "Mantener ..", hacer "Menos de ...", hacer "Más de ..." o simplemente "Dejar de hacer ...".



El enfoque de transformación ágil centrado en el equipo es el más recomendable, pero como hemos visto debe hacerse un trabajo importante de preparación, no necesariamente extenso en el tiempo, pues la estrategia de implantación debe también ser ágil, basada en mejora continua, añadiendo incrementalmente nuevas prácticas y ajustando las ya implantadas. Deben evitarse los típicos atajos para eludir dicha preparación y que harán más probable el fracaso de la implantación, tales como la imposición uniforme de prácticas ignorando la diversidad de los equipos y de su trabajo, o la simple adquisición y formación en herramientas pretendiendo que con eso bastará para el que el equipo modifique su actitud y su forma de trabajar.


Patricio Letelier