Una de las preguntas más comunes que recibimos de los profesionales de PMO cuando hablamos de entregar proyectos con técnicas Agile es “¿cómo garantizo los proyectos Agile?”. La Garantía de Calidad es uno de los servicios más importantes que una PMO puede proporcionar a una organización y, para muchos, parece que los proyectos con entrega Agile no pueden garantizarse. ¿Es esto cierto? Aquí argumentaremos que es absolutamente posible hacer garantía de calidad en proyectos con entrega Agile, pero como PMO (u otro profesional de Assurance / Garantía de Calidad) es posible que debas cambiar tu forma de pensar y de enfoque, tanto para ver valor de hacer garantía de calidad como para asegurarte de que no impides que el proyecto entregado con Agile sea ágil (después de todo… debe haber una buena razón por la que se han elegido métodos Agile para entregar el proyecto… ¡¿verdad ?!)
¿Por qué hay tensión entre los proyectos entregados con Agile y hacer Garantía de Calidad de Proyectos?
La garantía de calidad es un proceso que se realiza para dar confianza a la organización y a las partes interesadas de que el proyecto se gestiona de una manera que probablemente dé lugar a los productos que necesitamos para lograr los resultados. En un proyecto tradicional / lineal / en cascada / predictivo (¡hay muchos nombres para proyectos con entrega no Agile!). Podemos hacer Garantía de Calidad verificando que los entregables clave existen, son de la calidad adecuada y se revisan y actualizan regularmente.
Los entregables típicos en la Garantía de Calidad ‘tradicional’ incluyen:
- Declaración de alcance que aclara lo que está dentro y fuera del alcance
- Un cronograma que detalla cuándo se realizará todo el trabajo necesario para entregar el alcance y quién lo hará.
- Registros RAID que detallan los riesgos y cómo se gestionarán
- Documentos presupuestarios que expliquen qué dinero se gastará y dónde
- Planes de realización de beneficios
… Así como otros elementos en función de las necesidades de gobierno de la organización
¿Por qué sería esto un problema para un proyecto con entrega Agile? Bueno, en el meollo del asunto está este hecho: los proyectos con entrega Agile son fundamentalmente diferentes de los proyectos lineales / en cascada / predictivos (Nota: estamos hablando de “real Agile” aquí, no de un proyecto en cascada que ha tomado prestadas un par de palabras de la metodología Scrum y afirman ser Agile).
Como Profesional de Garantía de Calidad (Assurance Practitioner), hay dos factores clave que debes comprender:
1) Agile requiere un enfoque diferente para la gestión de proyectos
En un proyecto de Waterfall, es vital que haya una declaración de alcance claramente definida y documentada en la que se basen todos los planes, entregables y trabajo. En otras palabras: averiguamos qué se supone que debemos ofrecer, luego averiguamos qué recursos y tiempo necesitamos para que eso suceda.
Es en situaciones en las que no es posible definir el alcance por adelantado cuando Agile es apropiado. Ya sea porque el proyecto es tan nuevo o innovador que es imposible, o porque esperamos tantos cambios que hay poco valor en detallar nuestro alcance y el cronograma posterior por adelantado. Agile proporciona una estructura sobre cómo avanzar con disciplina y rigor para garantizar que el proyecto siga generando valor.
Entonces, por su propia definición, un proyecto con entrega Agile no tendrá una declaración de alcance (si podemos definir el alcance por adelantado y trabajamos en una organización que valora la Garantía de Calidad «tradicional», entonces ¡Agile probablemente no sea un enfoque de entrega adecuado para el proyecto!) y si no hay una declaración de alcance, no podemos construir un cronograma o presupuesto detallado para todo el proyecto por adelantado.
2) Los proyectos con entrega Agile valoran la documentación de forma diferente
Debido a los diferentes enfoques para la administración del alcance, los equipos que trabajan con Agile deben tener una colaboración cercana y continua con el cliente / usuario final para reevaluar continuamente y aprender qué es lo más importante en lo que hay que trabajar y entregar. Para que esto sea fluido y rápido (algunos lo llamarían … agile …) se utilizan herramientas interactivas como los tableros Kanban para realizar un seguimiento del trabajo y se evitan las herramientas tradicionales como los planes y los diagramas de Gantt.
Por esta razón, es poco probable que un proyecto entregado con Agile tenga o mantenga los entregables que normalmente se revisan en la Garantía de Calidad «tradicional».
Este enfoque de trabajo se describió por primera vez con la publicación del manifiesto Agile (a continuación). Es importante señalar que el manifiesto no dice que NO puede haber documentación. Simplemente está diciendo que la colaboración, las interacciones y el software (o producto) de trabajo son más importantes que la documentación sólida.
El Manifiesto Agile
Descubrimos mejores formas de desarrollar
software haciéndolo y ayudando a otros a hacerlo.
A través de este trabajo hemos llegado a valorar:
Individuos e interacciones sobre procesos y herramientas
Software de trabajo sobre documentación completa
Colaboración con el cliente sobre la negociación del contrato
Responder al cambio en lugar de seguir el plan
Es decir, si bien hay valor en los elementos de
a la derecha, valoramos más los elementos de la izquierda.
Entonces, Garantía de Calidad y Proyectos Agile, ¿es una combinación imposible? ¡No absolutamente no! Pero si eres un Profesional de la Garantía de Calidad (Assurance Practitioner), es posible que debas modificar tu forma de pensar y tu enfoque para asegurarse de obtener la Garantía de Calidad que necesitas (por ejemplo, la gobernanza de tu organización) y que la organización aún obtenga el valor esperado de la entrega de proyectos con Agile.
Tres formas de entregar Garantía de Calidad y proyectos Agile con éxito:
1) Asegurar que Agile se haga bien
Deberás aprender sobre los artefactos y ceremonias Agile y los valores que los sustentan para comprender cómo se ve lo bueno. Pero, como mínimo, debes poder identificar una estructura y disciplina en las formas de trabajo del equipo y cómo y cuándo se libera el valor al cliente.
En cuanto a actividades (ceremonias) deberías ver:
- Evidencia de que el trabajo está estructurado en sprints o timeboxes
- Evidencia de acumulación / refinamiento
- Evidencia de planificación de sprints
- Stand-ups diarios / scrums diarios
- Reseñas de Sprint
- Retrospectivas y evidencia de aprendizaje y mejora continuos
- Evidencia de colaboración con el cliente
En términos de artefactos / entregables, deberías ver:
- Un backlog priorizado
- Historias de usuarios bien escritas
- Evidencia de planificación y seguimiento del progreso, como tableros Kanban, emisor de información o Burn charts.
2) Asegúrate de que Agile sea lo adecuado para este proyecto
Los métodos Agile pueden mejorar la colaboración, la velocidad de entrega, la calidad de la entrega y la capacidad de lidiar con el cambio para la mayoría de los tipos de proyectos, ¡pero no para todos! Para poder decir con confianza que el proyecto Agile conducirá a los resultados deseados, es importante asegurarse de que sea adecuado para la entrega Agile.
| Apto para entrega Agil | No Apto para entrega Agile |
|---|---|
| Es imposible definir el alcance por adelantado y / o hay mucha flexibilidad e incertidumbre en torno al alcance. | El alcance se puede definir por adelantado y es vital que todo el alcance se entregue exactamente como se define |
| Contamos con un equipo dedicado que trabajará en conjunto durante todo el proyecto. | Los miembros del equipo van y vienen o solo están disponibles por períodos cortos de tiempo |
| El cliente / usuario está dedicado y disponible para pruebas y comentarios continuos | El cliente / usuario no está disponible para probar o dar comentarios |
| La organización comprende las implicaciones del uso de métodos de entrega Agile y está dispuesta a modificar procesos estándar como Garantía de Calidad, asignación de recursos, realización de beneficios y potencialmente contabilidad / facturación. | La organización no está dispuesta a modificar ningún proceso y requiere una documentación rígida y el cumplimiento de los procesos estándar durante todo el proyecto. |
Esta garantía de calidad se puede realizar con cuestionarios o asesoramiento (por ejemplo, de la PMO) al inicio del proyecto, y esto se puede verificar como parte de las actividades de garantía de calidad independientes, una vez que el proyecto está en marcha.
3) Encontrar un compromiso
Debe haber una razón por la cual se eligió la entrega Agile para el proyecto (si no se puede definir una razón, tal vez sea una señal de que se trata de una entrega lineal…) así que no cometas el error de obligar al proyecto a cumplir con sus mecanismos de garantía de caliad. – al hacerlo, puedes restringir el proyecto y reducir la ganancia de valor de la entrega Agile.
Considera el desafío que plantea el proyecto Agile como una oportunidad para revisar (y potencialmente optimizar) tus prácticas de garantía de calidad. ¿Todo lo que haces (y todo lo que pides a los proyectos), realmente agrega valor? En todo momento apuntar a pedir el MVB – Burocracia Mínima Viable. ¿Quizás puedas priorizar lo que es más importante y pedirle al equipo del proyecto Agile que produzca ese producto en particular? Y si eres capaz de priorizar algunos aspectos como importantes y otros como no importantes, ¿por qué no llevarlo a todos los proyectos?
Tiene que haber un elemento de toma y daca entre tus necesidades de garantía de calidad y el proyecto con entrega Agile. En el corazón del método Agile está el impulso para entregar valor (enfócate en todo momento en el trabajo y las características que agregan valor, y elimina todo lo demás). Entonces, si hay un aspecto de tu práctica de garantía de calidad que es vital para la organización, es de interés para el proyecto Agile alinearse con él. No lo olvides: la última oración del Manifiesto Agile (sí, puede que valga la pena retroceder y volver a leerla) es
“Si bien hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda”.
Eso significa que el proyecto Agile debe valorar y centrarse más en la colaboración y el software de trabajo (producto) que en los contratos y la documentación, ¡pero no significa que utilicen o produzcan documentación en absoluto! Por lo tanto, debería ser posible encontrar un compromiso que se adapte tanto a las necesidades de garantía de calidad como a las necesidades de flexibilidad y agilidad en el proyecto con entrega Agile.
Comprender la confianza
¿Qué es la confianza? El Diccionario Oxford lo define como “el sentimiento o la creencia de que uno puede tener fe o confiar en alguien o algo”.
Tener en cuenta que la Garantía de Calidad consiste en dar confianza en que un proyecto avanza como se esperaba, cambiar nuestra mentalidad e identificar los enfoques adecuados nos ayudará a ganar esa confianza; tal vez sin los documentos «tradicionales», podríamos haber esperado a ver antes de que Agile se convirtiera en uno de los enfoques para entregar nuestros proyectos.
Psicológicamente, confianza = seguridad.
Siempre que utilicemos las herramientas pragmáticas y las ayudas visuales que Agile proporciona, por supuesto, es perfectamente posible hacer que los patrocinadores y los clientes se sientan seguros en las manos de nuestra entrega.
Sin embargo, una nueva perspectiva podría ser que, considerando que los proyectos Agile requieren un contacto constante y regular con el Cliente (y cualquier Patrocinador interno), la confianza en un par de manos seguras debe estar implícita y sentirse por la naturaleza misma del trabajo que nuestros equipos están haciendo.
The Wellingtone APM Accredited Agile for PPM Professionals is a course designed for Practitioners by Practitioners who are not working in a fully Agile environment; helping to bring Agile skills and practices to a realistic environment where hybrid is the way forward.
El curso APM Accredited Agile for PPM Professionals de Wellingtone es un curso diseñado para profesionales por profesionales que no están trabajando en un entorno totalmente Agile; ayudando a llevar las habilidades y prácticas Agile a un entorno realista donde el híbrido es el camino a seguir.
Si necesitas más información recuerda que con Wellingtone puedes obtener 30 min de Consultoría Gratis. Ponte en contacto con nosotros ya!
