Nuestro compañero Roberto trabaja en ALTEN desde 2005. Actualmente, ocupa el puesto de jefe de proyecto en el área de desarrollo del Ministerio de Industria y además, es el responsable de la Oficina de Mejora Continua dentro del Ministerio. Gracias a su posición, ha podido poner en práctica metodologías Ágiles, la cual le ha reportado unos muy buenos resultados. Tanto es así, que asistió como ponente a “AGILE19”, un congreso organizado por itSMF España y la Universidad Politécnica de Madrid. Nos cuenta más sobre esta metodología y su desarrollo en ALTEN en la siguiente entrevista:
P: ¿Cómo ha sido tu trayectoria en ALTEN? ¿En qué proyecto colaboras actualmente?
R: Comencé como jefe de proyecto en un equipo de un área de desarrollo del Ministerio de Industria. Con el paso del tiempo, he colaborado, además de en mis labores habituales de dirección de proyectos, con la elaboración de ofertas técnicas, tanto para este cliente como para otras administraciones públicas. Por otra parte, he puesto en marcha, dentro del mismo cliente, la Oficina de Mejora Continua, la cual está destinada a impulsar buenas prácticas de desarrollo del software para ayudar a la mejora de la productividad de los equipos. Actualmente, en esta oficina, trabajamos cuatro consultores de ALTEN, ofreciendo un servicio de valor añadido altamente reconocido.
P: Habéis implementado metodologías ágiles en vuestra actividad, ¿en qué consiste?
R: Yo, personalmente, comencé a utilizar en 2011 el método Lean Kanban (el cual entra dentro del paraguas metodológico Agile/Lean) en mi equipo de desarrollo de software, dentro del Ministerio. Posteriormente, dado los buenos resultados obtenidos, se creó la Oficina de Mejora Continua, la cual le fue encomendada a ALTEN. Esta oficina se encarga de la implantación de metodologías Agiles (principalmente Kanban y Scrum), DevOps y otras buenas prácticas de ingeniería dentro del ámbito del desarrollo software.
P: ¿Qué diferencia su implementación en un Ministerio a hacerlo en cualquier otra empresa o entidad privada?
R: El principal reto de la implantación de metodologías ágiles en un Ministerio proviene del escalado de la iniciativa, como en cualquier otra organización de tamaño similar. Ahora bien, en un Ministerio existen otros desafíos adicionales, principalmente la contratación ya que, al estar sujetos a la Ley de Contratos del Sector Público, tienen unas rigideces extra que no existen en otros sectores. Debemos tener en cuenta que las metodologías agiles apuestan por ofrecer máxima flexibilidad ante el cambio, especialmente en el alcance dentro de los proyectos, algo que no encaja del todo bien con los requerimientos de los contratos de la Administración. Otro de los aspectos a combatir es la combinación de diferentes consultoras trabajando para un mismo cliente, ya que muchas de las prácticas y dinámicas que se plantean requieren de formación adicional en los equipos de desarrollo y, por tanto, de un esfuerzo extra de coordinación con las diferentes consultoras.
P: ¿Cómo surgen las metodologías ágiles, desde cuándo se empieza a aplicar?
R: El termino Lean fue referenciado por primera vez a principios de la década de los noventa en “ The Machine That Changed the World: The Story of Lean Production (Womack et al., 1990)”, se convirtió en la forma occidental de llamar al Toyota Production System (TPS), que fue posteriormente adaptado para su aplicación al desarrollo de software en el movimiento que actualmente se denomina Lean Software Development . Aunque ofrecer una única definición para hablar del pensamiento Lean aplicado al desarrollo del software es complicado, sí es cierto que existen dos enfoques principales a la hora de aplicar los principios Lean en este sector:
- Aquellos que se basan en la eliminación del desperdicio “Implementing Lean Software Development: from concept to cash (Mary and Tom Poppendieck, 2006)”
- Los que se apoyan en el concepto de flujo “The Principes of Product Development Flow (Reinertsen, 2009)”.
El método Lean Kanban propuesto por David J. Anderson en “ Kanban: Successful Evolutionary Change for Your Technology Business ” es una técnica que pertenece al segundo enfoque y está basado en la filosofía “Just in Time”, que consiste en producir los elementos que se necesitan, en las cantidades que se necesitan, en el momento que se necesitan. El método fue aplicado por primera vez en un pequeño equipo de servicio de mantenimiento de software, el cual trabajaba para aplicaciones internas de Microsoft, y presentado en una conferencia internacional sobre Theory of Constraints: “ From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution in Microsoft’s IT Department (Anderson y Dumitriu, 200 5)”.
P: ¿Qué ventajas ofrece?
R: Antes de afrontar un proyecto o llevar a cabo un importante cambio en cualquier organización, es importante plantearnos por qué nos interesa afrontarlo y qué esperamos conseguir tras realizarlo. Este mismo razonamiento es el que debes aplicar si estás planteándote cambiar la forma de trabajo de un departamento de desarrollo para adoptar prácticas Agile. Definir qué pretendes obtener en su aplicación es de vital importancia, puesto que una u otra práctica tienen “prescripciones” diferentes y, por tanto, te llevarán a distintas metas. De forma muy resumida, podemos enumerar las siguientes ventajas en la aplicación del método:
1. Optimizar el proceso existente
De todas, esta es la principal, puesto que si se decide afrontar el esfuerzo de cambiar la forma de trabajar de un equipo es porque interesa optimizar esta forma de trabajo. El método Lean Kanban es un agente facilitador que te permite mejorar gradualmente tu proceso, sin cambios disruptivos en la forma de trabajar del equipo ni duros procesos de reingeniería (algo que normalmente genera rechazo).
2. Entregar con Alta Calidad
Kanban permite establecer claros criterios de calidad como políticas definidas del tablero. No es algo que se deba realizar en la primera semana de aplicación, pero gradualmente se pueden incluir esas políticas que “obliguen” a todos los miembros del equipo a implantar técnicas que redunden en la calidad del producto.
3. Mejorar la predictibilidad de nuestros tiempos de entrega
El mero hecho de limitar el trabajo en curso (WIP) acorta los tiempos medios de entrega. Pero, si además de limitar el trabajo se reducen suficientemente bien los tamaños de estos trabajos, se dispone de una estimación razonable del esfuerzo de desarrollo y un vistazo a la situación del tablero y a los tiempos medios de entrega (Lead Time) y de ingeniería (Cycle Time), podremos predecir un rango de entrega suficientemente razonable.
4. Mejorar la satisfacción del equipo
Si el equipo está muy acostumbrado al estrés, a las prisas, a los cambios de foco, notará que el sólo hecho de limitar el trabajo y definir una serie de medidas objetivas de rendimiento mejora notablemente su satisfacción.
5. Generar “tiempo-libre” para posibilitar la innovación
La definición de diferentes políticas, la limitación del trabajo en curso y la gestión de los cuellos de botella pueden generar tiempos “ociosos” en los miembros de tu equipo. Aprovechar este tiempo libre individual puede ser altamente beneficioso para el equipo y la organización en su conjunto si se reorienta adecuadamente.
6. Simplificar la priorización de los trabajos
La fácil visualización del trabajo, las políticas establecidas en cuanto a los límites del trabajo en curso y la clasificación de los distintos tipos de tareas nos permitirá, atendiendo a los datos históricos de rendimiento del equipo, priorizar los trabajos de forma prácticamente automática. Si los objetivos y políticas están bien definidos, esta priorización puede ser incluso delegada al propio equipo.
7. Proporcionar transparencia sobre el proceso y su funcionamiento
Si el método tiene un desempeño correcto, tanto el equipo de desarrollo como el resto de agentes que se relacionan con él (gerencia, operaciones u otros equipos de desarrollo), comprenderán el resultado de sus acciones y evitarán interferir en el buen funcionamiento de la “cadena de montaje”, que a su vez es parte de un engranaje mayor (el resto de cadena de valor de la organización) y se verá beneficiada en su conjunto. La gerencia será más consciente de que añadir un trabajo extra al equipo implica superar sus límites de trabajo (demostrados con el tiempo como eficientes) y se cuidará de hacerlo sin un buen motivo, manteniendo al equipo dentro de su foco. Otro equipo de desarrollo y operaciones verá fácilmente las implicaciones que el retraso de alguna de sus tareas conlleva a otro equipo al observar los bloqueos existentes. Por ello, solucionar estos conflictos debe ser prioritario entre las tareas de una gerencia efectiva.
8. Creación de una cultura de mejora continua
La visualización del proceso y la constante revisión de indicadores, políticas y prácticas, unido con el poder que se le debe dar al equipo para definir y modificar su propio proceso, hace que comience a emerger la idea de una cultura de mejora continua. El equipo ya no sólo se preocupa de completar tareas para desarrollar nuevos productos o mantener los existentes, sino que se replantean continuamente cómo podrían hacerlo mejor la próxima semana: ¿cambiando el límite de la columna de aceptación? ¿añadiendo una de revisión de código? ¿automatizando el proceso de despliegue? ¿reduciendo el tamaño de las tareas? Pequeños pero continuos cambios que permitan “afinar” el proceso.
P: ¿Qué cambios crees que supone los métodos Ágiles en la consecución de objetivos?
R: El principal cambio es justamente la adaptación al cambio. En el entorno actual, la definición de unos objetivos fijos e inamovibles al comienzo de un proyecto es inviable. La dirección de proyectos clásica, promovida por el Project Management Institute , espera que el director de proyectos evite la “corrupción del alcance”, como uno de los principales males a evitar dentro de nuestro proyecto. Es decir, una vez definidos los objetivos o alcance del proyecto, el director de debe velar porque dicho alcance no se modifique durante la ejecución del proyecto. Después de 50 años del nacimiento de la ingeniería del software, podemos decir que, en nuestros proyectos de desarrollo del software, este enfoque no funciona. El responsable del proyecto debe enfocarse en la entrega de valor, de forma frecuente y temprana durante la ejecución del proyecto, sin importar que el alcance se vea comprometido. Las metodologías ágiles facilitan los cambios en lugar de combatirlos.
P: ¿Cuál crees que es el mayor reto a la hora de implementar esta nueva estructura de trabajo?
Probablemente, el lógico rechazo al cambio, que es algo innato a la naturaleza humana. Ahora bien, el método Lean Kanban ofrece una ventaja incluso frente a otras metodologías Agiles y es que toda iniciativa Kanban arranca de la situación actual de equipo y no obliga a introducir cambios organizativos ni técnicos. Si la comparamos con Scrum (la que actualmente es la metodología Agile más implantada a nivel mundial) vemos que surgen una serie de roles (Product Owner y Scrum Master) que no existen en las organizaciones, lo que obliga a formar al personal en dichas funciones o a incorporar estos perfiles, así como una serie de dinámicas y reuniones que no se realizaban anteriormente. Kanban, sin embargo, no realiza ningún cambio, sino que parte de la situación actual de roles y organización del trabajo y, a través de la aplicación gradual del método, facilita el cambio y la mejora continua.
P: ¿Se trata de una metodología aplicable a cualquier campo o proyecto?
R: Sí, claramente el método Lean Kanban se puede aplicar a otros escenarios diferentes al desarrollo del software. De hecho, es un marco de trabajo que nosotros hemos adaptado de la industria automovilística. Además, en este mismo cliente, nosotros lo estamos utilizando en diferentes campos: desarrollo del software, gestión de las operaciones IT e incluso para la gestión del área de contratación interna del Ministerio. A su vez, se han hecho pilotos dentro de la Subdirección de Recursos Humanos y algunas otras subdirecciones sectoriales.
P: ¿Cómo afecta al entorno laboral? Es decir, ¿cambia la relación entre los trabajadores?
R: Obviamente el hecho de aplicar nuevos métodos de trabajo requiere de cierta formación, para que los todos los implicados en el desarrollo conozcan y apliquen determinadas normas. Ahora bien, como he comentado antes, la aplicación del método no es disruptiva, sino que busca la aplicación de cambios graduales, lo que, habitualmente genera poco rechazo. Nosotros, en la aplicación de nuestras iniciativas, solemos partir de unas jornadas de formación que no suelen superar las cuatro horas y, posteriormente, un acompañamiento durante varias semanas para ir asentando las bases del método y guiando al equipo en la adopción de las buenas prácticas.
P: ¿En qué punto nos encontramos del desarrollo de las metodologías Ágiles y cómo crees que será su evolución?
R: El Manifiesto para el desarrollo Agile de Software se firmó en 2001, por lo que recientemente ha superado su mayoría de edad. Lo cierto es que, si bien en los primeros 10 años existió gran controversia entre aquellos que estaban a favor o en contra, en la actualidad ya no existe un debate sobre la conveniencia o no del desarrollo Agile, por el contrario, existe un gran consenso de que es una forma más eficiente de desarrollar software. Esto lo podemos ver fácilmente en el mercado laboral actual, puesto que es muy habitual encontrar ofertas para puestos de Scrum Masters o Product Owners que necesitan perfiles claramente asociados al desarrollo Agile.
Ahora bien, sigue existiendo terreno para la evolución, no olvidemos que la ingeniería del software como disciplina tiene 50 años y el desarrollo de metodologías Ágiles apenas 18, tenemos que seguir investigando y mejorando nuestras técnicas, al igual que hicieron otras ingenierías clásicas durante siglos. Temas como el escalado de la agilidad en grandes organizaciones, la problemática de la contratación Agile o la expansión de la agilidad más allá del departamento de desarrollo (DevOps) tienen que seguir mejorándose.
P: ¿En qué consistió “AGILE19”?
R: Es un congreso organizado por itSMF España y la Universidad Politécnica de Madrid que busca difundir experiencias de la mano de profesionales y empresas para conocer cómo están viviendo este proceso de transformación, cómo están adaptando sus organizaciones a nuevos paradigmas y marcos de valores, qué beneficios están obteniendo o cuales son los retos que se están encontrando.
La temática y ponencias de AGILE19 estaban enfocadas en:
- “X as service (Lean)”
- Calidad del Software
- Agile fuera de IT
- Casos de éxito en Agile
P: ¿Cómo valoras la experiencia?
R: Fue una experiencia muy positiva, me permitió conocer de primera mano cómo otros grandes profesionales de nuestro sector están lidiando con problemas que a todos nos preocupan a diario. Si tuviera que quedarme con alguna experiencia en concreto sería la charla “ Pairing en liderazgo ”, presentada por la directora de ThoughtWorks en España, empresa referente a nivel mundial que toda persona dedicada al desarrollo del software debería conocer. En esta charla conocimos cómo ThoughtWorks ha extendido exitosamente la práctica de “ pair programming ” a la gestión, y nos explicaba cómo en cada país en que opera ThoughtWorks existen dos codirectores que tienen un liderazgo compartido y colaboran conjuntamente en las tareas de dirección.
P: ¿Participarás en algún otro evento próximamente relacionado con este campo?
R: Siempre que pueda ser interesante nuestra participación en algún evento, acudiremos y, obviamente, siempre será en torno a la disciplina de desarrollo del software, concretamente, en la aplicación de marcos de trabajo Agile/Lean. En este sentido, en el pasado impartí alguna charla en el “Lean Kanban Southern Europe” hablando sobre la aplicación del método Lean Kanban y también participé en la “International Business Servitizacion Conference”.
