"Agile está muerto". La gente dice eso todo el tiempo. Pero necesariamente agregan: "Estamos bromeando". Significaban que
tenías prácticas tan estúpidas y equivocadas que Agile está muerto para
ti . Pero el "verdadero" Agile no está muerto. Es solo que todos lo hacen mal. Entonces me di cuenta: el verdadero Agile es, ya sabes, Agile
en teoría . Incluso lo implementé. ¿Y sabes que? Estoy harto de eso.
Recientemente, vi la misma vieja defensa en mis artículos: "Pero, pero, pero el problema es la cascada, el scrum y la implementación incorrecta de Agile, la no observancia del Manifiesto ... bla, bla, bla". Entonces Bob Marshall me dijo la verdad. Él dijo: “Cállate, Charles. El manifiesto ágil es la jarra que llenamos. Hizo algunos comentarios con los que tuve que estar de acuerdo. Lo pensé El resultado fue este artículo.
Aquí hay una prueba para ti. ¿Cómo comienza la primera línea de un manifiesto ágil? No mires. No lo sabes Todo esta bien. No importa Dice: "Estamos descubriendo métodos de desarrollo de software más avanzados ..." Detente. Aviso, dice: "desarrollo de software". No dice: "sacar a su organización", "pagar la deuda para la transformación", "cortarla con esta mierda de comando y control", "centrarse en los resultados y mejorar el trabajo de apertura", "arreglar su sistema de presupuesto medieval" o lo que sea valor agregado más avanzado que la gente intentó invertir en él. Pero el hecho es que cuando la gente dice que Agile se refiere a toda la organización, es revisionismo. Esto no es justo.
Observe también que comienza "
Descubrimos ..." Él no dice: "Hemos recibido desde arriba ..." ¿No cree que hemos aprendido algo de 2001? Quiero decir, sí, la mayoría de las organizaciones grandes todavía están estancadas en 1987, pero está bien, tú. Contrariamente a la creencia popular, la foto a continuación no es realmente del acto de firmar el manifiesto. ¿Podemos finalmente dejar de fingir?
El manifiesto cumplió un propósito específico, pero no lo llevará a donde lo necesite. Así que comienza tus estudios. Nuestro conocimiento tiene una fecha de vencimiento, y no tanto como pensamos. Todos tienen colegas (generalmente jefes) que afirman que "no tienen tiempo para aprender". Usted mismo sabe que ellos confían demasiado en su conocimiento. Así que encuentra una buena lista de libros. Manténgase al día con buenos blogs. Aquí hay un comienzo: si no ha leído
Sense & Respond ,
Lean Enterprise ,
A Seat at the Table y
Everyone Is a Change Agent , le sugiero que lo haga de inmediato. Y a tus superiores.
Comienza a leer publicaciones de John Cutler, Melissa Perry, Bob Marshall, Allen Holub, Laura Klein, Erica Hall, Neil Killick y aquellos a quienes se refieren. ¿Están todos de acuerdo entre ellos (o conmigo)? No, pero son inteligentes y también te harán más inteligente. Comienza a leer y anima a los demás. Fast Company dice que el CEO promedio lee 60 libros al año. ¿Cuántos libros leen tus líderes? ¿Y qué leen ellos? (Los artículos de HBR, los informes de Gartner y las novelas de Maeve Binchi no cuentan). Porque seamos sinceros: si tus líderes son maestros de Scrum, entonces estás firmemente atrapado en los años 80 y 90.
Pasemos al aprendizaje continuo y dejemos de fingir que Agile es algún tipo de cura. Esto debe decirse:
Agile es y siempre ha sido una optimización local para un ligero aumento en la eficiencia del sistema . Solo Agile coloca injustamente bajo el microscopio a un equipo de desarrolladores de software. Esto no aumenta la flexibilidad organizacional. NO Curiosamente, según Ken Schwaber (ver su "Inseguro a cualquier velocidad"), Agile fue un intento de "compensar el daño causado por la cascada", sin embargo, nunca le dio a las organizaciones una alternativa holística y viable a la cascada. Porque hay una diferencia entre teoría y práctica. Trabajar en un producto es más una práctica. Cuando nos quejamos de AINO (Agile In Name Only), no somos honestos con nosotros mismos.
Teoría versus práctica, ¿recuerdas? Debemos ser pragmáticos. Ágil en la práctica es casi siempre AINO. Parece un problema con el movimiento en sí, ¿verdad? En cualquier caso, hay cosas más importantes para aprender, incluyendo (pero no limitado a) Lean UX, Lean Enterprise, Beyond Budget, Theory of Restraints, Throughput Accounting, Design Thinking, DevOps, Marshall Organizational Therapy, etc.
Puede preguntar por qué Lean UX encabeza la lista? Debido al hecho de que,
en esencia, Lean UX populariza el concepto de orientación a resultados. Piensa: si no sabes qué tipo de cambio de comportamiento estás tratando de crear, entonces no entenderás tus acciones. Si no tiene una señal de giro clara, ya no puede ser flexible. Eso es Agile, después de todo, es pivotar. Algunos pueden objetar: "¡No, no, no, verificar y adaptar!" Por supuesto Teoría versus práctica, ¿recuerdas? No veo equipos flexibles que prueben y se adapten. Veo equipos ágiles tratando de ponerse al día, jugando con Jira y Rally y trabajando como si estuvieran construyendo un muro de ladrillo por orden.
Ágil en realidad tiende a enmascarar el problema principal: esta es una falta sistémica y bidireccional de confianza vertical. Los Agile Coachis se van, empeorando la situación: dejan atrás a los gerentes que hablan cerdos y a un equipo de desarrollo que se cambió al esperanto. Los equipos creen que la administración está rota, y la administración cree que el enfoque principal aún debe estar en el volumen, el tiempo y la eficiencia, ignorando que los plazos son arbitrarios y las estimaciones de tiempo son una
forma de desperdicio . (¿Sabe qué puntos de la historia realmente se inventaron para
ocultar el tiempo y ayudar a resolver el problema en sí mismo? También hubo consecuencias desagradables aquí, ¿verdad? Teoría y práctica).
Adivina quién ganará? Dos campamentos con dos perspectivas radicalmente diferentes, ¿dónde obtiene un campamento calificaciones del otro? Si los equipos son como personas ciegas que sienten un elefante y no están de acuerdo con lo que es, entonces el liderazgo es como los elefantes ciegos que atacan a las personas y aceptan que todos son planos. La solución es reconocer que el sistema es
un equipo. Termine ya con optimizaciones locales y comprenda que la confianza es el problema número 1. Deje de colocar injustamente a los desarrolladores bajo el microscopio, permitiendo que otros se escondan en una caja negra. (¿Por qué no nos interesa cómo funcionan los equipos de desarrollo estratégico? ¿O cómo son las restricciones del sistema de los arquitectos heredados?)
Y mientras hacemos esto, debemos dejar de tratar a los equipos de desarrollo como si estuvieran trabajando en una fábrica. No estampamos platos de plástico. Creamos software. Debes dejar de actuar como si estuviéramos
sirviendo una pizzería . Aquí están las otras reglas. No utilizamos la misma receta probada.
Desarrollamos recetas . Si aún no lo ha entendido, se trata de un trabajo de apertura, no solo de entrega. El descuido del descubrimiento conduce a pérdidas masivas: funciones no utilizadas y otro trabajo que no logra resultados. Esto revela otra falla profunda de Agile. Sugiere que los usuarios pueden ser considerados como conejillos de indias: "Oye, solo usa este producto de mierda, luego lo mejoraremos". Excepto que el producto de mierda generalmente se mantiene así, ¿no? Las mejoras futuras se convierten en "costos" innecesarios.
¡Pero, pero, pero, Agile está realmente enfocado en la investigación! Derecho? Seremos honestos. Teoría versus práctica, ¿recuerdas? Si se gana la vida diseñando o investigando, responda esta pregunta. ¿Cómo te sientes al trabajar con equipos flexibles? ¿Se le ve inicialmente como valor y se le pide que ayude a "probar y adaptarse"? ¿O se le pide que "demuestre su valía"? Como dijo Alan Cooper, cuando se le pide que "demuestre su valía", queda claro que está en un sistema que no lo valora. Tenga en cuenta que le están pidiendo a un participante individual que demuestre su valía; no están preguntando cuánto de su código sesga realmente los indicadores en la dirección correcta. En otras palabras, todavía se centran en las personas,
no en el trabajo en sí . Probablemente todavía estén enfocados en los huesos, no en el valor, ignorando áreas donde una parte significativa del valor realmente fluye.
Si trabaja con equipos flexibles, la próxima vez que se le pida que "muestre su valor", intente esto. Comience haciéndoles preguntas. ¿Saben cuál es el precio de la demora? ¿Qué ejercicios usan para evaluar este parámetro? ¿Qué resultados específicos están tratando de lograr? ¿Qué proporción de su producto realmente alcanza su rendimiento? ¿No lo saben? Si hay formas más rápidas y económicas de averiguar qué desarrollar, además de solo lanzar el código, ¿están interesados en aprender? ¿Cuál es su eficiencia de flujo? Que tan malo es ¿Cuánto tiempo pasan en las reuniones? Si hay juegos de diseñadores y acciones simplificadas que conducirán a mejores soluciones en mucho menos tiempo, ¿están interesados en aprender? Porque no solo te mostraré mi valor, te enseñaré a crear más valor
en todo lo que haces .
Esta es una forma diferente de pensar. Esto es meta. Esto es estratégico Como señala Austin Gowella, tanto Agile como la cascada se centran en el
desarrollo . El diseño es una
prueba . Si no están interesados, puedes irte. Si simplemente bajan la cabeza para lanzar un producto, enfocándose en los costos, nunca sabrán lo suficiente como para entender que generalmente obtienes más de lo que te enfocas (um, huesos). Esta es una fábrica de características. Responsabilidad mutua. Pretenden crear platos de plástico. Tienes cosas más importantes que hacer. Porque el valor real lo proporcionan las opciones que se generan a través de la
investigación . Cuantas más opciones cree y más flexible sea su enfoque, más caminos posibles y mejores resultados. ¿Qué están tratando de lograr? ¿Han explorado de tres a cinco formas de lograr esto? Esto conducirá a una mejor toma de decisiones para el futuro. Una opción no es una elección. Dos es un dilema. Tres: ahora has logrado algo.
¿Has oído hablar de la Ley de Diversidad Necesaria? El componente con más opciones
controla el sistema . Aplícalo a la estúpida lucha de poder de Agile vs. Waterfall. Hubo ejecutivos que intentaron mantener el control del sistema desde arriba y equipos flexibles que intentaron acercar el valor a la fuente (usuarios y clientes reales). La salida de una guerra civil sin sentido es enseñar a las personas cómo generar opciones
en todos los niveles . El camino a seguir no es Agile Against a Waterfall. Este es un trabajo estratégico inteligente de arriba hacia abajo (cascada) con tácticas de abajo hacia arriba orientadas empíricamente. Diseño y descubrimiento de ayuda en ambos casos.
Entonces ... ¿cuál es la solución? Este es un enfoque razonable en resultados claros, no en la entrega, con resultados planificados en lugar de marcas planificadas, no con proyectos, sino con equipos de productos confiables autorizados para verificar suposiciones y encontrar el camino más corto hacia el valor.
Ahora para entrenamiento (adaptado basado en la tabla de John Cutler).
Entonces ... ¿eso significa que Agile se va? Por supuesto que no. Esta es solo una publicación de blog tonta. No tengo poder E incluso si lo fuera, Agile aún no desaparecería.
El movimiento ágil ha hecho posible muchos de estos conceptos . Además, contrario a la creencia popular, las prácticas ágiles no fueron inventadas por el movimiento ágil. Aparecieron décadas antes.
Así que no, no quiero que Agile se vaya.
Solo quiero que seamos más honestos.