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, 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 agilismo) 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 agilismo: 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 agilismo 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 agilismo 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 servicio o producto con el cual trabaja el 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 un producto o servicio sino en varios (o peor aún, en demasiados:-) ). En esta situación, la implantación del agilismo en el equipo debería también considerar las particularidades del trabajo del equipo en cada producto o servicio con el que trabaja. También existe otras variantes en cuanto a diversidad en un mismo producto o servicio; por ejemplo, si el producto es de gran envergadura podrían estar trabajando diferentes equipos, cada uno en un área determinada del producto, o si en un mismo producto hay varias líneas de trabajo (para un mismo equipo o varios), por ejemplo, cuando en un mismo producto se está ofreciendo mantenimiento continuo, desarrollo a medio plazo de nuevos módulos, y/o soporte al cliente. Cada línea de trabajo en un producto podría requerir un tratamiento diferenciado en cuanto a planificación y seguimiento. Lectura recomendada "Agilismo en contextos multi-proyecto".

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 sobre-proceso (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 coorporativas. 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 agilismo en el equipo
Demos un paso adicional, supongamos que ya estamos centrados en implantar agilismo a nivel de equipo y más aún, atendiendo a las particularidades de cada trabajo del equipo (en los diferentes productos o servicios que trabaja). En este punto la implantación del agilismo requiere adicionalmente seleccionar una estrategia para llevar a cabo la incorporación de prácticas ágiles.

Mi post "Revolución o evolución hacia el agilismo" detalla mi opinión respecto de la estrategia de implantación. Aunque pudieses tener todas las condiciones favorables para hacer una revolución en la forma de trabajar de tu equipo, probablemente no podrás hacerla de un día para otro, con lo cual lo más natural 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 improductivo, al menos para quienes quieren aprovechar los beneficios del agilismo 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 el agilismo a la práctica. Siguiendo una estrategia evolutiva debes concentrarse en establecer el Roadmap hacia el agilismo, diagnosticar la situación de tu equipo con cada uno de sus productos o servicios, y definir un "Improvement Backlog" general, común para todos los productos o servicios, o varios, si las diferencias son significativas entre la forma de trabajo requerida por cada producto o servicio. 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 mi lista en Carta de prácticas ágiles). AGILE 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 implantación 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