1.5. Evaluación de madurez
La evaluación de madurez de Scrum es una fase que se debe ejecutar a medida que el proyecto de adopción de Scrum avanza y no solo al final, pues es necesario medir constantemente el impacto de las diferentes acciones y experimentos sobre las personas y el negocio el general. La medición del impacto puede ser del tipo:
-
Impacto cualitativo: El impacto cualitativo evalúa aspectos relacionados con los comportamientos y las relaciones que se dan entre todos los individuos que están involucrados en el proyecto de adopción de Scrum, a continuación, se presentan algunos aspectos que se pueden evaluar:
- El comportamiento de la alta dirección considerando si en el proceso de desarrollo del proyecto de adopción de Scrum ha existido un aumento en el apoyo por parte de los gerentes hacia las iniciativas de cambio, con un enfoque hacia el cliente y la entrega de servicio.
- La relación con los clientes, evaluando si estas se han fortalecido a través de un trabajo colaborativo que genere un mayor valor tanto para los clientes como para la organización.
- El índice de felicidad laboral, cada colaborador involucrado en el proyecto de adopción, puede manifestar diariamente a través de algún mecanismo como una encuesta o un tablero de puntos su nivel de felicidad, esto arrojara información valiosa quer permitirá soportar la toma de algunas de las decisiones que tienen un impacto directo sobre la creatividad, productividad, motivación y compromiso del equipo.
-
Impacto cuantitativo: el impacto cuantitativo se realiza a través del diagnóstico de agilidad que incluye los elementos de las siete épicas del Backlog y adicionalmente un diagnóstico que incluye las dieciséis prácticas planteadas en Scrum, esto permitirá conocer qué tan alineada está la organización con la cultura ágil y en qué grado se han adoptado las prácticas de Scrum. Para evaluar el impacto cuantitativo del proyecto de adopción se presenta en el Capítulo 2 Evaluación de madurez una herramienta que permite realizar la medición del impacto cuantitativo del proyecto de adopción de Scrum.
Dentro de esta fase de evaluación de madurez del ciclo de vida del proyecto de adopción de Scrum, además de evaluar el impacto cualitativo y cuantitativo de la adopción se debe realizar un análisis de los resultados del proyecto y la definición de una estrategia de sostenibilidad.
1.5.1. Análisis de los resultados del proyecto
Aunque no haya terminado el proyecto de adopción Scrum, es necesario no perder de vista los resultados que se van generando a lo largo del tiempo, ya que las personas se sienten más motivadas cuando perciben lo que han logrado. Si los resultados se ven pronto, el optimismo y el apoyo de las partes interesadas irá en aumento, y se fortalecerá la credibilidad en la adopción.
El seguimiento de la transformación ágil se debe dar a diferentes frecuencias durante la ejecución del proyecto, para ello es importante considerar los eventos propuestos por Scrum.
Algunas maneras de medir los resultados son:
Seguimiento a las restricciones Tiempo-Costo-Alcance
Es importante realizar un seguimiento constante a las restricciones del proyecto (no solo al final), para evitar desviaciones o incumplimientos, dado que el cambio en uno de los tres factores (tiempo – costo – alcance) tiene repercusión inversa (positiva o negativa) en al menos uno de los otros dos factores (o ambos).
Aumentar | Reducir | |
---|---|---|
Alcance | Aumentar el alcance implica retraso en la entrega, un aumento de costo o ambos. | Reducir el alcance supone una mejora en costo, adelanto en la entrega o ambos |
Presupuesto | Aumentar el presupuesto implica extender el alcance, adelantar la entrega o ambos. | Reducir costo implica reducir el alcance, retrasar la entrega o ambos. |
Plazo de entrega | Extender el plazo de entrega puede mejorar el costo, aumentar el alcance o ambos. | Adelantar una entrega implica aumentar el costo, reducir el alcance o ambos. |
Informes regulares / informe final
Los informes son una herramienta importante para la comunicación con la alta dirección pues son una fuente de información para la toma de decisiones.
Se debe tener especial cuidado al construir informes pues aunque existen muchos formatos diferentes, existe el riesgo de hacerlos pesados, molestos y en última instancia, que no sean leídos o entendidos. La clave esta en:
- Incluir elementos críticos relevantes
- Evitar los elementos poco importantes (sobrantes)
- Generarlos en poco tiempo (de preferencia casi automáticos)
La frecuencia con la cual se generan los informes depende de la duración del proyecto, pues se debe cuidar que no sea muy corta como para sobrecargar a los responsables de la elaboración de los informes y quienes los revisan, ni muy larga como para que no se puedan tomar decisiones a tiempo que permitan corregir desviaciones durante la ejecución del proyecto. Lo recomendable es:
- Para proyecto cortos, con duración entre 1 a 6 meses, se pueden presentar informes quincenales.
- Para proyectos medios, con duración entre 6 meses a 2 años, se pueden presentar informes mensuales.
- Para proyectos largos, con duración de más de 2 años se pueden presentar informes trimestrales.
Los mejores informes de un proyecto crean responsabilidad y compromiso dentro del equipo. Al mismo tiempo, descubren problemas, reducen los riesgos y, sobre todo, garantizan que te encuentres encaminado a cumplir los objetivos del proyecto.
Otras recomendaciones para la elaboración de informes son:
Elementos críticos | Elementos opcionales | Elementos a evitar |
---|---|---|
* Nombre del proyecto. * Visión del proyecto. * Estado del proyecto. * Avance. * Proyección para el corto plazo o próximos Sprints. * Problemas u obstáculos. * Próximas tareas o actividades. |
* Enlace al cronograma global del proyecto. * Entregas completas hasta la fecha. * Notas de apoyo. * Gráficas con métricas relevantes (costo-tiempo-alcance). |
* Demasiado texto o lenguaje ambiguo. * Errores de gramática, ortografía y puntuación. * Sobrecarga de información. * Exceso de gráficos. * Rumores sobre posibles cambios o ajustes al proyecto. |
Retrospectiva
A diferencia de la retrospectiva de Sprint, esta retrospectiva tiene un enfoque global, es decir que no está orientada solo a que participen los miembros del equipo de adopción Scrum, pues se busca que participen las partes interesadas que han sido impactadas (proyectos, equipos, gerencias, etc). Durante este evento:
- Se generan conversaciones poderosas, en cuanto a personas, relaciones, procesos y herramientas.
- Se comparten los desafíos y dificultades del día a día.
- Se proponer acciones para potenciar los buenos resultados y acciones para remover las barreras o limitantes del proyecto.
- Se socializa el progreso de la adopción con respecto a los resultados de las acciones y experimentos.
Según la duración del proyecto lo idean es que la frecuencia sea entre 3 y 6 meses, con una duración aproximada de entre 1 y 2 horas. A continuación se presentan algunas recomendaciones para realizar una buena retrospectiva:
- Establecer el escenario: consiste en dar tiempo a las personas para “llegar” y ponerse en el estado de ánimo adecuado antes de iniciar los temas de la retrospectiva, antes de iniciar.
- Circulo de apertura: lo ideal es empezar haciendo un círculo, para que todos pudieran verse entre ellos y hacer una breve introducción de lo que tratará durante la sesión.
- Recolectar datos: contar con datos a la mano ayuda a todos a “acordarse” de los aspectos relevantes a abordar, además crea un conjunto compartido de información desde diferentes perspectivas.
- Compartir experiencias: se recomienda constituir sub-grupos heterogéneos para que compartan sus experiencias.
- Indagar: entender por qué las cosas ocurrieron, cómo ocurrieron, identificar tendencias y patrones (mirar el bosque y no el árbol).
- Decidir qué hacer: elegir pocos aspectos en los cuales trabajar y crear planes concretos de acciones para intentar mejorarlos.
- Cerrar la retrospectiva: agradecer a los participantes, cerrar la reunión y pensar como mejorar las retrospectivas.
1.5.2. Definir la estrategia de sostenibilidad
Esta última parte es crucial para asegurar que todo el esfuerzo realizado durante todo el proyecto de adopción Scrum realmente quede adherido a la organización, ya que los nuevos resultados implicarán hacer las cosas de manera diferente y de forma sostenible.
Se deben considerar diferentes factores que pueden afectar los esfuerzos para sostener el cambio en la organización, como por ejemplo:
- Cambios en la estrategia.
- Cambios en el mercado.
- Cambios en el staff directivo.
- Contratación de nuevo personal.
- Diseño de estrategias y planes de reconocimiento y recompensas.
- Creación o fortalecimiento de canales de retroalimentación.
La mentalidad
En muchos casos, el cambio fracasa porque se intenta ir a las práctica sin antes cambiar la mentalidad, este error se comete por lo general por el afán de la organización en ir más rápido a la adopción de las prácticas y las ceremonias de Scrum.
Es común encontrar la situación en la que un jefe tradicional continua actuando de forma autoritaria sin cambiar su modelo de liderazgo, ni la forma en la que realiza las actividades, aunque su departamento ahora se llame “equipo ágil”.
Vale la pena resaltar que Scrum es un cambio en el paradigma organizacional que está en manos de las personas, y no por cambiar el nombre de una reunión o utilizar elementos como tableros kanban la adopción de Scrum va a tener éxito.
Costos de NO sostener el cambio
Si bien es difícil medir los costos de los esfuerzos perdidos, se debe tener en mente que los riesgos que afectan al sostenimiento del cambio son muy altos y permanecen por mucho tiempo en la memoria colectiva de la organización:
- Resultados peores que los existentes antes del cambio.
- Esfuerzos, duplicados, costos elevados.
- Objetivos más complejos con menos recursos para alcanzarlos.
- Volver a viejas prácticas, lo que implica pérdida de credibilidad y confianza en el cambio.
- Efectos desfavorables en el clima organizacional.