Agile pragmático Vs Agile tecnicista

No hace mucho luego de participar de una revisión de un incremento, un Arquitecto manifestó no estar convencido con las estimaciones por Story Points.

Recuerdo, su punto de vista le indicaba que había “descubierto” que podía estimar 50 Puntos de Historia con un equipo experto y tener un Scope realmente desafiante, y un equipo inexperto podría estimar exáctamente los mismo Puntos de Historias pero para un Scope mucho más pobre y esa incongruencia le molestaba. Claro, al final de cuentas lo que importa es cuantas historias por Sprint se finalizan para determinar una velocidad del team.

Allí mimos surgió del Ubber Scrum un análisis que indicó que dado a que tienen enorme cantidades de datos colectados por producto, relacionados con las líneas de código y áreas funcionales modificadas, es posible determinar métricas que indiquen la cantidad de Historias de Usuario y complejidad, desarrollados por Sprint y de ese modo, podrían realizar estimaciones casi de manera automática, es decir a mi entender, prescindiendo del criterio del team o al menos como un fuerte indicador o “driver”.

En mi razonamiento, este enfoque “tecnicista” le quita pragmatismo a cada proyecto y al equipo mismo que disminuye su creatividad, practicidad y pronto el interés en la interacción y así la útilidad del enfoque agilista carecería de espíritu. Por intentar esto, salvaguardar métricas uniformes útiles para todas las “ventanas” de información, me pregunto ¿cuanta interacción estamos dispuesto a relegar?.

Para el ejemplo particular que mencioné antes, creo que con solo medir el valor entregado al cliente, sabrás que tan importante es el trabajo realizado del equipo y con solo este criterio en mente, ¿que importancia puede tener si el equipo A (experto) estimó 50 puntos de historia para algo muy complejo y el equipo B (inexperto) estimó 50 puntos de historias para algo menos complejo?.

Yo mismo he vivio que a la Historia de Usuario más compleja, la hemos tenido que dejar de lado por la historia más sencilla de todas por que de pronto en medio del Sprint, pasó a ser la de mayor valor para nuestro PO.

Un caso típico es cuando los comerciales “enganchan” un nuevo cliente y en cuestión de días deben mostrarle el producto y no podrían mostrar el módulo de reportes si no se modifica el “branding” (headers & footers) que aún menciona al producto con la antigua denominación del proveedor anterior.

  • Entonces, agilizar una organización es algo más que solo agrupar los equipos de una determinada manera para que todos juntos ejecuten sus tareas. En su lugar regáleles principios y valores, donde la confianza y la cooperación primen.
  • Agilizar, nada tiene que ver con permitir que subsista la antigua cultura de aislamiento y comunicación esporádica entre individuos. En su lugar promueva una conversación constante sobre los tópicos del negocio, cara a cara y en una misma jerarquía. Lo que uno no puede, varios podrán.
  • Agilizar una organización es mucho más que brindarles recetas bien acomodadas para que las Historias sean rastreables con requerimientos técnicos, diseños de arquitectura, componentes y funciones. En su lugar ayúdales a conocer la importancia que las historias tienen para representar las necesidades de negocio que el cliente tiene y ayúdales a encontrar una relación con las tareas técnicas sin que ello implique sumergerse en “enfoques tecnicistas”.
  • Agilizar, es mejor que solo permitirle a los equipos realizar estimaciones por puntos para que finalmente éstas deban rigurosamente, ser congruentes con cantidad de horas por tareas y para el colmo, uniformes a lo largo de todos los equipos de la organización. En su lugar permite que todos sientan orgullo por sus estimaciones y permite que ellos las expongan sus avances con monitores omnipresentes.
  • Agilizar es más que ofrecerle a los equipos, un juego de herramientas ostentosas que soporten extensas WBS trackeables (auditables) desde todos los niveles. En su lugar, permítale a su equipo colaborar en cada tarea que vaya surgiendo sin tener que anticipar el detalle de su existencia, tal vez las estimaciones por puntos en las historias ya es suficiente como para también tener que estimar horas por tareas.

Desde que conocí el agilismo, entendí que cuando más fractales son los equipos, más cohesivo es el funcionamiento orgánico y más flexible, capáz de adaptarse a los cambios.

La cuestión natural en Agile es que los equipos deben ser permanentes y ganar experiencia en cada proyecto, mejorar en cada proyecto, optimizarse en cada proyectos. Por otro lado, el problema natural es que cuando los equipos no adoptaron los principios, aún comprendiendo las prácticas, es muy fácil que cualquier opinión contrarie y debilite el verdadero sentido y utilidad de éstas prácticas.

One thought on “Agile pragmático Vs Agile tecnicista

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s