Tales from the Scrum: No esperemos a Superman

En estos días, buscando ejemplos de antipatrones de Scrum, me encuentro con el “Hero-Driven Development” (visiten todo el blog Scrum is Scrum). Hace poco comentaba sobre las “prima donnas” en desarrollo en Tales from the Scrum- No somos Q. El caso que quiero comentar ahora, es distinto. El desarrollador super héroe de nuestra historia, puede ser un tipo apreciado, querido por el equipo, reconocido en su campo. Es uno de esos desarrolladores que puede programar mucho más que los demás. Steve Mc Connell los llama 10X Developers. Pero puede causar problemas. Veamos (basado en el blog que mencioné):

Problema: En el medio del desarrollo, surge un problema. Puede ser una configuración de Windows Communication Foundation, un tema de mapeo de Hibernate, una instalación en JBoss. No importa. El problema es complejo, y bastante técnico. De pronto, se abre la ventana, y entra nuestro “programador héroe”, reluciente en su traje. Se sienta, mira el código, entiende el problema, y lo va solucionando. El equipo, arrobado, se queda atrás, mirando, cómo nuestro Superman del código, va resolviendo el más intricado nudo de desarrollo. El héroe, concentrado, no habla ni explica. Parece relajado, lo que hace es “pan comido” para él. Entonces, en un momento, para, el problema está solucionado, levanta la vista, mira al equipo, y sale volando por la ventana, directo hacia el atardecer. Gran música de fondo.

Contexto: El equipo no sabe cómo solucionar el problema técnico que surgió. Es algo en lo que tienen poca experiencia. Trataron de solucionarlo, pero no pudieron, y están entrando en pánico. Pasan las horas, y no avanzan. Todo está empantanado. Entonces, encienden la señal, para llamar al super héroe.

Fuerzas: Vivimos en tiempos de cumplir los compromisos que asumimos para la iteración. Queda poco tiempo para la entrega. Todo indica que necesitamos una solución rápida.

Solución: No hay que buscar solución rápida. Primero, habría que haber previsto el riesgo tecnológico, desde el propio equipo. Los miembros deberían haber anotado que en algún momento se toparían con una tecnología que no conocen, y tendrían que haber tomado la tarea asignándole más tiempo. Pero bueno, supongamos que no se pudo hacer eso. El problema de arriba, es que el equipo delega la solución FUERA del equipo. El equipo, de alguna forma, “se lava las manos”. La actitud del superhéroe también conspira para eso. No es ése el camino. El equipo no debería perder “ownership”, propiedad y responsabilidad del producto, y de cada pequeño o gran problema. El desarrollador super héroe, que los hay, debería haberse integrado al equipo, compartiendo su conocimiento. Debería actuar como consultor del resto del equipo, pero trabajando con él. Y cada cosa que haga, con el equipo, será considerada como cualquier otra tarea de otro miembro: deberá cumplir con los estilos pactados, las métricas adoptadas, la definición de “hecho”. No debe ser un miembro “distinguido”. Lo que haga, debe estar público y lo más entendible posible para el resto del equipo. Tal vez no consigamos una solución tan rápida como la de arriba. Pero seguramente, a largo plazo, estaremos construyendo un equipo más responsable.

Recuerden: uno de los grandes entregables, en Scrum, es el equipo.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in 10549, 1389, 2752, 3463. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>