A muchas organizaciones les interesa adoptar Ágil por la habilidad de entregar valor de negocio de forma temprana, incrementar la productividad, realizar entregas más frecuentes y mejorar la moral de los empleados. Hay muchos cursos y libros disponibles que ayudan a los equipos a aprender los fundamentos del desarrollo ágil, pero se suelen enfocar en los desafíos a nivel de equipo, y no tratan muy profundamente los temas organizacionales que pueden ayudar o impedir una transición a esta nueva forma de pensar y trabajar. Este artículo busca mostrar las áreas en donde muchas organizaciones encuentran dificultades para adoptar Ágil, para que puedan estar mejor preparadas al momento de enfrentar el desafio.
Lista de comprobación
Las organizaciones pueden enfrentear distintos desafios en una adopción Ágil, dependiendo del tamaño de la organización y de los procesos que usen. Esta sección lista las dificultades más comunes que una organización puede encontrar en los primeros días de una adopción de desarrollo ágil. Algunos de estos elementos no están relacionados directamente con Ágil; son principios y fundamentos de Ingeniería o de Gestión, que cualquier organización inteligente debería seguir. Más allá de esto, no tratar estos temas podría terminar en frustración durante la adopción ágil.
Esta lista está pensada para verificar qué tan preparados estamos en la organización para enfrentar estos desafios nuevos.
Gestión
1. ¿Tenemos el apoyo de la gerencia?
Entre todos los desafios que enfrenta un equipo durante las primeras etapas de una adopción Ágil, el más importante es ganar la confianza y apoyo de la alta gerencia. Si no existe un compromiso genuino para el cambio de la alta gerencia, es poco probable que tengamos éxito. Debemos ganarnos su confianza y apoyo antes de emprender el viaje. Seamos directos con ellos sobre los problemas que podemos encontrar, y armemos un plan que muestre como pensamos superarlos.
En algunos casos, las gerencias bajas o el personal técnico pueden estar entusiasmadas por "implementar ágil", pero puede existir dudas en la gerencia media. Esto puede deberse a miedo por perder el control de sus equipos, o por no poder diferenciar el desarrollo Ágil de la "anarquía para codificar", o dudas sobre la calidad del producto o la falta de documentación. Necesitamos eliminar todas estas dudas mostrando ejemplos concretos.
¿Qué pasa si nuestro líder no está de acuerdo con nosotros? Igualmente podemos implementar Ágil, pero estaremos solos para enfrentar los desafios.
2. ¿La organización está brindando una capacitación adecuada?
Existen varios programas de capacitación en Scrum, tanto para los desarrolladores, Scrum Masters y Dueños del Producto. Para lograr grandes resultados se necesita que todos comprendan bien las "reglas del juego".
Aunque la capacitación inicial es fundamental, también se necesitan aprender otras habilidades para poder lograr una implementación exitosa. Primero, el desarrollo Ágil hace visible de forma muy rápida todas las deficiencias en los equipos, y su capacidad de crear productos de alta calidad y funcionalidad en el transcurso de una iteración. Muchos equipos necesitan capacitarse para aprender a escribir mejor código y usar buenas prácticas de testing, como ser pruebas automatizadas, técnicas de refactor, o prácticas como Test-Driven Development (TDD). En muchas organizaciones, los miembros del equipo tienen habilidades muy específicas, y les resulta dificil trabajar juntos como parte de un equipo multi-disciplinario; es posible que necesiten de coaching para incorporarse con éxito al equipo. A menudo, la forma más efectiva de capacitar a un equipo en comportamientos multi-disciplinarios es "plantar" en el equipo a uno o más miembros experimentados con esta forma de trabajo.
Otra buena forma para acelerar el aprendizaje es armar un grupo de estudio que se junte periodicamente para discutir distintos aspectos del desarrollo Ágil antes de que empiece la capacitación. Durante este periodo el equipo puede leer artículos de Internet. Estas reuniones pueden ser de mucha ayuda para comenzar más rápido entendiendo estas nuevas prácticas y forma de pensar, y facilitar así la adopción.
Además de las nuevas habilidades técnicas, también se podría necesitar más educación en el dominio del producto. En Ágil, los desarrolladores no son "robots de software" que implementan a ciegas las especificaciones; en cambio, queremos que el equipo sea un aliado del cliente con su esfuerzo de desarrollo, que ayude al Dueño del Producto a maximizar el valor de negocio. Para que esto ocurra, el equipo necesita comprender el contexto de negocio y la tecnología con la que trabajan.
Muchas organizaciones hacen una inversión sólida en capacitación de técnicas Ágiles, pero se olvidan de las habilidades sociales que se necesitan para aprovechar al máximo estas prácticas. Los Scrum Master, los Dueños del Producto, los líderes funcionales y los gerentes deberían recibir capcitación en técnicas de comunicación, técnicas de retrospectivas Ágiles, resolución de conflictos, análisis de causa-raíz, y pensamiento sistémico. Todas estas prácticas serán necesarias para lidiar con la montaña de disfuncionalidades que el desarrollo Ágil sacará a la luz.
3. ¿Se capacitó al Dueño del Producto?
Es clave contar con un Dueño del Producto sólido, ya que es el puente entre el consumidor final, la gerencia y IT. Se necesita tener una comprensión profunda de las responsabilidades del Dueño del Producto, cómo trabajar con los clientes, con el equipo y con los interesados del proyecto para maximizar el ROI, y cómo ser efectivo con las prácticas ágiles.
Cuando se tenga que hacer un desarrollo a gran escala, en general es recomendable que todos los equipos trabajen con un único Backlog del Producto para todo el proyecto, en vez de tener múltiples backlogs específicos a cada equipo; esto ayudará a reducir la duplicación, la redundancia y las direcciones opuestas que a menuda aparecen más tarde en el proyecto.
Para lograr una adopción Ágil exitosa necesitaremos un Dueño del Producto equipado con todas estas habilidades.
4. ¿Hay espacio suficiente?
Los principios Ágiles enfatizan la comunicación cara-a-cara cada vez que es posible. Si los miembros del equipo se sientan en ubicaciones distintas, la dificultad de la comunicación reducirá su efectividad. Es obligatorio reacomodar al equipo para que se sienten juntos y mejoren la comunicación informal con los equipos de Scrum. Debemos ubicar juntos al equipo aunque tengamos que hablar con Recursos Humanos, la gerencia o el CEO.
También necesitamos asegurarnos de tener suficiente espacio libre para reuniones informales alrededor de las computadoras, para demos, para las reuniones diarias, etc. También necesitaremos espacio en las paredes, pizarras y material para escribir.
5. ¿Se tiene en cuenta a todos los equipos de apoyo?
Las organizaciones se esfuerzan por capacitar a los equipos que están por adoptar Scrum. Pero a menudo ignoran la necesidad de familiarizar a los demás equipos de apoyo. Si queremos que el equipo de desarrollo tenga éxito con Scrum, necesitarán el apoyo de los especialistas que les brindan apoyo pero que no son miembros del equipo, como por ejemplo los DBA, administradores de sistemas, o el equipo de Gestión de Configuración. A menos que estos equipos de apoyo conozan la dinámica de un equipo de Scrum, es poco probable que reciban los entregables y se cumplan los compromisos del Sprint.
Debemos invitar al menos a 1 representante de cada departamento a la capacitación de Scrum. De ser posible, estos especialistas deberían formar parte a tiempo completo del equipo de Scrum, o al menos con un rol de consultor.
6. ¿Qué tan rápido escalar?
A menudo, las grandes organizaciones intenta desplegar Scrum de forma simultánea a varias equipos; lo que algunas personas conocen como "Big Bang". Aunque resulta tentador, el riesgo de este enfoque es que las disfuncionalidades sistémicas o de la organización (que afectan a muchos equipos en toda la organización) serán descubiertas a la vez por distintos equipos, y tendrán que resolverse de forma rápida y por muchos equipos a la vez. Esto implica un desafio muy grande y caótico. Puede resultar más facil comenzar Scrum con un número reducido de equipos, intentar distintas soluciones para resolver estas disfuncionalidades básicas, y así poder brindar mejores prácticas a los equipos que continuen con la adopción de Scrum. A medida que la organización va ganando experiencia y confianza en implementar Scrum, más equipos podrán sumarse.
7.¿Hay una estrategia de rotación apropiada?
Esto podría no parecer muy importante en tiempos de crisis económica, pero para las organizaciones que tienen alta rotación de personal puede ser un desafio. A diferencia de los modelos tradicionales, Scrum promueve los equipos de individuos altamente relacionados con competencias básicas y un conjunto de habilidades multi-disciplinarias. Como los equipos de Scrum son pequeños, perder a uno de sus miembros puede ser un problema importante para el equipo. Incluso aunque encontremos rápidamente a un reemplazo equivalente, le tomará algo de tiempo al nuevo miembro tomar velocidad, relacionarse con el equipo y comenzar a entregar valor.
Scrum brinda los beneficios de los equipos, pero también hace más visible los problemas que ocurren cuando se separan o cambian los equipos.
Sería deseable tener un pool de ingenieros disponibles, que puedan sustituir una baja inesperada en un equipo.
8. ¿Pueden los miembros del equipo apreciar el propósito detrás de una historia de usuario?
Un equipo técnicamente competente puede convertir una historia de uusario en tablas en una base de datos, controladores, tags y formularios de forma bastante rápida. Pero algunos equipos tienen dificultades en comprender la motivación o el ROI detrás de las características que están implementando. Para que Ágil sea exitoso resulta crítico que todos los miembros del equipo de desarrollo (desarrolladores, testers, etc.) se "metan en la cabeza del Dueño del Producto" y aprecien la motivación detrás de una historia de usuario. Deben ser capaces de cuestionar el objetivo de las decisiones más importantes y sugerir implementaciones alternativas cuando sea posible.
Sino, corremos el riesgo de terminar con implementaciones técnicamente brillantes que no cumplen los objetivos del negocio.
9. Asignación de módulos a los equipos
Debemos ser muy precavidos si pensamos asignar distintos módulos de software a distintos equipos de Scrum y queremos que este equipo tenga privilegios exclusivos sobre ese módulo. Aunque es una buena idea que equipos individuales de Scrum se encarguen de componentes específicos de software, las cosas se van a complicar mucho cuando tengamos que implementar una historia de usuario que requiera que varios equipos de Scrum trabajen juntos. Todo el trabajo de diseño de interfaces, entregas e integración entre múltiples equipos es un montón de desperdicio.
También, debemos evitar restringir a los equipos a tocar los módulos según su propiedad. La propiedad colectiva de código es un beneficio para todos, que podemos llevar adelante con buenas revisiones de código y políticas de refactor.
Código
10. ¿Qué tan acoplado está el sistema?
Si el código consiste de módulos muy acoplados, y tenemos muchos equipos de Scrum, hay probabilidades de que se estén "pisando" entre ellos continuamente. el problema será mayor si los sprint no están alineados.
De ser posible debemos invertir algo de tiempo en re-organizar la base de código para minimizar las dependencias entre los módulos. Este ejercicio bien vale el esfuerzo porque el código será más modular y menos acoplado, lo que a su vez creará mejores "condiciones del código" para que los equipos de Scrum trabajen, y podrán producir valor de negocio con más velocidad.
11. ¿Hay buenas pruebas unitarias, pruebas automatizadas y cobertura de código?
Una de las características fundamentales de Scrum es la entrega de software potencialmente productivo al final de cada Sprint. Para que esto ocurra es obligatorio automatizar las pruebas. Si no tenemos un conjunto abarcativo de pruebas unitarias automatizadas que estén incoporadas a la construcción del software, vamos a gastar más tiempo del necesario en hacer testing y debug, y será dificil terminar cada Sprint con un sistema probado completamente. Además, las pruebas automatizadas brindan la confianza necesaria para incorporar cambios; el equipo sabrá si algún cambio rompe alguna otra parte del sistema, y será visible de forma inmediata.
Debemos incrementar la solidez del código agregando la mayor cantidad de pruebas unitarias automatizadas como sea posible.Hay que enseñarle a los desarrolladores el arte del Refactor. Las herramientas como Emma, Jester y Cobertura nos ayudarán a medir la cobertura de nuestras pruebas unitarias.
Herramientas
12. ¿Hay buenas herramientas de colaboración?
Este punto es crítico para los equipos geográficamente distribuidos. Ágil necesita de una interacción cercana entre los miembros del equipo, por lo que necesitaremos asegurar que los equipos tengan todo lo necesario para comunicarse de forma efectiva. Las herramienta de video conferencia, teléfonos, emails, mensajería instantánea y Skype las debemos usar lo más posible. VNC, WebEx y Sococo son otras herramientas útiles para la colaboración entre equipos. Si estás pensando en usar una herramienta como Rally, VersionOne o ScrumWorks, debemos asegurarnos que los equipos puedan evalularlas antes de tomar una decisión.
13. ¿Hay un sistema de repliación del repositorio de código?
Este punto es relevante para los equipos geográficamente distribuidos. Nada puede resultar más frustrante que el equipo remoto no pueda acceder al repositorio de código, o resulte muy lento. Debido a los ciclos de entrega más cortos, los equipos necesitarán hacer checkins, checkouts, branches, merging y otras operaciones de forma mucho más seguida que con metodologías tradicionales. Debemos asegurarnos tener una solución de replicación del repositorio que sea rápida y confiable antes de implementar Scrum.
14. ¿Tenemos un sistema de construcción y despliegue completamente automatizado?
Es dificil imaginar una organización moderna de desarrollo de software que no quiera automatizar las actividades de construcción y despliegue. Debemos diseñar nuestro proceso de construcción y despliegue para que se complete en un tiempo corto, por ejemplo, 30 minutos. Esto debería incluir ejecutar los casos de prueba y la certificación de la construcción. Incluso mejor es tener una política de integración continua antes de migrar a Scrum. La integración continua descubrirá los problemas de construcción/integración y ayudará al equipo a identificar y arreglar los problemas más rápido. Cuando los equipos trabajan en iteraciones cortas y fijas, es valioso todo el tiempo que pueda ganarse.
Por otro lado, si necesitamos mucha intervención manual en la construcción y despliegue del produto, la velocidad del equipo se verá afectada.
Otros
15. ¿Hay entornos de desarrollo y testing adecuados?
Si queremos tener entornos dedicados de Desarrollo y QA para equipos individuales de Scrum, vamos a necesitar planificarlos por adelantado. También necesitaremos asegurar que haya suficiente hardware, licencias de software y personal de soporte de IT para crear y mantener estos entornos. Como lleva un tiempo armar el presupuesto, las aprobaciones, las órdenes de compra, la contratación y la capacitación, vamos a necesitar pensar todo esto por adelantado.
16. ¿Hay sistemas de monitoreo de los ambientes y sistemas?
Si estamos trabajando con muchos ambientes y cada uno de estos ambientes tiene múltiples servidores, bases de datos, redes y otros componentes externos, necesitamos tener un sistema robusto de monitoreo en funcionamiento. Zabbix y Hobbit son dos buenas herramientas que se pueden considerar para monitorear la salud de los sistemas.
Conclusión
Debido a las diferencias filosóficas entre las metodologías tradicionales y Ágiles, algunas organizaciones enfrentan desafios y se frustran con los resultados que encuentran con la adopción de Ágil. Muchos de estos desafios pueden superarse de forma efectiva con la preparación adecuada. Este artículo presentó una lista de temas a considerar cuando empecemos una migración de equipos hacia Ágil.
