Aunque los cursos y certificaciones del estilo CSM (Certified Scrum Master) o ACP (Agile Certified Practitioner) siguen en aumento, estas iniciativas no parecen ser la solución. El desencanto con el enfoque ágil comienza a crear nuevas corrientes, no necesariamente contrarias, pero recelosas de las recetas genéricas difíciles de llevar a la práctica en contextos específicos, por ejemplo, el término Post-Agilism, o una visión crítica del estado del enfoque ágil en Maybe Agile is the Problem).
Hasta ahora, se ha promovido el “pseudo-purismo” en cuanto a la aplicación de los principios y prácticas ágiles, el “todo o nada”, el “ser o no ser Ágil”, “el aplicar o no Scrum”, etc. Extreme Programming (XP) en este sentido es menos radical, y aunque en su nombre “Extreme” se refiere a la aplicación en extremo de cada una de sus 12 prácticas, reconoce que es posible que no se apliquen todas o que alguna se apliquen en menor medida, eso sí, advirtiendo que esto restaría efectividad al método pues las prácticas se relacionan entre sí. Scrum sugiere menos prácticas que XP y a priori resultaría más sencillo de implantar, sin embargo, su postura es mucho más radical en cuanto a la aplicación de sus elementos.
Bastaría con hacer una lista de elementos (roles, prácticas y artefactos) propuestos por Scrum y XP, y luego hacer una reflexión en equipo preguntándose en qué medida en un determinado contexto de producto (relación con el cliente, dominio de aplicación, tecnología, composición del equipo, etc.) cada uno de dichos elemento podría aplicarse y en qué nivel de profundidad.
Tomemos por ejemplo el rol Cliente en XP o Product Owner en Scrum. El Product Owner define y ordena el Product Backlog (el trabajo pendiente asociado al producto) teniéndolo preparado para cuando se realice la planificación. Este Product Owner está altamente disponible para el equipo (ojalá in-situ como remarca XP). El Product Owner es una única persona y representa a todos los otros posibles stakeholders, y es su responsabilidad resolver requisitos o prioridades en conflicto. En XP es el cliente el que debería escribir las Historias de Usuario y definir las correspondientes pruebas de aceptación. Pero es difícil tener un cliente con este nivel de participación, y si el cliente no asume dicho trabajo será el equipo quien tendrá que realizarlo, eso sí, el cliente mantendrá la responsabilidad de las decisiones que se tomen al respecto. En este caso, ¿sería correcto decir que estamos usando Scrum o XP si no se cumple con dicha definición de Cliente o Product Owner, aunque estemos aplicando otros elementos ágiles?. Tal como se suele interpretar Scrum, probablemente no nos calificarían como un equipo Scrum, en el caso de XP probablemente podríamos tener el calificativo de equipo XP, dependiendo de qué otros elementos estemos aplicando y en qué medida.
El pseudo-purismo en la aplicación de Scrum o XP ha marcado distancia con los métodos tradicionales, lo cual es positivo en término de tener referencias claras de uno y otro enfoque. Sin embargo, desde la perspectiva de implantación dicho purismo como estrategia de cambio para un equipo representa una revolución hacia métodos ágiles. Esto puede ser ideal y deseable en ciertos contextos, pero en muchos otros es claramente inviable, o incluso probablemente llevaría a una decepción y frustración a mediano plazo.
¿Qué alternativa tiene un equipo para el cual no es posible llevar a cabo dicha revolución? ¿debe esperar hasta que tenga condiciones más favorables para embarcarse en el enfoque ágil? ¿debe resignarse a que el enfoque ágil no es para ellos? ¿qué tan importante es poder calificarse como equipo Scrum o XP?
Sí, existe otra alternativa, y consiste en implantar el enfoque ágil con una estrategia de evolución. El equipo no tendría que esperar y en un corto plazo podría estar ya aplicando ciertos elementos ágiles e iniciando un camino de mejora continua hasta donde pueda y le interese llegar. Los elementos del enfoque ágil deberían actuar como una “lista de deseos” un punto de referencia hacia el cual se intenten dirigir los cambios de proceso. No hay por qué obsesionarse en tener la calificación Scrum o XP, lo realmente importante es que el equipo asimile los principios del enfoque ágil (del Manifiesto Ágil) e incorpore los elementos que le aporten mayor valor, y que a su vez puedan ser efectivamente aplicados en un contexto y momento determinado.
Curiosamente, CMMI, visto por alguno como el Satanás para las metodologías ágiles :-), pasó por una situación similar en cuanto a estrategia de implantación. Inicialmente sólo existía el modelo CMMI Escalonado (Staged) para el cual hay que demostrar evidencias de implantación de todas las prácticas incluidas en el nivel que se quiere certificar (y de los niveles inferiores). Posteriormente, como una alternativa apareció el modelo CMMI Continuo el cual permite certificarse sólo de aquellas prácticas que el equipo considera más importantes o factibles de implantar de acuerdo con su contexto de trabajo.
Kanban, al menos en la propuesta de David J. Anderson, sugiere una estrategia evolutiva insistiendo en que para encontrar una menor resistencia al cambio inicialmente se debe cambiar lo menos posible, es decir, para asegurar el éxito de introducir Kanban lo mejor es partir por dar soporte a la forma actual de trabajo del equipo y luego ir realizando mejoras, una vez que Kanban esté establecido. Sin embargo, tal como ocurre en XP o Scrum, en Kanban la mejora se centra en sus propias prácticas, sin prestar atención a prácticas de otros métodos.
La estrategia evolutiva requiere un diagnóstico del contexto del equipo y su trabajo en productos o servicios. El diagnóstico debería orientarnos para establecer un roadmap para la implantación incremental de prácticas ágiles (ver Carta de prácticas ágiles y/o acceder a AGILE Roadmap para realizar un diagnóstico preliminar on-line). Este roadmap constituye un Improvement Backlog para el equipo, es decir, una lista ordenada de mejoras metodológicas que se irán introduciendo y evaluando. La siguiente figura ilustra cómo para un equipo determinado sus prácticas lo pondrían en un punto intermedio entre una supuesta clasificación NO ágil y ágil. Con una estrategia evolutiva la idea es mover paso a paso al equipo hacia prácticas ágiles. Cada paso hacia el enfoque ágil debería ser "razonable" para que el esfuerzo invertido en dicho paso se corresponda con la rentabilidad conseguida. La Transformación Ágil también debe ser fiel a los principios ágiles, NO debería ser un esfuerzo largo en el tiempo, con mucha preparación y sin mostrar resultados (al menos parciales).
¿Existen propuestas para Transformación Ágil basadas en una estrategia evolutiva?. Aunque la recomendación es demasiado cercana, hasta donde llega mi conocimiento sólo nuestra metodología TUNE-UP Process (www.tuneupprocess.com) y apoyada por su Worki ofrecen una estrategia evolutiva, es decir, que permite al equipo poder situarse en un punto de partida y luego ir modificando la forma de trabajo, llegando, si se desea, a cumplir totalmente con Kanban, Scrum o XP. TUNE-UP Process y Worki abordan la implantación del enfoque ágil (y su posterior mejora) desde una perspectiva integradora de prácticas ágiles, independientemente de si ellas provienen de XP, Scrum, Kanban o Lean.
Patricio Letelier
No hay comentarios:
Publicar un comentario