Las zonas grises de Agile

De un tiempo a esta parte las metodologías derivadas de Agile y el Test Driven Development (TDD) se han convertido en buenas prácticas habituales. Pero “buenas prácticas” en un sector es casi sinónimo de prácticas mediocres.

Ahora todos los clientes piden Agile hasta el punto de que a mi empiezan a tenerme un poco frito con su esnobismo metodológico. No voy a comentar aquí las virtudes de Scrum ni Kanban, que son muchas, a quien necesite aprender sobre ellas le recomiendo el libro Kanban y Scrum traducido al español por el equipo de Agile Spain o la traducción de Scrum Primer de Ángel Medinilla. Me voy a centrar sólo en las zonas grises de estas metodologías y en por qué algunos clientes confían demasiado ciegamente en ellas.

1ª) Un producto “Agile” es tan bueno como lo sea su Product Owner. O, equivalentemente, si es product owner es un zote entonces el producto será un desastre. Existen principalmente dos clases de malos product owners: el iluminado y el desenfocado.

El product owner iluminado es aquel que cree tener una visión de rayo láser sobre cómo debe de ser el producto hasta sus últimos detalles. Curiosamente este iluminado a menudo no habla mucho con los usuarios finales, él simplemente “lo sabe”, sabe cómo debe ser el producto aunque no tiene ni idea sobre cómo es la operativa diaria de los usuarios finales. El resultado producido por este product owner iluminado es un software que hace perfectamente lo que no es del modo equivocado.

El product owner desenfocado se reconoce porque añade erráticamente requisitos al product backlog en cada sprint hasta que lo sume en un marasmo tan grande que es imposible para los programadores seguir el plan de desarrollo debido a que enloquecen bajo en efecto Zeigarnik. El resultado producido por un product owner desenfocado es un producto elefántico que hace de todo y no sirve para nada.

2ª) Reunirse todos los dias con los usuarios no es la solución mágica para enterarse de los requisitos. Uno de los principios de Scrum establece que los programadores y los usuarios deben reunirse y hablar con tanta frecuencia como sea posible. En la realidad los programadores suelen hablar con el product owner, quien, como ya he explicado, puede representar a los usuarios o no. Pero incluso si hablan a diario con los usuarios ¿Para qué lo hacen? Pues con frecuencia porque los programadores no se han enterado a priori de qué va el negocio de los usuarios. Es, además, fundamental darse cuenta de que la primera necesidad previa es ayudar a los usuarios a descubrir y entender sus propios requisitos. La mayoría de los usuarios no piensan en términos de procesos, entradas y salidas sino que ejecutan su trabajo de una forma más o menos automática sin metaconocimiento y, por consiguiente, necesitan apoyo para aprender a describir su flujo de trabajo en términos de clases e if-then-else. A veces incluso es mejor usar técnicas etnográficas sentándose cerca de ellos y observándoles en lugar de preguntarles directamente.

3ª) Las líneas de código no son una métrica fiable del avance un proyecto. Agile se centra en producir codigo. Al mismo tiempo, el product owner, en teoría, debe centrarse en maximizar el ROI del producto producido. Lo que pasa es que no existe una conexión necesaria entre ambos objetivos. Más líneas de código producidas en menos tiempo no implican indefectiblemente más ROI. Hay que trabajar en que los programadores entiendan el negocio y los procesos operativos de los usuarios antes de ponerlos a ambos a hacer navegación por estima.

4ª) En algunas organizaciones no se puede hacer Agile puro. Casi todas las grandes empresas están inexorablemente avocadas a algún tipo de Water-scrum-fall. Con esta afirmación los puristas de Agile seguro que me crucifican argumentando que, precisamente, lo que deben hacer estas organizaciones es cambiar su modo de trabajo globalmente hacia el agilismo. Pero es que el status quo en cada empresa es el que es, y no va a cambiar mañana para un proyecto que debería estar terminado ayer. Por ejemplo, es común que marketing fije los requisitos, y si marketing fija los requisitos entonces los programadores NO hablan con los usuarios porque si lo hiciesen ¿qué pintarían los de marketing? Y eso va a ser así hasta que suceda el improbable evento de que ruede la cabeza del VP de marketing.

5ª) El desarrollo no va de producir código sino de producir experiencias (UX). Mike Gualtieri dice en su artículo Siete cualidades de un software salvajemente deseable que todas las cualidades son importantes, pero sin UX ninguna de las otras sirve para nada.

6ª) Un buen product backlog no se centra en producir código sino en perfeccionar el que ya hay. La correción de bugs es una prioridad absoluta para mejorar la experiencia de usuario. Esta priorización pocas veces es parte intrínseca del proceso. A menudo los defectos software que van apareciendo se anotan en un bug tracker y los programadores continúan con su plan desarrollo y los van corrigiendo en los intersticios de la planificación. Una aplicación debe contener la mínima cantidad de código posible. Es algo paradójico que muchos programadores profesionales defiendan a muerte a los lenguajes que son textualmente más cortos como Ruby o Python y que, simultáneamente, prediquen técnicas para maximizar la velocidad de producción de código.

