h1

Becoming Agile: …in an imperfect world

07/05/2012

Wizbook [Icon By Buuf]  Libros.

No es necesario cambiar. La supervivencia no es obligatoria.

W. Edwards Deming (1900 – 1993). Estadístico, profesor, autor y consultor estadounidense, considerado el padre de la Gestión de calidad total.

Hace un par de días terminé de leer Becoming Agile: …in an imperfect world de Greg Smith y Ahmed Sidky. Es una interesante lectura que muestra un paso a la vez, cómo podemos hacer la transición de metodologías tradicionales – o desarrollos sin metodología alguna – hacia ágil. El libro está muy enfocado a Scrum y Extreme Programming, basando sus ejemplos en el caso de estudio integrado por “Acme Media”.

El libro está dividido en ocho secciones, dedicando en la primera los fundamentos de ágil y cómo se llevará el caso de estudio. En los siguientes apartados, el libro muestra poco a poco cómo podemos adoptar una metodología ágil en nuestra organización, empezando por obtener el apoyo de la alta dirección y presentar los criterios de selección de un proyecto piloto; cómo medir la viabilidad del proyecto, planear su ejecución mediante involucramiento temprano del cliente y realizar de forma iterativa pequeñas entregas que incluyan análisis, diseño e implementación de funcionalidad lista para ser liberada en un ambiente productivo. En las últimas secciones se incluyen consejos para mejorar el proceso, con técnicas como las retrospectivas de iteración y de proyecto. El último capítulo proporciona los siguientes pasos a seguir una vez que el piloto haya terminado, incluyendo cómo extender la metodología ágil al resto de la organización.

Disminuyendo el golpe a la productividad

Uno de los capítulos más importantes del libro explica que al experimentar un cambio en los procesos de la organización, siempre tendremos una fase de resistencia e inestabilidad, que después de un periodo de tiempo, desembocará en una mejora paulatina de la productividad gracias a su aceptación, como se muestra en el siguiente diagrama:

Virginia-Satir Change Curve


La curva del cambio, definida por la psicoterapeuta estadounidense Virginia Satir (1916 – 1988). En ésta, se ilustra cómo las iniciativas de cambio implementadas en las organizaciones generan un periodo de resistencia y conflicto, provocando una caída en el desempeño de sus empleados.

El cambio afecta nuestra zona de confort, primero generando un entusiasmo inicial, para más tarde provocar una desilusión, seguida de resistencia y caos que después de un tiempo, finalmente se acepta como parte de nuestra “nueva realidad”. (Fuente: dragile.com)

El mayor riesgo se presenta cuando este periodo de resistencia se prolonga demasiado, debido a que la organización no pudo descubrir a tiempo que no posee los rasgos y características necesarios para implementar exitosamente las prácticas adoptadas. Es importante notar que el impacto ocurrirá invariablemente; por ello, siempre es recomendable realizar una valoración de la capacidad (readiness assessment) para detectar a tiempo las áreas de mayor riesgo al implementar ágil y minimizar en lo posible dicho golpe a la productividad.

A manera de ejemplo, uno de los requisitos de ágil es promover un ambiente colaborativo en el que la comunicación fluya de manera efectiva. Así que deben evaluarse diversas características e indicadores organizacionales que permitan conocer los retos a enfrentar durante la implementación:

• Estilo gerencial: Si existe una relación colaborativa o de comando y control entre los gerentes y sus subordinados. El estilo gerencial es una indicación de que la gerencia confía en sus desarrolladores y viceversa.

• Apoyo de la gerencia: Si la gerencia apoya o se resiste a tener un ambiente colaborativo.

• Distancia al poder: Si la gente se intimida/es temerosa a participar y ser honesta en presencia de sus gerentes.

• Apoyo del equipo de desarrollo: Si los desarrolladores están dispuestos a planear en un ambiente colaborativo.

Después de aplicar un examen de respuesta múltiple que cuantifique el nivel de madurez de la organización, se podría tener el siguiente resultado:

Característica Resultado
Estilo gerencial Parcialmente adecuado (30.5%)
Apoyo de la gerencia Adecuado (72.5%)
Distancia al poder Adecuado (60.5%)
Apoyo del equipo de desarrollo Muy Adecuado (92.5%)

Resultados ilustrando las áreas de oportunidad requeridas para adoptar una planeación colaborativa. (Fuente: Becoming Agile: …in an imperfect world. Smith & Sidky. (Manning, 2009))

La tabla muestra que de adoptar la nueva metodología de forma inmediata, se incurriría en un importante riesgo de provocar reacciones negativas por parte de la gerencia. Así, es recomendable una capacitación previa en liderazgo colaborativo para minimizar el impacto debido al cambio.

El libro posee un apéndice que integra los reactivos para detectar la capacidad de la organización e incluye referencias a un sitio con evaluaciones gratis llamado Dr. Agile. Sin embargo, por el afán de tener un mayor marco de referencia, incluyo otras evaluaciones que me parecen igual de válidas y en algunos casos, un poco más profesionales para identificar dónde hay que concentrar nuestros esfuerzos en acciones preventivas o control de daños durante la transición.

Qué aprendió “Acme Media” después del piloto ágil

