¿Existe un buen modelo para elegir un enfoque ágil?

No sé mucho sobre cómo seleccionar metodologías (siempre usé Scrum como base y lo adapté a las necesidades específicas del proyecto y la organización), pero tenga en cuenta que ágil es más una mentalidad que un proyecto.

Si desea introducir una metodología ágil en una nueva organización, los puntos clave son:

• Los miembros del equipo deben estar facultados y ser responsables del resultado (no es necesario que las autoridades superiores aprueben en la mayoría de los casos; por ejemplo, la OP debe poder cambiar el alcance sin involucrar al patrocinador)
• Se requiere dedicación de toda la organización para permitir que incluso un solo equipo sea ágil (por ejemplo, no pudimos comenzar nuestro primer sprint porque el departamento de seguridad no autorizó a los miembros del equipo a obtener las llaves de la sala de desarrollo durante 2 semanas)
• No es un maratón, es un sprint: necesitará poner energía continuamente, no habrá períodos más lentos (no habrá tiempo para sus otras responsabilidades; si está 100% en el proyecto, ningún otro trabajo encajará) en su horario)
• Acepte el cambio: espere que los acuerdos que se hicieron ayer se revisen y posiblemente se deshagan mañana, no se preocupe por eso.
• Sea flexible con respecto al resultado: lo que tiene en mente posiblemente no sea lo que obtendrá después de algunos cambios.
• Y, lo más importante: confíe en los otros miembros del equipo: no debe jugar a la política empresarial o juegos de poder, está remando en el mismo bote.

Si tiene la suerte de que esos puntos sean aceptados (y respaldados por su organización), la metodología concreta es bastante irrelevante.

Si, como usted dice, su organización es extremadamente burocrática y orientada a la cascada, no "perdería" demasiado tiempo pensando en qué hacer y, en cambio, comenzaría a hacer algo:

1. Encuentra un problema para resolver
2. Descubre cómo resolverlo
3. Aplica tu solución
4. Inspeccionar y adaptar

O, como sugiere Dave Thomas :

He aquí cómo hacer algo de manera ágil:

Qué hacer :

Descubre dónde estás

Da un pequeño paso hacia tu meta

Ajuste su comprensión en función de lo que aprendió

Repetir

Cómo hacerlo :

Cuando se enfrente a dos o más alternativas que ofrecen aproximadamente el mismo valor, tome el camino que facilite el cambio futuro.

Haga esto junto con su equipo, deje que la metodología crezca de la mano con el compromiso de las personas, especialmente si desea resultados duraderos.

Ah, y buena suerte ;)

No es realmente una respuesta, por así decirlo, pero le sugiero que vea esta charla muy interesante de Yuval Yeret: "Buenas y malas formas de impulsar la agilidad al estilo Kanban" . Presenta cómo impulsar la adopción de Agile usando Kanban, considerando cada pequeño cambio como una opción, y brinda buenos consejos sobre la gestión de cambios, al estilo Kanban.

Además, también puede leer una entrevista de Yuval Yeret por Ben Linders sobre el mismo tema.

(fuentes: infoq.com)

Primero: el desarrollo ágil de software se trata de cambiar su proceso para que se ajuste a sus necesidades. Scrum no es ágil, Kanban ( JIT ) no es ágil. Es su equipo cambiando procesos o creando sus propios procesos que se adapten a su situación: eso es lo que significa ser ágil.

En estos días entre las metodologías hay una clara comprensión de lo que es más rápido y se resuelve con mejor calidad. Dependerá de su calificación, equipo y organización lo que realmente puede aplicar:

1. La entrega continua es la opción n.º 1 en la actualidad. Puede liberar a PRD incluso si las funciones no están listas (existen técnicas que permiten ocultar esos cambios). Pero necesitarías a alguien con experiencia para que funcione. Y puede resultar en una calidad más pobre que la siguiente opción si tiene un equipo de desarrollo débil.
2. Just-in-time , Theory of Constraints : con estos, libera todas las tareas (o las agrupa en pequeños lotes). Si no eres fuerte en CD, esta es la mejor opción para comenzar. Es un poco más lento que CD y más rápido que Scrum, y resulta en muy buena calidad.
3. Scrum : se basa en la iteración y tiene muchas actividades adicionales. Por lo tanto, da como resultado un desarrollo de menor calidad y más lento (mucho más lento). Pero sigue siendo mucho mejor que Waterfall.

Estos no siempre son mutuamente excluyentes. Nuevamente, lo más probable es que su situación necesite que se modifique algo. Y los procesos no tienen que ser estáticos: puede cambiarlos de un lado a otro según el estado de ánimo actual del equipo.

Te sugiero que lo mantengas simple y sigas estos pasos :)

1. armar un equipo
2. crear una cartera de productos
3. calcule su cartera de pedidos
4. inicio de un sprint o iteración

luego inspeccione, adapte y repita!

Buena suerte :)