Este artículo fue publicado originalmente por Foundry4, una consultora de tecnología que ayuda a las organizaciones a aprovechar la tecnología para resolver los complejos problemas de hoy. Lea el artículo original aquí y más Foundry4 insights aquí.

¿Tu organización ha cambiado su forma de trabajar a Agile pero aún no ha mejorado significativamente?

Muchas organizaciones luchan con Agile. Adoptan un marco ágil como Scrum, pero no ven ningún beneficio. Para algunos, esto se debe a que solo están hablando de labios para afuera, por ejemplo, celebrando eventos de Scrum, como el Daily Scrum, sin cambiar realmente su forma de pensar.

Pero incluso si vive la mentalidad ágil (como se describe en el Manifiesto para el desarrollo de software ágil de 2001), su objetivo puede parecer difícil de alcanzar.

¿Cuál es tu objetivo?

Implementar un enfoque ágil como Scrum no debería ser su objetivo: Scrum, Extreme Programming, Kanban, etc.son solo enfoques para ayudarlo a lograr su objetivo real. Entonces, ¿cuál es tu verdadero objetivo?

Cuando hago esta pregunta, un objetivo común que escucho es: 'Queremos que nuestros equipos entreguen más rápido'. Esto tiene sentido porque el Manifiesto Ágil habla de satisfacer a los clientes a través de 'entregas tempranas y continuas' y alienta a las personas a 'Entregar software que funcione con frecuencia '. Incluso afirma que "el software que funciona es la medida principal del progreso". (Fue escrito por un grupo de gente de software, pero puede cambiar "software" a cualquier producto o servicio que sea y aún funciona).

Por lo tanto, es comprensible que la entrega más rápida sea un grito de batalla común de la administración, especialmente en aquellas organizaciones que se consideran "ágiles".

El problema de la entrega más rápida

Encuentro que muchas organizaciones pasan por alto dos problemas importantes cuando se enfocan en este tipo de objetivo: ¿Qué problema se está abordando y quién lo quiere? ¿Qué cualidad es deseable?

"Antes de comenzar una búsqueda, es aconsejable preguntarle a alguien qué está buscando antes de comenzar a buscarlo". - Winnie the Pooh

El ejemplo que utilizo es el de servir a los comensales en un restaurante. Identificamos que tenemos una gran cantidad de comensales hambrientos y el jefe nos empuja a atender a estos clientes lo más rápido posible. Si nos enfocamos en la velocidad sin considerar la calidad, sacamos una tortilla cada 30 segundos y servimos tortillas repugnantes a nuestros clientes que nunca regresan. Si nos enfocamos en la velocidad sin considerar las necesidades de nuestros usuarios, solo descubrimos que estamos sirviendo tortillas a los veganos una vez que los platos están llegando a las mesas. Nuestra solución de entrega más rápida no ha satisfecho a nuestros comensales hambrientos y los hemos perdido para siempre.

El problema de la calidad es relativamente fácil de resolver negándose a ceder; un producto o servicio menos completo no tiene por qué significar una mala calidad, solo puede significar que una funcionalidad más limitada está disponible en los primeros días. Alcance reducido, no calidad reducida.

Desafortunadamente, muchas organizaciones de mentalidad ágil están cayendo en el otro problema, a menudo apresurándose a entregar antes de saber qué es lo que deberían suministrar.

La correccion

"Antes de comenzar una búsqueda, es aconsejable preguntarle a alguien qué es lo que está buscando antes de comenzar a buscarlo". - Winnie the Pooh

Construir algo y luego decirle a la gente que lo necesita es una forma muy difícil de vender un producto o servicio; deberíamos intentar satisfacer una necesidad real y existente de los usuarios.

Sin embargo, nosotros, la organización, no sabemos cuál es la necesidad más importante del cliente. Podríamos pensar que sí, pero eso suele ser solo una suposición no probada. ¿Y de quién es la suposición? ¿Los equipos? ¿El CEO? ¿El de algún otro experto dentro de su organización?

Sus clientes están en la mejor posición para decirle esto. No estoy sugiriendo que debamos simplemente darles a los clientes lo que piden. Aunque Ford nunca dijo en realidad "Si le hubiera preguntado a la gente qué querían, habrían dicho caballos más rápidos", todavía se entiende que dar ciegamente a los clientes lo que piden no es necesariamente una buena idea. Las organizaciones deben considerar las necesidades, los deseos y los deseos de sus clientes junto con sus necesidades comerciales.

El punto óptimo es la intersección entre la visión / propósito de la organización y las necesidades / deseos / deseos de los clientes. Solo entonces debería comenzar a avanzar hacia una fase de entrega, a través de las fases de solución y creación de prototipos.

¿Está mal el Manifiesto Ágil para centrarse en la entrega?

Escrito en 2001, el Manifiesto Agile estableció algunos principios que cubrían una colección de enfoques para hacer software, incluidos Scrum, Extreme Programming y Crystal Clear. Abordó una variedad de malas prácticas que eran comunes en el cambio de milenio: proyectos de 12 meses con un gran lanzamiento al final, equipos trabajando en silos, documentos de requisitos ridículamente largos y detallados, riesgo llevado al final del proyecto. , etcétera.

No prescribe cómo abordar cada proyecto. Deliberadamente omitió muchos, por ejemplo, no menciona establecer una visión o propósito, pero estoy seguro de que los creadores pretendían que los tuvieras. Entonces, no es que el Manifiesto esté equivocado; se trata de cómo la gente lo interpreta.

Se trata de interpretación

Es beneficioso que muchas organizaciones hayan asimilado las palabras del Manifiesto. Esto les ha permitido liberarse de sus viejas e inútiles formas de trabajar. Ahora pueden lanzar productos y servicios antes, lo que reduce el riesgo y brinda valor a sus usuarios antes.

Las organizaciones inteligentes son conscientes de que el Manifiesto Ágil no les da una guía paso a paso. Reconocen que se espera que ellos también piensen por sí mismos.

Desafortunadamente, hay algunas organizaciones que toman una lectura literal del Manifiesto, como si fuera un evangelio. Estas organizaciones adoptan un tipo de actitud de "solo hacemos lo que dice en el manifiesto" y corren el riesgo de perderse el primer paso crucial del desarrollo de productos / servicios: comprender cuál es el objetivo.

No comprenden qué es lo que necesitan sus clientes. No comprenden cuál es el "valor" de que el Manifiesto exige que se entregue de forma temprana y continua. Estas organizaciones son como el restaurante que optimiza para sacar dos tortillas por minuto… ¡pero no reconoce que sus comensales son veganos! La solución

Una opción sensata es seguir el enfoque del doble diamante, creado por Design Council. Esto comienza por comprender el propósito y los problemas de su organización. Luego busca comprender los problemas de sus clientes, recopilar información sobre esos problemas y encontrar posibles soluciones ... En este punto, puede comenzar con la creación de prototipos y la entrega iterativa.

No es que el Manifiesto Ágil se haya equivocado; es que algunas personas lo siguen a ciegas y se pierden el paso inicial y fundamental de descubrir y definir el problema que están tratando de resolver. Pensar un poco más es realmente importante antes de apresurarse a intentar acelerar la entrega.