Llegamos a ustedes gracias a:



Reportajes y análisis

Comparación de marcos ágiles escalables

[11/09/2015] Cuando el Agile Manifesto apareció en el año 2001, combinaba varios métodos, a veces llamados "métodos ligeros", bajo una sola bandera. Scrum, DSDM, ExtremeProgramming (XP) y Crystal eran todos "ágiles" en relación al espíritu del manifiesto. Estos métodos permiten que los equipos pequeños hagan mejor su trabajo, dejando los papeles a un lado e introduciendo al cliente en la conversación.

El enfoque en "pequeños equipos" funcionó para pequeños equipos. Hoy en día, las grandes organizaciones también quieren avanzar hacia métodos más ágiles. Los métodos en los que están interesados amplían las metodologías originales para incluir grandes equipos, coordinación y supervisión. También introducen riesgos; un experimento que va mal para todo el departamento de TI es mucho más peligroso que para un equipo que experimenta durante unos meses.

La mayoría de las grandes organizaciones se comprometen a un marco de desarrollo de software único. Las empresas que no lo hacen -las que tratan de escoger y elegir las mejores piezas de cada uno- todavía quieren crear una única visión. De cualquier manera, tomar las decisiones correctas requiere la comprensión de todo, sus puntos fuertes y débiles, cuándo y cómo tienen sentido.

Así que vamos a hablar de ellos.

¿Qué queda de Scrum y XP?

Los equipos ejecutan un proyecto a la vez (por lo menos, esperamos que lo hagan). Las organizaciones ejecutan programas -combinaciones de varios proyectos que pueden superponerse. Los proyectos más grandes son construidos por los equipos de los equipos, o equipos de equipos de equipos, que pueden funcionar en diferentes ubicaciones físicas. Este tipo de trabajo requiere de coordinación. Las organizaciones más grandes por lo general quieren un acoplamiento flexible -dándoles a los equipos la libertad de innovar mientras crean solo suficientes expectativas compartidas para hacer más fácil la coordinación cruzada entre equipos. Manejar los avances del trabajo en progreso, el trabajo planificado y la programación de cuando se inician y detienen los proyectos se vuelve mucho más complejo.

Entonces existe el problema legado de cambiar a un enfoque ágil. Un alto directivo de una cadena de hoteles de Fortune 500 describió su proceso de despliegue como "una docena de personas en una llamada de conferencia, dando de baja sistemas y haciendo copias de seguridad nuevamente, durante un período de cinco horas".

Scrum, XP, Crystal y las otras metodologías de desarrollo de la primera generación no proporcionan una respuesta a estas preguntas. Vamos a explorar cómo los nuevos métodos abordan estas necesidades.

SaFE

La popularidad del Scaled Agile Framework (SaFE) de Dean Leffinwell hace que la capacitación o las consultas sean más fáciles. Hay muchos artículos, tutoriales y videos en línea, y el proceso de certificación es claro y bastante maduro. Relativamente fácil para que las organizaciones migren a él, SaFE también es prescriptivo -le dice a las organizaciones exactamente lo que se debe hacer. Un gerente de programa de una compañía Fortune 500, comentó anónimamente que sin entender las ventajas de cada pieza de SaFE, la alta gerencia tiende a adoptar todo, incluyendo el trabajo en equipo, el trabajo del programa, "epopeyas de negocios", "epopeyas técnicas", métricas en cada nivel y una serie de otros requisitos. Todas esas piezas extra realmente pueden añadir complejidad a la organización, lo cual va en contra de los objetivos de la adopción ágil.

LeSS

Large Scale Scrum (LeSS) literalmente escala las actividades en scrum, aplicándolas al nivel de "equipo de los equipos. En LeSS, la planificación a gran escala toma a uno o dos miembros de cada equipo para formar una segunda reunión; hay un levantamiento diario que hace lo mismo que el scrum diario. La "retrospectiva global", que ocurre una semana después de finalizar una carrera, del mismo modo jala representantes de cada equipo para discutir cuestiones programáticas importantes. Por encima de todo esto, LeSS también añade espacio abierto, reuniones comunitarias y otras actividades de coordinación y comunicación.

