Tales from the Scrum: No somos Q

No se si conocen o recuerdan al personaje de Q, que apareció en el capítulo presentación de Star Trek: Next Generation. Dotado de poderes sin límites, el personaje interpretado por John de Lancie ha aparecido en varios episodios, siendo uno de los favoritos de la audiencia trekkie. En la tercer temporada de Next Generation, en el capítulo Déjà Q le quitan los poderes, y pasa a ser un simple mortal, que tiene hasta que comer para sobrevivir. Se le sugiere integrarse a la tripulación de la Enterprise, pero él responde que no está acostumbrado: “Es difícil trabajar en grupo cuando se es omnipotente”.

Q nunca podría ser un buen miembro de equipo Scrum. Recuerden: Scrum es un marco de trabajo para producir software EN EQUIPO (se puede extender para otras actividades, pero siempre en equipo). La idea de equipo en Scrum es fuerte: miembros con distintas habilidades y competencias, que trabajan coordinados para ir armando, iterativamente, el producto que el cliente necesita. En general, se usa la figura del Scrum Master para mantener el equipo dentro de las buenas prácticas, como mantener la reunión diaria, evaluar correctamente el Sprint (iteración), actualizar el backlog de sprint, ver que se arma y priorice lo mejor posible el product backlog, etc.

Pero, en el día a día, lo que cuenta es el trabajo en equipo. No hay lugar para “prima donnas” o “Qs” en un equipo Scrum. Claro que puede haber miembros con más “seniority” en un tema técnico, o en alguna habilidad (como diseño gráfico, o base de datos). Pero lo importante es que toda tarea, y su resultado, queda a cargo del equipo. No hay “me corto solo” en Scrum. No hay actitudes de “yo lo hago mejor, y hago esto, y nada más”. No hay “yo me encargo de la base de datos, lo demás no”. No hay “esto lo hago yo, porque lo hago mejor que Uds.”. Debe haber “esta tarea la tomo yo, si quieren, hago pair programming con X, y dejo claro cómo lo hice, para que mañana otro pueda seguir con esta tarea”. Si no se puede llegar a esa actitud, por lo menos, debemos luchar para conseguirla, y marcar nuestra falta en las retrospectivas (recuerden que para eso están las reuniones de retrospectivas: no para marcar errores, sino para detectar malas prácticas, o formas de trabajo no efectivas, y mejorarlas).

Cada tarea es del equipo.

Tomemos un ejemplo en concreto. Puede que haya en el equipo alguien ideal para escribir el manual de usuario de una parte del sistema que estamos armando y entregando (ciertamente, hay manuales de usuario, y es muy probable que se algo que para el cliente tiene valor de entrega y nos lo pida; sino, es, en general, un buen “over-delivery” que hace que el producto entregado tenga mejor recepción y uso). Supongamos que esa persona, llamémosla Juan, se recibió de “Technical Writer”, o que es el que mejor conoce esa parte del sistema. ¿Será él el que tome esa tarea? Un día, al comienzo, en la reunión diaria, Juan tome la tarea. Pero bien puede ser que sea una tarea que insuma varios días: hay que escribir una tabla de contenido, un glosario de los términos, una introducción, un paso a paso, sacar “screenshots” y ponerlos en el documento, escribir sobre el proceso A, el B, el C… En definitiva: la tarea puede partirse en varios pasos. Y entonces, seguramente otros miembros del equipo podrán colaborar con alguna de las subtareas. El miércoles, Juan está enfermo, y falta. Pedro, que estuvo colaborando con él, bien puede seguir con la tarea: aprendió cómo se organiza el material, cuál es el ejemplo que se estaba desarrollando en el manual, y puede seguir con el tema. Mientras tanto, el documento va quedando publicado en el repositorio de código del equipo. José “odia” hacer documentación. Pero igual revisa el documento parcial producido, y descubre que un “screenshot” no corresponde con lo el ejemplo que se explica. María detecta que se está usando mal el tiempo verbal. Francisco, que está desarrollando otra parte del sistema, y es el menos familiarizado con el tema del manual, apunta que no se entienden algunos términos, que el creador original del documento toma por sabidos por todo el mundo.

Cuando al final del Sprint, el documento es entregado, casi todos los miembros del equipo pasaron por la producción del mismo: escribiendo, revisando, juntando material, mejorando una parte, sugiriendo cambios. Y ese entregable, es responsabilidad del equipo. Si luego se detecta que hay un error tipográfico o de concepto, es el equipo el que se hace cargo de ese defecto.

Trabajando en equipo, hasta capaz le ganamos a Q y todo… :-)

Nos leemos!

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

This entry was posted in 10549, 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>