¿Están preparados? Aquí está el secreto... para ser ágil deben... ¡romper todas las dependencias a cualquier costo!
Las depedencias se crean cuando dos elementos discritos dentro de la organización se necesitan mutuamente para hacer parte (o todo) de su trabajo. Las dependencias están por todos lados a nivel organizacional. Son creadas por la forma en la que estructuramos el negocio y cómo preaparamos y ejecutamos el trabajo de nuestros proyectos. Esto hace que sea muy dificil identificarlas, y más dificil todavía eliminarlas.
Creo que romper con nuestra dependencia en las dependencias es el desafio esencial para lograr orquestrar una transición ágil sustentable.
Las transiciones ágiles no falla porque Scrum sea insuficiente. No fallan porque la gente no aplica las prácticas de XP correctas. Nuestro problema no es una malinterpretación fundamental del Manifiesto Ágil, ni la resistencia a convertirnos en buenos líderes ágiles.
Aunque algunas organizaciones puedan tener algunos o todos estos problemas, no deben ser nuestra principal preocupación.
El tema de fondo es que los principios de gestión de proyectos ágiles, las prácticas de ingeniería ágil, y la filosofía de liderazgo ágil todas presuponen que hemos logrado eliminar las dependencias. La mayoría de los equipos intentan volverse ágiles sin validar esta presunción básica, que de hecho nadie les dijo que debían comprobar!
Cómo describimos una implementación ágil ideal...
Primero, comenzamos con un equipo chico de miembros multi-funcionales con suficientes habilidades de manera que cualquiera pueda trabajar en cualquier parte del sistema. Luego hacemos que este equipo sólo trabaje en un único proyecto a través de los sprint.
Después le asignamos al equipo un Dueño del Producto dedicado que tiene el poder de tomar decisiones en nombre de la empresa. Le permitimos trabajar en requerimientos funcionales pequeños e independientes que pueden ser repriorizados en cualquier momento.
Le damos al equipo un miembro con poder de remover cualquier problema organizacional que el equipo encuentre, el Scrum Master. Quitamos todos los escollos del proceso y les permitimos trabajar de la manera que quieran siempre y cuando entreguen software que funcione.
Por último, asumimos que se tiene una arquitectura orientada a objetos que admite un diseño guiado por pruebas, integración continua y refactor constante.
Este escenario describe un equipo sin dependencias. Tiene el 100% de lo que necesitan para realizar su trabajo.
Y lo que enfrentan muchos equipos al adoptar ágil...
Las personas usualmente forman parte de un equipo de especialistas que se los ubica en proyectos de equipo multi-funcionales. Como estas personas son especialistas, no se necesita de sus servicios el 100% del tiempo. Para maximizar la utilización individual se los asigna a varios proyectos en varios equipos.
Los Dueños de Producto están en investigaciones de mercado, en reuniones con clientes y asistiendo a conferencias. A los equipos se los deja con un analista de negocio con poco poder para tomar decisiones en nombre del negocio. Y en realidad, el Dueño de Producto es tan solo un proxy de un grupo mucho más grande de usuarios que no se involucran de todas formas. Nadie tiene acceso a datos de cliente o de mercado reales.
Muchos equipos intentan avanzar en los sprint del desarrollo del producto usando Documentos de Requerimientos de Marketing (MRD) o Documentos de Requerimientos de Proyecto (PRD). No utilizan requerimientos escritos como hilos funcionales o con comportamientos de sistema que puedan ser probados de forma completa al final del sprint. Estos requerimientos no pueden ser repriorizados a medida que vamos aprendiendo del sistema en creación.
Muchos equipos trabajan con líderes de proyecto tradicionales quienes hacen su mejor esfuerzo para ser ágiles, pero que fueron capacitados para gestionar dependencias y decirle a la gente qué hacer. Aunque quieran ser ágiles, no suelen tener el poder de hacer nada sobre los impedimientos reales con los que se encuentra el equipo.
Los equipos intentan ser ágiles con arquitecturas fuertemente acopladas, cobertura de pruebas insuficiente, bases de código legado, y sin posiblidad de construir diariamente.
Este escenario describe perfectamente a un equipo que opera bajo el peso aplastante de las dependencias creadas por suposiciones organizacionales incorrectas.
Suposiciones que llevan a dependencias innecesarias
Suponemos que debemos optimizar el rendimiento individual y por lo tanto ubicamos a los miembros del equipo en varios proyectos. Esto genera dependencias entre los proyectos que no tenían porqué existir. Nos encontramos gestionando quién está en cuál proyecto, y cuándo va a estar disponible para otros proyectos. Creamos una red de dependencias (entre proyectos) que restringe nuestra habilidad para cambiar el curso de la acción. Cualquier cambio provoca una cascada de impactos dolorosos en nuestro portfolio.
Suponemos que algunas partes de la solución son demasiado complicadas, y por lo tanto deben ser manejadas por especialistas. Elegimos asignar a ciertas personas a componentes específicos. Creamos entonces dependencias entre los productos que usan estos mismos componentes. También creamos dependencias entre los requerimientos que impactan en el mismo componente. Creamos dependencias de proyectos entre los equipos (y entre los miembros de los equipos) cuando tenemos a estos especialistas asignados a un equipo de especialistas.
Suponemos que nuestros Dueños de Producto están demasiado ocupados para atender al equipo, por lo tanto asignamos a alguien más como proxy del negocio. Creamos dependencias entre el equipo y el negocio que resulta en una tendencia en sobre-documentar y gestionar las relaciones etre los contratos. Cuando se usan contratos creamos dependencias entre el equipo y el negocio que se deben mantener, aplicar y poner bajo una gestión de cambios.
Suponemos que el mercado demanda todas las características a la vez, por lo que no nos enfocamos en porciones funcionales pequeñas a lo largo de toda la arquitectura del sistema. ¿Para que molestarse, si tiene que hacerse todo igualmente? Esta forma de pensar nos lleva a considerar todo antes de que podamos construir nada. Cuando los requerimientos dependen todos entre si, no hay necesidad de priorizar, no hay oportunidad de cambiar nuestra forma de pensar, ni oportunidad de aprender del sistema emergente. Y este documento de gran diseño completo inicial comienza a parecer bastante razonable.
Suponemos que la arquitectura no puede desacoplarse, o que las pruebas de cobertura son muy costosas. Esto nos lleva a pensar en todos los cambios cuando estamos haciendo cualquier cambio. Los cambios acumulados se van haciendo fuera del contexto del software que funciona. Luego los cambios se integran y prueban todos juntos... seguramente cerca del final del proyecto. Al crear dependencias entre los cambios en el código perdemos la capacidad de aprender de nuestros errores, del refactor, y de hacer a los equipos responsables de los resultados.
Las dependencias nos fuerzan a medir las horas trabajadas, o los módulos entregados, o las líneas de código, cuando en realidad lo que queremos medir es al software funcionando.
¿Por qué importa todo esto?
Algunas de estas dependencias son reales. Puede llevar años superar varias. Lo importante es darse cuenta que cada dependencia que aceptamos, cada dependencia que dejamos en su lugar, va a limitar nuestra habilidad de adoptar métodos ágiles.
Cada dependencia nos va a restar efectividad y capacidad para responder a los cambios.
Si nos enfocamos en técnicas de gestión de proyectos, prácticas de desarrollo, o incluso filosofía de liderazgo... vamos a perder el foco. Estamos acostumbrados a elegir de una bolsa de tácticas y seleccionar lo que pueda funcionar para una organización en particular. Nada nos fuerza a enfrentarnos al problema de fondo, y por lo tanto elegimos nuestro camino hacia una implementación ágil sin sentido, una que no va a entregar el valor esencial que la organización quiere entregar.
Si nos enfocamos en una persecusión y eliminación de las dependencias, vamos a posicionar a la organización para que potencialmente pueda adoptar TODAS las mejores prácticas ágiles. Luego podremos seleccionar las prácticas de acuerdo a nuestros valores y principios, y no en las restricciones de nuestra organización llena de dependencias mezcladas.
Reducir las dependencias a cualquier costo. Este va a ser mi mantra para el 2009.