7ª) Pretender que haya algo visible y testeable en los primeros sprints es empezar la casa por el tejado. Según Scrum y TDD, al final de cada sprint de 2 a 4 semanas debe de producirse algún tipo de build estabilizada y testeable, incluso si luego hay que refactorizar el código. Como a un edificio, a un buen software hay que ponerle buenos cimientos, y los cimientos no son algo que los usuarios puedan entender ni validar. Aunque a priori parezca que es más rápido hacer primero la casa y meterse a vivir en ella y luego irle poniendo los cimientos, a la postre el coste total de la obra terminada será siempre más caro si se empieza la construcción por el tejado.

8ª) El modelo de equipo que propone Scrum choca frontalmente con el ranking de programadores. Uno de los principios de Scrum es que los programadores deben trabajar en un equipo multi disciplinar de multi aprendizaje fuertemente cohesionado. Esto es genial y muy buena idea. El problema es que muchas empresas, incluídas Microsoft y Google, han adoptado la costumbre de pedir a los managers que hagan un ranking de sus subordinados clasificándoles en sobresalientes, medios y deficientes. Quien cae en el grupo de los deficientes recibe primero un aviso y luego tiene una alta probabilidad de ser despedido. Este método por el cual, pase lo que pase, un 20% de los programadores recibirá un sobresaliente, otro 60% recibirá un aprobado, y el restante 20% suspenderá el examen es señalado por muchos expertos como una causa principal de que Microsoft lleve una década sin dar pie con bola debido a que los programadores están más preocupados de competir entre ellos que contra los programadores de otras empresas.

Conclusión

Agile es una filosofía, pero las metodologías ágiles son procesos que implementan esa filosofía. Los procesos están sujetos a la regla inapelable de “basura entra ⇒ basura sale”. Si se alimenta Scrum con entradas envenenadas el resultado será una ponzoña, más ágil y más Scrum pero igualmente fallida en la misión de maximizar el ROI que es de lo que se supone que va la metodología en definitiva.

Posts relacionados:
La estimación ágil de proyectos I: Puntos-historia y velocidad. (Jose Ramón Díaz)
Estimación ágil de proyectos II: Equipo multiproyecto. (Jose Ramón Díaz)

Presentación relacionada:
Agilidad para ingenieros del S. XXI (Ángel Medinilla).

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Esta entrada fue publicada en Desmitificando FUDs, Organizando la Comunidad. Modelos de Desarrollo. Guarda el enlace permanente.

4 respuestas a Las zonas grises de Agile

  1. quemasda dijo:

    Buen artículo para hacer bajar de las nubes a muchos. El cambio desde metologías tradicionales irá pasando, pero es muy inocente pensar que grandes empresas con procesos burocráticos cuasi inamovibles van a modificarlos para adecuarse a metodologías ágiles puras.

    PD: RoR es un framework, no un lenguaje.

  2. Pingback: Tendencias en el desarrollo de software 2014 | La Pastilla Roja

  3. Sergio,

    tu artículo me parece muy interesante, tocas con realismo varios aspectos que quedan etereos en las discusiones más filosóficas sobre agile. Parafraseando al célebre tema de los 70, “Now that we’ve got Scrum what we are gonna do with it”. Muy bién, ahora Agile ya es el paradigma de referencia en el mercado. Tenemos las 19 páginas de la Scrum Guide. Fantástico, ahora consigue proyectos de éxito en todos los contextos (no sólo en proyectos donde todo va de cara).

    Como casi todo cambio en la informática, el Ciclo de Hype se acostumbra a cumplir. Se ensalza que Agile y Scrum son el no-va-más, se filosofa sobre el cambio de paradigma en las empresas ágiles, etc. pero se dedica poco tiempo a hablar de proceso de software. Una vez que ya sabemos que Agile es bueno, creo que nos habríamos de centrar más en el proceso y en las prácticas ágiles, como ingenieros de software que somos (bueno, algunos rechazarán ese término y preferirán ser “artesanos”).

    Enlazando los dos párrafos anteriores, creo que habríamos de desmitificar Scrum y Agile, salirse de la ortodoxia y atreverse a proponer soluciones prácticas que se alejen de la teoría y encajen en las necesidades del día a día de las empresas “ágiles-imperfectas”.

    Mi experiencia de haber ayudado a muchas empresas desde hace más de 10 años a mejorar la efectividad de su desarrollo con modelos como CMMI, PMBOK, RUP y también XP o Scrum, me demuestra que cada empresa es un mundo por su estructura, roles, misión, tipo de producto, y que por tanto no debería ser nada extraño la heterodoxia que se describe en tus puntos 2, 4 y 8.

    He hecho, a mi me gusta usar el término Hybrid Agile (la vi por primera vez en Disciplined Agile Delivery) para enfatizar la complejidad y hereodoxia de las soluciones agiles en las empresas. En el caso más habitual, ni la empresa rechaza Agile ni se vuelve 100% Agile, se llega a un “meet in the middle”.

    En fin, vuelvo a felicitarte por tu artículo. Estamos en contacto.
    Àlex Ballarin

  4. Pingback: Metodologías basadas en la gestión de expectativas | La Pastilla Roja

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *