¿Qué es Agile 2?

Tras 20 años del movimiento Agile, surgido formalmente con el Manifiesto ágil en el año 2001, son muchas las lecciones aprendidas, y ya se evidencia la necesidad de pivotarlo, adaptando y enriqueciendo los valores y principios de la agilidad.

Un equipo de expertos agilistas ha creado Agile 2, cuyos análisis y propuestas se resumen en la página https://agile2.net/, la próxima iteración de Agile.

Desde mi punto de vista, Agile surge como un MVP que ha dado a las organizaciones la libertad de iterar y evolucionar la agilidad acorde a sus necesidades, contexto y criterios propios, y como en todo proceso empírico, la experimentación deja resultados que necesitan ser revisados para ser cambiados o para ser incorporados como mejores prácticas que seguirán evolucionando dentro de la cultura de la mejora continua.

Agile 2 propone evolucionar los valores y principios del manifiesto ágil, a fin de incorporar nuevos elementos que fortalezcan la fundamentación de los marcos de trabajo, cuyo fin último es apoyar a las organizaciones y equipos de trabajo en la resolución efectiva de sus problemas y en el logro de sus metas y objetivos.

Entre los cambios destacados, en materia de Valores, Agile 2 propone nuevos valores en un equilibrio donde éstos se complementan, incorporando factores clave como el Liderazgo y la importancia de las personas además de los equipos:

Valores Agile	Valores Agile 2
Aunque valoramos los elementos de la derecha, valoramos más los de la izquierda	Valoramos todas estas cosas y nos esforzamos por equilibrarlas o combinarlas para cada situación.
1. Individuos e interacciones sobre procesos y herramientas 2. Software funcionando sobre documentación extensiva 3. Colaboración con el cliente sobre negociación contractual 4. Respuesta ante el cambio sobre seguir un plan	1. Consideración y prescripción 2. Resultados y productos 3. Particulares y equipos 4. Comprensión empresarial y comprensión técnica 5. Empoderamiento individual y buen liderazgo 6. Adaptabilidad y planificación

En el campo de los principios, Agile 2 los amplia y estructura en 10 áreas:

Principios Agile

Principios Agile 2

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. 2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. 3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.   4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. 5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. 6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.   ­7. El software funcionando es la medida principal de progreso. 8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. 9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad. 10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. 11. Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados. 12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

1. Planificación, transición y transformación -    Cualquier iniciativa requiere tanto una visión u objetivo como un plan flexible, orientable y orientado a resultados. -    Cualquier transformación significativa es principalmente un viaje de aprendizaje, no simplemente un cambio de proceso. -    El cambio debe venir desde arriba. -    El desarrollo de productos es principalmente un viaje de aprendizaje, no simplemente una "implementación". 2. Producto, cartera y partes interesadas -    Obtener comentarios del mercado y las partes interesadas de forma continua. -    La única prueba de valor es un resultado comercial. -    Trabajar de forma iterativa en pequeños lotes. -    El diseño del producto debe integrarse con la implementación del producto. -    Crear documentación para compartir y profundizar la comprensión. -    Quienes ofrecen productos y servicios deben sentirse responsables ante sus clientes por el impacto de los defectos. 3. Datos -    Los datos tienen un valor estratégico. -    El modelo de información de una organización es estratégico. -    Recopile y analice cuidadosamente los datos para la validación del producto. 4. Marcos y metodologías -    Adapte un marco ágil a su trabajo, su cultura y sus circunstancias. -    Las organizaciones necesitan un "marco inicial" adaptado a sus necesidades. 5. Dimensión técnica y fluidez técnica -    La agilidad técnica y la agilidad empresarial son inseparables: no se puede comprender una sin comprender también la otra. -    Los líderes empresariales deben comprender cómo se crean y se entregan los productos y servicios. -    El liderazgo en la entrega de tecnología debe comprender la entrega de tecnología. -    Los equipos y el liderazgo en la entrega de tecnología deben comprender el negocio. 6. Individualidad vs. Equipo -    Todo el equipo resuelve todo el problema. -    Fomentar la diversidad de comunicación y la diversidad de estilos de trabajo. -    Los individuos importan tanto como importa el equipo. -    Tanto los especialistas como los generalistas son valiosos. -    Las diferentes certificaciones Agile tienen un valor desigual y requieren un escrutinio. 7. Equipo v. Organización -    Favorecer los flujos de entrega de extremo a extremo, en su mayoría autónomos, cuyos equipos tienen autoridad para actuar. -    Fomentar la colaboración entre equipos a través de objetivos compartidos. -    Favorecer a los equipos de larga duración y convertir su experiencia en una ventaja competitiva. 8. Mejora continua -    Ponga límites a las cosas que causan arrastre. -    Integrar temprano y con frecuencia. -    De vez en cuando, reflexione y luego promulgue el cambio. -    No comprometa completamente la capacidad. 9. Enfoque -    Respetar el flujo cognitivo. -    Facilitar a las personas la participación en un trabajo centrado e ininterrumpido. -    Fomentar intercambios profundos. 10. Liderazgo -    El factor de éxito más impactante es el paradigma de liderazgo que la organización exhibe e incentiva. -    Proporcionar un liderazgo que pueda empoderar tanto a las personas como a los equipos, y establecer la dirección. -    Escala de modelos de liderazgo. -    Los modelos organizativos de estructura y liderazgo deben evolucionar. -    Los buenos líderes están abiertos. -    Un equipo a menudo necesita más de un líder, cada uno de un tipo diferente. -    La autoorganización y la autonomía son aspiraciones y deben darse de acuerdo con la capacidad. -    Validar ideas a través de pequeños experimentos contenidos. -    El desarrollo profesional de las personas es fundamental.

 

Muchas empresas han complementado Agile con prácticas DevOps, Lean, Kanban, Management 3.0, incluso han integrado la agilidad a la gerencia de proyectos y al uso de datos estadísticos, métricas e indicadores para medir desempeño y éxito.

Estoy de acuerdo en fortalecer la agilidad con estos nuevos valores y principios, pero considerar que Agile ha sido un fracaso o que necesita un nuevo comienzo, en mi opinión, no es cierto en todos los casos, y que en todo caso dependerá de la madurez agile en que se encuentre la organización.

¿Y tú que opinas? Te leo en los comentarios.

Gracias

Ig @Soy.Agile.Coach

#Agile, #Agile2, #AgileCoach, #ScrumMaster, #ManifiestoAgil

La Maestría Técnica del Agile Coach

Entre las competencias del agile coach, y del Scrum master, destaca la maestría técnica, especialmente importante cuando se trata de equipos que trabajan con productos de tecnología.

La maestría técnica nos permite conectar con los retos y oportunidades del equipo de trabajo, participar en conversaciones donde se tratan los problemas de arquitectura, seguridad, plataformas, calidad del software, automatización, etc. No digo que tengamos que ser especialistas en cloud, phyton o java, o dominar las herramientas de integración continua y de automatización de pruebas, pero si tener el conocimiento necesario para comunicarnos efectivamente con el equipo.

Con esta competencia, ayudamos al equipo a cumplir con el noveno principio del manifiesto ágil: La atención continua a la excelencia técnica y al buen diseño mejora la agilidad, y como se afirma en el marco de escalado LeSS: La agilidad organizativa está limitada por la agilidad técnica.

Algunas técnicas que favorecen la excelencia técnica son:

• Lean Code: es código limpio que funciona (Ron Jeffries), está bien estructurado, tiene un propósito claro, sigue buenos principios de diseño y es fácil de entender y de mantener. Es una filosofía de diseño de desarrollo de software que enfatiza la simplicidad, la eficiencia, la flexibilidad y la accesibilidad.
• Deuda Técnica: préstamo que nos permite avanzar y aprender rápidamente (Ward Cunningham), y luego se paga refactorizando el código para que refleje el conocimiento adquirido.
• Pair Programming: especifica que siempre haya dos personas trabajando al mismo tiempo en el código y que, en la medida de lo posible, se sienten juntas. Una se encarga de escribir el código y la otra de supervisarlo en tiempo real. Al mismo tiempo, están constantemente intercambiando impresiones: debaten problemas, encuentran soluciones y desarrollan ideas creativas.
• Costo del Cambio: es común asegurar que corregir un error se vuelve exponencialmente más costoso mientras más tarde se detecte. Beck (XP) sugiere que, con una buena combinación de tecnologías y prácticas de programación, la curva puede achatarse, manteniendo el costo de cambio bajo. Si incorporar funcionalidad se volviese cada vez más costoso, difícilmente podríamos mantener la agilidad.
• Testing automatizado: que permiten tener la mejor velocidad posible, desarrollar en forma sostenible y disponer de una buena documentación del sistema.

Más allá del software, también hay que velar por la excelencia técnica del producto y del negocio, recurriendo a técnicas como la investigación de mercado, el benchmarking, experiencia de usuario (UX), data análisis, gestión de riesgos, etc.

Marcos de trabajo como Scrum y Kanban, son menos prescriptivos y se adaptan a diferentes tipos de proyectos y servicios. En otros marcos más orientados al mundo del desarrollo del software, encontramos prácticas técnicas específicas, como en: eXtreme Programming (XP), Lean Software Development (LSD), Test-Driven Development (TDD), Feature Driven Development (FDD), Agile Unified Process (AUP), Adaptive Software Development (ASD), Crystal Clear, Dynamic Systems Development Method (DSDM), entre otros.

Conocer sus técnicas nos permite enriquecer otros marcos de trabajo, y como les compartí en el artículo Scrum, Kanban, XP ¿Hay uno mejor? ¿Se pueden combinar?, cuando implementamos por ejemplo Scrum en desarrollo de software, es muy recomendable integrar prácticas de la ingeniería como TDD o Pair Programming para asegurar la excelencia técnica.

Déjame saber tu opinión en los comentarios.

Gracias por leerme

Ig: @Soy.Agile.Coach

Scrum, Kanban, XP ¿Hay uno mejor? ¿Se pueden combinar?

Cuando las organizaciones deciden ser ágiles y lean, además de una iniciativa de transformación y gestión del cambio, necesitan decidir cuál, o cuáles, marcos de trabajo ágiles van a implementar en sus equipos de trabajo. Ante las diferentes opciones, quizás se pregunten ¿hay uno mejor?, y la respuesta, como es usual, será depende del contexto.

Los marcos de trabajo ágiles tienen un propósito común: facilitar prácticas basadas en los valores y principios ágiles y lean, en las áreas que precisan de rapidez y flexibilidad, fomentando el aprendizaje, la mejora continua y la capacidad de responder de forma ágil a los cambios del contexto.

Conocer los fundamentos de los marcos ágiles nos permite usar el que mejor ayuda al equipo de trabajo a conseguir productos, proyectos o servicios de alta calidad.

Cabe destacar, que el primer valor del Manifiesto Ágil es "Individuos e interacciones sobre procesos y herramientas", por lo que los métodos ágiles son adaptables, y vamos a encontrar que hay marcos más prescriptivos y otros más adaptativos. Dependiendo del contexto y el propósito de cada equipo, se apreciará el disponer de unas determinadas prácticas.

Por ejemplo, XP (eXtreme Programming) es más restrictivo en comparación con Scrum, dado que incluye las prácticas de Scrum más un conjunto de buenas prácticas específicas de la Ingeniería del Software, tales como Desarrollo Dirigido por Pruebas (TDD) y la Programación en parejas (Pair Programming). Scrum es más restrictivo que Kanban ya que prescribe el uso de iteraciones de duración fija (sprints) y roles, mientras que Kanban no lo hace.

Cada equipo debe ser capaz de seleccionar y/o adaptar un subconjunto adecuado de prácticas para su producto, proyecto o servicio, pero esto será difícil en un inicio, por lo que en agile sugerimos seguir el modelo Shu-Ha-Ri, donde en una primera etapa el equipo aprende y aplica las prácticas de acuerdo a los procedimientos de trabajo establecidos (Shu), en la segunda etapa el equipo, en búsqueda de la mejora continua, va experimentando y adaptando las prácticas iniciales (Ha), y en la tercera etapa, donde el equipo ha madurado la comunicación e interacción, será capaz de crear sus propias prácticas y combinar las propuestas en los distintos marcos ágiles.

Esto nos lleva a reflexionar sobre la segunda pregunta: las prácticas de los diferentes marcos ¿se pueden combinar?, y la respuesta, desde mi opinión, es que Sí, aunque existen ciertos límites.

Hace algún tiempo publiqué un artículo sobre Scrum y Kanban juntos en Agile: Scrumban, desde la perspectiva de un equipo que evoluciona un producto donde se gestionan incidencias, peticiones de soporte y evolutivos.

Más allá de los nombres, me parece más que apropiado, conveniente, integrar prácticas de un marco en otro dominante. Por ejemplo:

· Scrum con Kanban, donde puede incorporarse en el Scrum Board un WiP que ayude al equipo a enfocarse en terminar más rápido las tareas actuales. Scrum.org tiene una certificación de Scrum profesional con Kanban y un conjunto de recursos que incluye una guía de Kanban para equipos Scrum: https://www.scrum.org/resources/suggested-reading-professional-scrum-kanban.

· Kanban con Scrum, donde puedes implementar Dailies que favorezcan la sincronización y colaboración en los miembros del equipo, o decidir priorizar el trabajo de las columnas y tener ciclos periódicos de feedback, tal como lo propone Scrum.

· Scrum con XP, aplicado al desarrollo de software, puede integrar prácticas de la ingeniería cómo Pair Programming para elevar la calidad del código.

Para evitar confusiones, los marcos suelen tener algunas de sus restricciones menos negociables. No podrás llamar Scrum a un método de trabajo sin sprints, ni Kanban a un método que no gestione la eficiencia del flujo de trabajo.

Cabe destacar, que los marcos son medios y no fines en si mismos, y que, en todo caso, son métodos empíricos, por lo que la experimentación y adaptación serán la base de la mejora continua.

Me interesa conocer tu opinión. ¡Muchas gracias!

Ig: @Soy.Agile.Coach


#Scrum, #Kanban, #XP, #Scrumban, #MarcosAgiles, #Agile, #Lean, #AgileCoach, #ScrumMaster, #Empírico, #Experimentación, #Adaptación.