Las reglas formales de LeSS, de dos a ocho equipos encajan en la parte frontal y posterior de una página; la versión para equipos de producto de hasta un millar de personas, LeSS Huge, no es mucho más grande. Craig Larman, co-creador de LeSS, afirma que las grandes organizaciones añaden una complejidad innecesaria a través de grupos de una sola función, transferencias y una débil o lenta retroalimentación. "En lugar de introducir un método que añade un curita en la parte superior... tratamos de cambiar el diseño de la organización para crear equipos de características polivalentes. Estas ideas están en contradicción con cómo las organizaciones se instalan generalmente.

DaD

Mientras scrum asume un equipo que está en vuelo, no incluye dónde comenzó el equipo, o cómo hacer decisiones "Sprint cero", como la plataforma de tecnología de base, el lenguaje de programación y la arquitectura. Ahí es donde Disciplined Agile Delivery (DAD), el marco de Scott Ambler, comienza, incluyendo el inicio del proyecto, la formación de la arquitectura y el equipo, y el final -la producción, el uso operacional y soporte. Donde "Scrum" tiende a asumir que existe un equipo en modo de mantenimiento, DaD no, dando tiempo al equipo para decidir sobre la plataforma, construir herramientas, programar el proyecto y otros desafíos que ocurren más para el desarrollo de productos y menos para los esfuerzos de mantenimiento.

LeadingAgile

Con sede en Atlanta, LeadingAgile, fue fundada en el 2010 y desarrolló rápidamente una reputación internacional como una empresa que ofrece servicios de consultoría a nivel ejecutivo en las transformaciones ágiles a gran escala. En lugar de un "marco escalable", LeadingAgile ofrece un "marco de transformación" que se inicia mediante la evaluación de las metas de planificación de la empresa en relación con la previsibilidad o adaptabilidad. Esta metodología también pregunta si se espera que la funcionalidad del producto Emerja (descubrimiento basado en las necesidades del mercado) o Converja (entrega de requisitos y características a intervalos predeterminados).

A continuación, LeadingAgile ofrece una guía para mejorar la entrega en base a lo que está impulsando el negocio actualmente, mientras establece una base para lograr que la organización de TI esté donde tiene que estar para darle soporte al negocio en el futuro. La empresa organiza grupos de equipos en "expediciones", que se mueven progresivamente a través de "basecamps" o campamentos, desarrollando las habilidades necesarias para mejorar los resultados de negocio a través del tiempo. El CEO, Mike Cottmeyer, llama a esto una "hoja de ruta de la transformación", porque LeadingAgile se centra en la alineación de objetivos, la creación de la transparencia y la mejora del rendimiento del negocio sobre la implementación de modelos abstractos y reglas.

Alternativas a los marcos "grandes"

Después de los tres mencionados y el trabajo de LeadingAgile están una serie de marcos y métodos de escala más pequeños. Scrum de Sam Laing se apoya en Motion (Slim), por ejemplo, y está diseñado para complementar LeSS. Este autor es el creador de la Cultura Sostenible Agile en la empresa (SCARE), que aplica la teoría de las restricciones a la adopción ágil y se basa en los patrones que han surgido de proyectos de escala exitosos. FAST Agile de Ron Quartel, recientemente anunciado en la conferencia Agile Roots, se centra en la mejora de la velocidad de integración de los grupos grandes (y la reducción de residuos) a través de reuniones casi continuas de espacios abiertos para la planificación.

Si pudiera pensar en la gestión de una gran organización de TI como una cartera de trabajo, como una especie de escala, entonces otra opción a considerar es la obra de Johanna Rothman en The Project Portfolio, y Program Management.

Lo que le falta a los marcos de escala

Adam Yuret, consultor en gestión de cartera y estrategia, señala que los marcos de escala no pueden impedir que un alto ejecutivo pase por alto las especificaciones y las listas de errores. Y agrega que "no solo no es el mejor uso de su tiempo, sino que cuando se tiene como ejemplo, se lleva a mandos intermedios haciendo lo mismo, lo que finalmente termina con los programadores recibiendo indicaciones erróneas por parte de varias personas. La solución de Yuret no es un marco, sino una implementación de estrategia, donde el liderazgo comunica sus claras intenciones, por lo tanto confía en los equipos para que puedan cumplirla por más que lo consideren necesario.

Algunos otros líderes, incluyendo Arlo Belshee, Matt Barcomb y Alistair Cockburn, han llegado a proponer alternativas a la idea de "marco de escala".

