11
2020
La diferencia entre Agilidad Empresarial y Agilidad en el desarrollo (Agile)
Léelo aprox. en 4:03 minutos.
Hay muchas empresas que abrazan la agilidad pensando en que es la solución que necesitan para reducir su time-to-market. Piensan que tardan mucho en desarrollar el software, la App, que de solución a su idea de negocio. Van a algunas conferencias, algunas charlas, se compran algunos libros, asisten a algunas formaciones y toman una decisión. ¡Empezaremos por scrum!
Lanzan un completo programa de transformación digital para la compañía, formando y aleccionando a sus equipos de desarrolladores. Contratan agile coaches, scrum masters y todo lo necesario para que nada falle. Y empieza el rock&roll.
Comienzan los proyectos, bueno les llaman iniciativas, liberan distintos presupuestos y dejan fluir la relación entre los product owner y los equipos asesorados por los scrum masters. Los agile coaches hacen su trabajo aleccionando a toda la organización y focalizándose en que negocio entienda la nueva forma de implicarse en los desarrollos.
Pasan los meses y empiezan a obtener algunos resultados que tienen que comentar. Pero atención hay algunos datos que no esperaban ver. Algo no funciona: el time-to-market ha mejorado algo, pero no todo lo que esperaban.
¿Qué ha sucedido? ¿Tanta inversión en el cambio para esto? ¿Para un resultado tan exiguo? ¿Cómo puede ser? ¿Qué ha fallado?
Lo que ha fallado es que la agilidad en el desarrollo de aplicaciones no es lo mismo que la agilidad empresarial o de negocio.
En el ejemplo que te he puesto el fallo que tuvieron es el pensar que mejorando una única parte, la parte del desarrollo de aplicaciones, iban a conseguir los resultados que pretendían. Para una mejora del time-to-market hay que fijarse en el value stream completo, en toda la cadena de valor. Sí valor, esa palabra tan maltratada.
¿Quieres llevar tus Proyectos a otro nivel?
¿Las vas a dejar escapar? ¡Quiero ser el mejor! ¡Quiero ser la mejor!
A la palabra valor le pasa lo que a esas palabras que todos tenemos aprendidas desde hace tanto tiempo que hemos olvidado que significan. Es de esas palabras que todos creemos que sabemos lo que son, pero somos incapaces de definirlas a los demás “claro, valor, eso , pues ya sabes”.
Para nuestra definición de cadena de valor debes tener en cuenta desde que se gesta la idea, desde que se enciende la bombilla, hasta que el software, la App, está funcionando en producción con los usuarios que la deben utilizar.
Entre medio debemos detectar e identificar todos los pasos que nos lleven de la una a la otra.
De todos esos pasos el desarrollo de la aplicación es sólo uno de ellos. ¿Qué puede ser el más importante? Depende de tu organización, lo que no debes caer es en poner el acento en él para distraer la atención de otros puntos de la cadena de valor que afecten a otros interesados como la detección y selección de las ideas o la determinación de la validez de las mismas.
Como te he comentado piensa ahora en tu cadena de valor. Piensa en tu compañia, en todos los pasos que hay que dar entre que surge una idea de negocio, se aprueba, se habilita el presupuesto, se selecciona un equipo para desarrollarla, se construye, se despliega y se lanza. ¿Sólo vamos a agilizar la construcción para mejorar el time-to-market?
Piensa en la situación actual, donde todavía sufrimos restricciones debidas a la COVID-19. Piensa que nuestra empresa cerró el año anterior con una selección de nuevas ideas a aprobar en el próximo comité de presupuestaciones para el año entrante. Dicho comité se reune dos veces al año la primera en Febrero y la segunda en Julio. Cuando se reunieron en Febrero aprobaron ideas lanzadas en Diciembre o antes incluso. Con su aprobación liberaron los presupuestos necesarios para llevarlas a cabo.
Del comité presupuestario, las iniciativas aprobadas, pasan a la creación de un estudio de viabilidad (en otras organizaciones un caso de negocio) para ver la posibilidad de desarrollarlas en mayor detalle. Tras esto pasan a la selección del proveedor y a la construcción de la misma para después lanzarla a producción tras consultar el calendario de puestas en producción.
Pensar en agilidad, time-to-market, viendo todo esta cadena de valor y centrarnos únicamente en la parte de desarrollo de la aplicación es una estupidez. Es como pensar que sólo los desarrolladores son los ineficientes, como si todo fuera culpa de IT ¿y el resto de los componentes de la cadena? Estamos hablando que aunque los desarrolladores implementaran las ideas en un mes, estaríamos desarrollando ideas de finales del año anterior donde nadie pensaba en la COVID-19.
Con una visión más amplia, mirando en cómo mejorar toda la cadena, será más sencillo que consigas mejorar el time -to-market porque pequeñas mejoras en cada punto, sumadas, serán una gran mejora general.
Esta es la diferencia entre la agilidad empresarial y la agilidad en el desarrollo.
Ten cuidado no te vayas a confundir a la hora de perseguirlas.
Ten claro qué quieres y cómo puedes conseguirlo.
Consigue Más de 100 Libros gratis
Suscríbete a nuestro newsletter por email y conseguirás Más de 100 Libros Gratis sobre Gestión de Proyectos, Innovación, Emprendimiento, Empresa, etc. directamente en tu correo
Últimos artículos de Julián Gómez (ver todos)
- El Último vídeo del viernes del año: Vuela como un dragón - hace 4 meses
- Ultimo video del viernes del año: Sé diferente - hace 1 año
- Vídeo del viernes: Kadenko, una luz en la navidad - hace 1 año
Otros artículos que te pueden interesar
2 Comentarios+ Escribir Comentario
¿Te ha gustado? Pues sólo cuesta un Comentario. ¡Gracias por adelantado!
Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.
Suscribo el artículo totalmente, de hecho es una de las estrategias más utilizadas, transformo IT y ya negocio irá a rebufo. No es mala estrategia si no te llevas a engaño y sabes que es una fase inicial, que no debiera durar más de 3 a 6 meses. Por otro lado que negocio no entienda que el portfolio debe ser agile y que no se transforme es una de las dolencias de grandes y medianas compañías, conlleva tiempo, esfuerzo, y formación práctica (mucha, en abundancia “no si yo ya sé Scrum”,… que va ni la incepción ni la realidad de los backlogs dominan). El portfolio agile conlleva que eso de grandes comités semestrales, ni trimestrales sean lo adecuado. Lo raro es que teniendo agile coach o SM se lleven las manos a la cabeza al evaluar resultados porque estas cosas son nuestro día a día y aconsejamos la transformación holística, no de IT para IT.
[…] La parte por el todo […]