El último capítulo también me parece uno de los más importantes, ya que incluye las principales lecciones aprendidas a lo largo del libro y resume cuáles son los retos más comunes a los que se enfrentaría un equipo de desarrollo tradicional al implementar una metodología ágil:

• Aceptar el cambio para entregar valor de cara al cliente. Entregando software de forma iterativa es más fácil adaptarse a nuevos requerimientos. Las reuniones diarias permiten detectar problemas más rápidamente, permitiendo un menor tiempo de respuesta. Mejorando la participación en dichas reuniones, es más factible enfocarse en los objetivos del día y problemas que deben resolverse. Por otro lado, es necesario recordar que la reunión diaria no es el lugar para atacar estos problemas, sino que éstos deberían ser discutidos por un grupo más pequeño al final de la reunión.

• Involucramiento y retroalimentación del cliente. Tradicionalmente, el cliente daría su retroalimentación sólo al final, durante un proceso de aceptación. Con un enfoque iterativo, el cliente puede dar su retroalimentación con cada iteración, refinando ideas y dejando funcionalidad menos critica para ser desarrollada después. Los principales retos a los que puede enfrentarse el equipo son tres: sentirse cómodos mostrando funcionalidad al cliente antes de que esté 100% terminada, mejorar su actitud de cara al cliente cuando se requieran nuevos cambios y obtener retroalimentación cuando terminen funcionalidad interna. Éste último punto es muy importante, ya que mucha funcionalidad se desarrolla no de cara al cliente sino para los administradores o staff de soporte, como herramientas ETL y pantallas de superusuario. Si no existe una retroalimentación correcta, pueden liberarse a producción herramientas administrativas que funcionan a medias y aunque el usuario final no se dará cuenta, sí pueden hacer difícil la vida de aquellos que dan soporte al sistema.

• Planear y entregar software frecuentemente. Con un desarrollo iterativo, el equipo puede esmerarse en funcionalidad crítica para el proyecto, enfocándose en entregar dicha funcionalidad durante las primeras iteraciones. Asimismo, es necesario discutir las prioridades durante todo el ciclo de vida del proyecto. Uno de los retos más complicados, al menos durante las primeras iteraciones, es terminar todo lo comprometido para el día de la demostración. Muchos equipos están tentados a extender la iteración por un día a o dos, pero ésta es una terrible práctica que debe evitarse, pues no podrán estimarse adecuadamente las siguientes iteraciones debido a estos “días extra”; adicionalmente, sentará un precedente que puede volverse cada vez más difícil de controlar.

• Excelencia técnica. Integrada por prácticas que mejoran la eficiencia del desarrollo, como builds diarios, pruebas de concepto, integraciones y pruebas automáticas. Por otro lado, un tema complicado en todo proyecto ágil es el tema de la arquitectura, ya que el equipo puede sentirse angustiado por no tener todas las respuestas desde un principio. Sin embargo, las metodologías ágiles recomiendan lo “mínimo funcional”. Otra alternativa es planear una “Iteración 0” en la que se definan y construyan entregables que no son tan “demostrables” ante un usuario: la arquitectura, la base de datos, los procesos de seguridad o la integración con sistemas externos.

• Prácticas centradas en las personas. Comunicación y colaboración; confianza y sentido de pertenencia; disciplina, participación y resolución de problemas. De eso se trata ágil: trabajar como un equipo y tomar decisiones conjuntamente, confiando los unos en los otros, evitando discusiones improductivas y divisiones que perjudican la entrega de resultados. El tema más importante que hay que atacar dentro de esta categoría es que el equipo de trabajo tome posesión del proyecto y sean autogestionados. Es decir, muchos desarrolladores están acostumbrados a tener un jefe o líder que les indique las tareas por hacer; cuando no existe esta figura de autoridad, se requiere de un mentor o coach que los ayude a tomar la iniciativa para organizarse sin necesidad de un líder explícito; por otro lado, el ambiente debe ser lo suficientemente cordial como para no cuestionar si alguien expresa una opinión o quiere asumir un rol de liderazgo.

Conclusiones

El libro es una lectura obligatoria para aquellos que estén llevando a cabo proyectos de forma tradicional y quieran aventurarse poco a poco en un esquema ágil. Sin embargo, el libro tiene un defecto que vale la pena mencionar: el caso de estudio utiliza sólo dos iteraciones – tres, si incluimos la iteración cero para establecer la arquitectura y el ambiente de trabajo. Esto puede no parecer mucho, pero en la vida real, sólo los proyectos más simples de mes o mes y medio usan dos iteraciones en su haber, y esos proyectos generalmente son tan sencillos que difícilmente requieren de una metodología ágil. El ejemplo del libro puede estar simplificado por razones de aprendizaje, pero mucha gente puede irse con la finta pensando que cualquier tipo de proyecto puede usar metodologías ágiles. Esto es un grave error que generalmente acarrea graves consecuencias.

Dejando de lado este y otros detalles, recomiendo mucho este libro por el contenido expuesto, así como la sencillez con la que explican ciertos conceptos que en otras publicaciones describen de forma muy compleja; algo que para una organización tratando de adoptar ágil puede marcar la diferencia entre mejorar la velocidad de respuesta, productividad y valoración de sus áreas de desarrollo o pasar a ser otro más de esos casos donde implementaron “una de esas iniciativas de calidad” que al final no funcionaron.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: