En dos días, puede formarse y certificarse como SCRUM Master – en línea, eso sí. Al parecer, esto lleva a muchos directivos a la suposición errónea de que la TI ágil es fácil y rápida de implantar. En cuanto a la metodología, puede que sea cierto. Pero la decisión por una TI ágil es una decisión por un cambio cultural que muchos directivos subestiman. De eso trata este artículo.
¿Le parecen emocionantes e interesantes la TI ágil y la gestión ágil de proyectos? Entonces, ¡usted es como yo! Lo veo como una gran oportunidad para aplicar de forma flexible y rápida los requisitos que se imponen a la organización de TI. Pero no todo lo que se autodenomina ágil lo es en realidad, así que eche un vistazo más de cerca conmigo.
¿Una TI realmente ágil o sólo ágil pintada?
Vayamos directamente al grano. ¿Cómo distinguir una TI ágil de una organización de TI que simplemente «pinta ágil»? Según mi experiencia, hay dos condiciones principales que debe cumplir el cliente de un proyecto.
La primera es: mi única persona de contacto es el propietario del producto. Esto significa confiar plenamente en el equipo SCRUM, no tener poderes de información y control y participar regularmente en las reuniones de planificación y revisión. Si ésta es la cultura de proyectos que se vive o a la que se aspira en su organización de TI: bien. De lo contrario, puede suponer que el proyecto sólo pinta ágil.
¿Y la segunda condición? Se trata de dinero, por supuesto. Es esencial que el cliente sea consciente de una cosa: no hay ninguna garantía de obtener un servicio predefinido en una fecha predefinida por una determinada cantidad de dinero invertida. Si, por ejemplo, se habla de calcular costes y fijar plazos para los elementos del backlog, puede suponer sin temor a equivocarse que el cliente tampoco se toma en serio la TI ágil. O simplemente no lo entendió.
Una TI ágil significa proximidad al negocio
Incluso en los proyectos dirigidos de forma ágil, la calificación de los requisitos es un factor decisivo para determinar la complejidad de la realización y el número de iteraciones necesarias para implementar un requisito. Cuanto más se acerque el equipo Scrum a los equipos de competencia de las unidades de negocio, mejor. Mi experiencia personal es que el intercambio directo es especialmente eficaz. Y sólo es necesaria una competencia metodológica mínima.
Las palabras clave en este contexto son épica e historias de usuario. En este contexto, un Epic describe una capacidad empresarial, es decir, un servicio que el equipo de competencias del área de negocio presta interna o externamente. Una epopeya se desglosa en historias de usuario. A continuación, describen unidades autónomas que el equipo Srum puede realizar en un sprint de un máximo de 4 semanas. Un ejemplo: para una empresa comercial, una Epopeya podría ser la tramitación de pedidos. Y las historias de usuario describen a continuación el apoyo a los distintos canales a través de los cuales se reciben los pedidos.
La ventaja: al final de un sprint, se puede presentar al cliente una funcionalidad totalmente desarrollada. Esto permite al cliente experimentar el progreso del desarrollo. Y si hubiera algún malentendido en los requisitos, se pone de manifiesto en la revisión del sprint para que se puedan hacer ajustes rápidamente.
¿Le parece bien? Lo es, pero ¿cómo conseguirlo?
Lo primero es lo primero: el cambio cultural para una TI ágil debe ser deseado y apoyado plenamente por la dirección de TI. En términos concretos, esto significa que el manifiesto ágil se entiende a nivel de gestión. Como consecuencia, es posible que haya que redistribuir las competencias.
En segundo lugar, es necesario que la financiación de los equipos Scrum esté completamente desvinculada de los proyectos ágiles realizados. Concretamente: los empleados con las competencias necesarias deben ser financiados o adquiridos por un periodo de tiempo determinado. Y eso depende exclusivamente de las arquitecturas y normas de TI elegidas por la empresa. En qué proyectos ágiles se despliegan después estos empleados es completamente independiente de la decisión de financiación.
Y por último, pero no por ello menos importante: la TI ágil y los proyectos ágiles sólo tienen realmente sentido si se puede garantizar que los desarrollos terminados también se pueden poner en producción rápidamente. Por un lado, esto requiere procesos ajustados y pruebas de aceptación organizadas de forma eficiente y, por otro, procesos de prueba y construcción automatizados. La palabra clave en este contexto es DevOps – el tema merece un artículo aparte.
Reflexiones finales
Especialmente en las medianas empresas, la flexibilidad y la rapidez son una ventaja competitiva decisiva. Mi opinión personal es: la TI ágil es obligatoria en el segmento de las PYME. Puede que existan restricciones reglamentarias, pero eso no se interpone en el camino de una TI ágil. Lo mismo se aplica aquí: Los que quieren, buscan formas; los que no quieren, buscan razones.
Estaré encantado de analizar con usted la estrategia existente. Averiguamos qué hay que hacer para conseguir una TI totalmente ágil. Con un coaching a medida para ejecutivos y equipos informáticos, le ayudo en la implantación. ¡Espero poder apoyar a su empresa en esto!