De todos modos ¿Quién necesita un marco de escala?

En el 2008, Arlo Belshee ganó el premio Godon Pask, el premio oficial de Agile Alliance para las contribuciones a la práctica. Después de ganar el Premio Pask, Belshee pasó a un puesto de entrenador/profesor en Microsoft. Esa experiencia, que se informó en una entrada de su blog en el 2013, 'Escala ágil, la forma fácil', en el que Belshee afirma que las objeciones de escala tienen su revés; que cuando las empresas desarrollan verdaderos equipos multidisciplinarios que pueden armar software regularmente, los problemas desaparecen. Como Belshee explica, esto es lo que sucede una vez que los equipos tienen esa competencia:

"No habrá dependencias técnicas entre sus equipos. Cada equipo será capaz de entregarle valor al cliente. Los equipos no causarán problemas cuando integren código entre sí. Ninguno de los productos tendrá errores (bueno, no por más de una hora cada dos semanas). Los equipos pueden trabajar juntos con el fin de proporcionar soluciones que mejoren el uno al otro. Los equipos también pueden ofrecer un valor empresarial sin coordinar con cualquier otro equipo".

Belshee no está solo.

Matt Barcomb, un capacitador independiente de Agile y ex vicepresidente de desarrollo de productos para Taxware, señala que si bien el problema de la "escala" suena duro, por lo general significa una de tres cosas: la difusión, coordinación o alineación. Como explica Barcomb, lo que pensamos como los grandes problemas de la organización son, en realidad, bastante fáciles de entender:

"Ellos están teniendo cierto éxito en un área y necesitan más equipos para tener éxito (difusión); o tienen un problema con el proyecto multiequipo (coordinación), que está dirigido por los conceptos de los libros de Rothman o por el portafolio kanban y basados en hojas de ruta, o bien la alta dirección se siente frustrada porque los equipos a cargo de mandos medios no parecen estar recibiendo tracción en las metas/indicadores clave de rendimiento que quieren (alineación). Por lo general introducen más controles, procesos más detallados y más medidas ["marcos"] que por lo general resultan en exactamente lo contrario".

El enfoque de Barcomb, como el de LeadingAgile, es identificar dónde está la brecha y trabajar en eso, haciendo pequeñas mejoras a la habilidad y a la cultura a lo largo del camino.

Por último, tenemos a Alistair Cockburn, quien organizó la Conferencia Snowbird que creó el Manifiesto Ágil, y fue conocido como uno de los principales pensadores sobre el tema antes y después de esa conferencia.

Aunque inicialmente vaciló cuando se aproximó a la expansión de marcos ágiles, Cockburn pasó a hablar de algo que él llamó el "Corazón de Agile". En pocas palabras, a nivel de empresa, el corazón de Agile hace estas preguntas:

1. Independientemente de todo lo demás, ¿Cómo va a aumentar la colaboración?

2. Contando todo lo demás, ¿Cómo puede aumentar el juicio y las entregas reales a los consumidores?

3. ¿Cómo hará para que la gente haga una pausa y reflexione sobre lo que está sucediendo a su alrededor?

4. ¿Cuáles son algunos experimentos que hará su gente en diferentes niveles de la organización para hacer una pequeña mejora?

Estas preguntas están diseñadas para ayudar a que una organización decida qué cambios pequeños hacer en su búsqueda de agilidad, y asegurar el cambio en el contexto de esta organización y este momento, en lugar de confiar en la sabiduría de alguien. En resumen, se centran en responder al cambio en lugar de seguir un plan.

Posteriormente Cockburn elaboró en su blog con un post titulado 'Uso del corazón de Agile en el problema de la escala'.

En resumen

El marco dominante, SaFE, ofrece una manera para que un grupo grande de TI se organice a sí mismo como equipos de equipos de equipos ágiles. LeSS hace lo mismo, centrándose en la mejora de la comunicación entre los equipos. Belshee sugiere comenzar haciendo equipos Agile de alto funcionamiento que puede entregar software que funcione bajo demanda, y los problemas de escala desaparecen, mientras que los otros consultores tienden a recomendar pequeños cambios para que una organización se adapte hacia un Agile ideal.

Una vez que pasamos de la "escala" al problema real que su empresa está interesada en resolver, luego una de estas soluciones podría tener más sentido que las otras.