"Lo siento, pero Agile no mejora tus productos"
Ya hemos publicado la entrada del blog de Jeff Sutherland, en la que responde a un post de Adam Pisoni, en el que afirma que Agile en realidad no mejora tus productos. Aquí está ese post de Adam Pisoni, cofundador y ex director técnico de Yammer y fundador de Responsive.org.
Si no lees regularmente los trabajos de Steve Denning, te recomiendo que lo hagas. Es uno de los mejores autores cuando se trata del futuro del trabajo. En un artículo que escribió para Forbes, dice que el desarrollo ágil de productos se ha convertido en la corriente principal, pero también plantea la pregunta de si ahora se ha convertido en una moda pasajera como tantas otras teorías de gestión. Su conclusión es que Agile no es realmente una moda, porque
"Agile y Scrum abordan directamente las preguntas empresariales actuales que las iniciativas del siglo XX evitaron. En Agile y Scrum, los clientes obtienen una voz a través del Product Owner y las competencias se colocan por encima de la autoridad."
Aunque básicamente estoy de acuerdo con muchas cosas en su artículo, debo estar en desacuerdo con su conclusión. Agile realmente ha dado un buen paso en la dirección correcta, sin embargo, para mí eso no es suficiente. Antes de que existiera Agile, ocurría con demasiada frecuencia que los equipos necesitaban extremadamente mucho tiempo y recursos para construir algo, solo para descubrir en el momento de la finalización que el cliente en realidad no quería eso.
Agile debería permitir principalmente construir productos exitosos en un mundo que cambia demasiado rápido para predecir lo que la gente quiere y cómo construirlo mejor para ellos.
Aunque Agile le ha enseñado a toda una generación de desarrolladores de software cuán importantes son la experimentación y el feedback de los clientes, Agile no ha logrado cambiar el antiguo sistema centralizado de Command-and-Control en la gestión, lo cual representa una gran parte del problema. Incluso con Agile, los desarrolladores que tienen muy poca influencia y muy poco contexto necesitan demasiado tiempo para desarrollar productos que los clientes en realidad no quieren. Eso resulta en clientes insatisfechos, desarrolladores desmotivados y gerentes frustrados.
Solo para información, desde 1995 hasta 2014 siempre fui – excepto por una breve interrupción después del estallido de la primera burbuja de las punto com – ya sea un desarrollador de software a tiempo completo o líder de equipos de desarrollo. En 1997 dirigí un equipo que usaba el método Cascada (predecesor de Agile). Con Cascada se hacía todo el trabajo de diseño y planificación por adelantado y se asumía que entonces se podría dividir y completar el trabajo.
En 2004 trabajé para una empresa que confiaba mucho en el análisis y las pruebas A/B e incluso tenía releases semanales – con todo eso estaban adelantados a su tiempo. Recuerdo cómo la gente hablaba por primera vez de Scrum, y recuerdo que tenía una idea clara del problema que estaba tratando de resolver: mala gestión.
Para ser justo, debo decir que he releído el Manifiesto Ágil y sus principios y estoy de acuerdo con cada punto. Siguen siendo tan buenos y relevantes hoy como lo eran en 2001 cuando fueron escritos. En Agile deberías construir algo iterativamente y aprender continuamente mientras lo haces, en lugar de seguir un gran plan. Además, el cliente debería ser un confidente cercano durante todo el proceso, para que puedas aprender de él durante toda la fase de desarrollo. Dado que el objetivo debería ser absorber permanentemente nueva información, también deberías asumir que cambiarás de dirección regularmente.
Antes de que existiera Agile, la gestión creaba un plan que documentaba (predecía) exactamente qué se construiría, cómo se construiría y cuánto tiempo tomaría – siendo esto último probablemente la parte más importante. Como sabemos, estos planes eran apenas predecibles y rara vez se podían cumplir. El resultado fueron expectativas y plazos poco realistas.
Para empeorar las cosas, debido al retraso de tiempo entre la finalización del plan y la entrega del producto, era muy probable que la gestión cambiara de opinión sobre el producto sin ninguna comprensión de los costos. Eso, por supuesto, enfureció a muchos desarrolladores, cuyo trabajo era ejecutar el "plan". Eso significaba que la situación con plazos poco realistas solo empeoraba y obligaba a muchos equipos a mantener los cambios posteriores tan bajos como fuera posible mediante aún más planificación. Irónicamente, los equipos de desarrollo obtuvieron más autonomía para decidir en qué orden completarían el trabajo, cómo lo construirían, quién lo haría, etc., debido a la falta de transparencia en el proceso de desarrollo. Por supuesto, la consecuencia de este tipo de autonomía y la falta de transparencia a menudo es la desconfianza entre la gestión y el equipo de desarrollo. Al final nadie estaba contento.
Y luego llegó SCRUM. Con eso se suponía que se aumentaría la transparencia en el proceso y se mejoraría la eficiencia en el desarrollo. Semanalmente, los gerentes podían decidir qué historias (o características) querían a continuación y los desarrolladores podían entonces estimar cuánto tiempo y recursos necesitarían para eso. El equipo podía entonces determinar los costos totales de todas las historias priorizadas y descubrir cuánto de este trabajo podían asumir para el próximo sprint.
Scrum ha aumentado drásticamente la transparencia y ha hecho más difícil para los gerentes exigir más de lo que se puede lograr. También se tuvo en cuenta la necesidad de actualizar los planes iterativamente. Sin embargo, debido a la mayor transparencia en Scrum, los desarrolladores tienen aún menos autonomía que antes. Los poderes de los desarrolladores se redujeron a determinar cuánto tiempo probablemente tomaría algo y elegir la siguiente historia de una lista que en su mayoría es prescrita por la gestión.
Un desarrollador que trabaja en una historia puede no tener idea del contexto y por qué esta historia es tan importante o cuál es la iniciativa detrás de ella.
Aunque Scrum ha logrado frenar a los gerentes impulsivos, en última instancia se trataba de ejercer más control sobre los desarrolladores y su trabajo.
Todavía la gestión toma decisiones, prioriza las características y prescribe quién en qué equipo trabaja en qué. Con su enfoque en la estimación del esfuerzo del trabajo prescrito y poco contexto, Scrum mira hacia atrás al cambio de siglo, donde Frederick Taylor dio instrucciones detalladas a los trabajadores de fábrica.
En el taylorismo se asume que los gerentes son los que tienen la experiencia y el contexto para poder prescribir en qué se debe trabajar. Por lo tanto, era su tarea dar planes detallados a los empleados para que tuvieran que tomar tan pocas decisiones propias como fuera posible.
Casi al final de los Principios Ágiles aparece un principio bastante fuera de lugar que Scrum ignora:
Las mejores arquitecturas, requisitos y diseños provienen de equipos auto-organizados.
Teóricamente es posible usar Scrum para rastrear trabajo en equipos auto-organizados, sin embargo, eso no está previsto y solo ocurre muy raramente. La mayoría de los libros sobre Scrum abordan esto desde la perspectiva de la gestión de arriba hacia abajo y no a través de la auto-organización.
Agile fue un paso importante para reconocer cuán importantes son las pruebas y el trabajo iterativo basado en el feedback del cliente. En gran parte, sin embargo, está orientado a una mayor eficiencia y Control vs. Empoderamiento o equipos auto-organizados. Uno de los autores del Manifiesto Ágil, Andy Hunt, también lo ve así.
Por supuesto, se puede argumentar que Agile no es el problema, sino métodos como Scrum. Sin embargo, esta distinción fina se pierde, ya que Scrum y Agile ya se han convertido casi en sinónimos. Cuando Agile se hizo conocido, desafortunadamente fue cooptado por modelos tradicionales de Command-and-Control, de los cuales surgieron métodos como Scrum.
¿Cuál es la alternativa? Echa un vistazo a los métodos de desarrollo de Spotify o las estructuras de Yammer. En lugar de cargar trabajo a personas individuales, das a los equipos más autonomía para decidir qué quieren construir y cómo. Estos equipos también consisten en personas de las disciplinas más diversas para asegurar que puedan completar todo lo necesario sin tener que esperar el permiso o el apoyo de otros.
Ya sea que actualmente trabajes con Scrum en tu organización o no – si tienes la sensación de que avanzas demasiado lento y no estás construyendo lo que tus clientes quieren, hay varias formas de experimentar con nuevos modelos sin tener que cambiar todo de una vez.
Elige un proyecto y reúne un equipo pequeño y comprometido con personas que tengan todas las habilidades necesarias, incluso si estas personas tienen diferentes gerentes. Preséntales el problema y dales la oportunidad de resolverlo como crean que es correcto.
Idealmente, este proyecto es lo suficientemente corto para poder determinar rápidamente si el experimento funciona. Si solo a regañadientes le das al equipo esta responsabilidad propia, o has elegido a las personas equivocadas, o tal vez el problema está en ti mismo. Llamarlo un "experimento" puede ayudarte a vender tu idea. Muy probablemente descubrirás que pequeños equipos de expertos comprometidos y multifuncionales pueden lograr extremadamente mucho en muy poco tiempo.
El próximo desafío es descubrir cómo transferir eso a una escala más grande, si debería funcionar. Para eso normalmente se necesitan nuevas soluciones, lo que lleva a nuevos problemas, para los cuales se necesitan nuevamente nuevas soluciones. No es fácil, pero vale la pena.
Te darás cuenta de que funciona cuando tu equipo pueda presentar a los clientes más ideas nuevas más rápido que antes. Ese es el objetivo.
La autonomía requiere confianza y eso a su vez requiere contexto compartido. Esa es la razón por la cual estos modelos más nuevos dependen de la transparencia completa cuando todos deben mantenerse informados. En Yammer tenemos equipos de proyecto de corta duración, para que las personas obtengan más oportunidades de trabajar realmente y aprender de las personas más diversas – pero esa es solo una forma de abordarlo.
No es suficiente que la gestión sea solo la voz de los clientes. Los desarrolladores y diseñadores deben entender e internalizar ellos mismos las necesidades y objetivos de las personas para las que están construyendo algo.
Agile fue un paso importante lejos de las organizaciones y métodos de la era industrial. Sin embargo, si quieres crear una organización para el siglo XXI, tendrás que mirar más allá de Agile a modelos más nuevos que distribuyan la autoridad, sean auto-organizados e inviten realmente a tus clientes, socios y empleados a convertirse en "propietarios" del proceso.
Este texto proviene del Blog de First Round y fue traducido por nosotros al español.
Para Scrum Master ofrecemos las siguientes formaciones y oportunidades de desarrollo gratuitas: