Se hace camino al andar…

Estaba leyendo un artículo publicado por Xavi Albaladejo en su ProyectosAgiles.org sobre un juego de simulación para enseñar Scrum y me ha venido la idea de hacer un pequeño recopilatorio de artículos que he ido leyendo en los últimos meses y que puede servir para aquellos que queráis venir al Agile Open Spain 2009 con algo visto y, quién sabe, con algo incluso probado.

Empezaré por recomendar una introducción de Scrum en 10 minutos (realmente 7:59). Lo siento, está en inglés, pero merece la pena. Sería genial que algún voluntario le pusiera subtítulos en español, ¿verdad?

Lógicamente, luego os recomendaría leer la explicación un poco más extensa que hace Xavi en ProyectosAgiles.org. Simplemente pulsad en la pestaña “Qué es Scrum”, pero no os quedéis en leer sólo esa página, profundizad en los hipervínculos a medida que vayáis aumentando vuestro interés. Merece la pena.

Si os ha picado la curiosidad, hace unos meses Xavi Albaladejo, Xavier Quesada y un servidor grabamos un podcast para JavaHispano, donde no hablamos exactamente de Scrum, pero sí hacemos un repaso bastante completo a los fundamentos ágiles en general, que lógicamente son compartidos por Scrum. Creo que merece la pena también, modestia aparte, que echéis un vistazo a la presentación que hice no hace mucho titulada “Los principios ágiles” y que hace un recorrido del Manifiesto Ágil y sus Principios. He adjuntado también mis notas porque sin ellas os podéis quedar un poco perplejos.

Radiadores de información

La vida de un equipo que hace Scrum está muy vinculada al tablón donde se publica la información que produce el propio equipo de manera completamente transparente, entre otras cosas para evitar interferencias por parte de los gestores con la típica preguntita impertinente “¡Qué, chaval! ¿Cómo lo llevas?” (que en realidad quiere decir “¿te falta mucho para acabar?”). Por eso os recomendaría también visitar el blog titulado “Visual Management” (desgraciadamente en inglés) donde Xavier Quesada nos enseña cómo mejorar la gestión del proyecto mediante un mejor uso de los elementos visuales que empleamos para “radiar la información” (es decir, las pizarras, los post-its, etc) y nuestra relación con ellos. Por ejemplo, podemos elegir un tipo de rotulador u otro para escribir en nuestros post-its. Si escribimos con un “boli medio gastado” y con una letra garabateada, estaremos disminuyendo la eficacia de nuestro tablón. Estoy seguro de que si muchos le pedís a Xavier que traduzca su blog, él estará encantado. No en vano es el primer CSC (Certified Scrum Coach) de habla hispana.

Pero si nos quedamos sólo con el tablón, los post-its, las pizarras y las reuniones diarias, probablemente nos estaremos quedando en la parte más cercana al folklore.

Historias de usuario

El trabajo en Scrum se reparte en forma de historias de usuario, que se estiman y priorizan para formar parte de una pila de producto (o “product backlog” en inglés). La mejor referencia para este tema es, sin duda, esta presentación de Mike Cohn, aunque preferiría que os leyérais su libro “User Stories Applied” porque es excelente (y cortito). En cualquier caso, creo que también os podría valer este artículo en español del compañero de Viçenc García.

A mi, todo este tema de las historias de usuario me parece básico, porque si no escribimos bien lo que queremos hacer, ¿cómo vamos a poder hacerlo después? Por eso me interesa tanto todo lo relacionado con las pruebas de aceptación, que algunos preferimos llamar “especificaciones ejecutables” para hacer más énfasis en el hecho de que se escriben antes y no después de la construcción del software. Pero esto ya quedaría fuera de lo que es Scrum (estrictamente hablando).

Si ya habéis llegado hasta aquí, creo que estaréis en la mejor de las disposiciones para aprovechar al máximo el curso gratuito de “Introducción a Scrum” que ofrecieron hace ya unos meses Agustín Yagüe y Juan Gutiérrez en las instalaciones que Autentia nos prestó.

Literatura (en español)

Libros sobre Scrum (y agilismo en general) hay muchos, pero en español hay muchos menos. Yo me atrevo a recomendaros la lectura de dos (elegid vosotros mismos):

• “Scrum y XP desde las trincheras” es la traducción del “Scrum and XP from the trenches” de Henrik Kniberg, hecha por nuestros amigos de Proyectalis.
• Leo Antolí ha traducido “The Scrum Primer”, otra buena fuente de referencia sobre Scrum en español.

Formación

Y si queréis más, podéis ir echando un vistazo al calendario de cursos de Scrum que desde Agile Spain tratamos de mantener actualizado. Si quieres ofrecerte como voluntario para ser tú el que lo mantenga actualizado… no tienes más que ofrecerte. O mejor aún, puedes intentar arrancar un grupo local de Agile Spain. Hay uno en Barcelona y otro en Madrid. Para esto no tienes más que buscarte un lugar donde hacer la primera reunión (tu oficina, la oficina de un amigo, un bar, una escuela… cualquier sitio es bueno para empezar) y avisar por todos los medios que se te ocurran (tienes la lista de correo de Agile Spain a tu entera disposición y a todos nosotros para echarte una mano). Lo demás depende de lo que se os vaya ocurriendo y las ganas que tengáis.

<publicidad>
Yo estoy estudiando seriamente dedicarme a dar formación y coaching ágil en breve, aunque tengo cierto reparo al leer comentarios en contra de los que desgastan el término ágil para su aprovechamiento mercantil. Sea como sea, si alguien está interesado, que se ponga en contacto conmigo y quizás sirva para decidirme definitivamente.
</publicidad>

Por supuesto, tenéis las listas de Agile Spain (la comunidad ágil española) y Ágiles (la comunidad ágil latinoamericana) para cualquier duda o sugerencia que se os ocurra.

Corolario

En cualquier caso, implementar Scrum no os va a garantizar nada más que, si tenéis éxito o fracaso, lo sabréis cuanto antes. Pero no va a reemplazar el que tengáis que tener unas buenas prácticas de ingeniería y una actitud profesional frente al trabajo. Si tenéis inútiles y vagos en vuestros equipos, Scrum sólo os ayudará a identificar que tenéis este problema (ni siquiera os permitirá identificar quién es el más inutil y vago del equipo). Eso sí, si conseguís armar un equipo con ganas de mejorar y capaces de adoptar una alta dosis de autodisciplina, con un poco de paciencia veréis que podréis ir mejorando en las prácticas de ingeniería y, finalmente, consiguiendo éxitos para vuestros clientes, es decir, también para vosotros. Citando a  Alfredo Casado en un hilo de la lista de Agile Spain: “sin excelencia técnica no hay agilismo, sólo post-it pegados por las paredes”.

Como habréis podido comprobar, la mayoría de los recursos que he ido citando en este resumen tiene un cierto tono informal. Incluso los cursos y talleres incluyen juegos (como el que me servía de excusa para arrancar el artículo). Y no es casualidad. Desde el primer momento el agilismo ha estado relacionado con la idea de cambiar la forma de ver el lugar de trabajo como un sitio donde se va a sufrir por otro donde, a cambio de hacernos responsables de nuestro trabajo, nos lo podemos pasar bien.

Nos vemos en el Agile Open Spain 2009. No olvides tu cámara.

[La foto es una reliquia familiar (aclaro que de alguien que yo no conozco en absoluto) y representa a un grupo de chavales jugando a la pelota. Me pareció que destilaba una cierta ternura y por eso la elegí.]

Mientras estoy terminando el artículo sobre Scrum que dentro de un ratito publicaré, me he topado, gracias a un amigo en twitter, con este otro artículo que, por una parte me ha parecido muy acertado, sobre todo recordando que los métodos ágiles no son balas de plata, es decir, que no siempre son la mejor solución. Pero por otra parte me ha hecho plantearme si es correcta la imagen que transmito de mí mismo al declararme “evangelizador agilista” (“agile evangelist” si echáis un vistazo a mi perfil en LinkedIn).

Después de pensarlo bien y echar mano de mi ejemplar de “Fearless Change”, he llegado a la conclusión de que sí, de que es correcta. Es más, es la que quiero tener en este momento. Porque tengo una pasión y me gustaría poder transmitirla. Esta pasión es el desarrollo de software.

He descubierto que hay formas mejores de desarrollar software y me gustaría que fueran las que se usaran mayoritariamente en las empresas de desarrollo de software de nuestro país. No quiero parecer un “talibán”, alguien que dogmáticamente, sin reflexión alguna, trata de imponer su criterio a todos los demás. Por eso no me autodenomino “Emperador de lo ágil” ni nada por el estilo. Y es que no creo que tener una pasión sea malo, ni tratar de que los demás compartan tu pasión (sin imponerla ni ponerse muy “pesao”) sea malo. Así que creo que, aunque es cierto que hay que empezar a tener cuidado con los que recién llegan a aprovecharse de la marca “agile” y de los que quizás han creado marcas a partir de estos conceptos para “monetizarlos”, también creo que no debemos descartar directamente a aquellos que te tratan de mostrar su pasión simplemente porque se ha convertido en una “buzzword”.

Bueno, lo dejo que no me quiero poner “pesao”.

[La foto es una obra de Warhol que está expuesta en el MOMA de Nueva York y que representa una infinidad de latas de sopa de una misma marca, con lo que no es fácil distinguir una sopa de otra. ¿Moraleja o simplemente arte?]

Estaba escribiendo una respuesta en la lista de Agile Spain a mi compañero Leo, y me he ido liando, liando… y al final me ha salido un alegato contra la falta de productividad. Y como queda un poco “off-topic” he decidido sacarlo al blog.

Pues bien, el caso es que el próximo día 3 de Junio, Ángel Medinilla dará una charla sobre Contratos ágiles subtitulada muy acertadamente “Vendiendo Scrum a tus clientes”. Lo que pasa es, y esa era la razón por la que comencé a responder a Leo, que creo que Ángel puede encontrarse con preguntas chungas del tipo “en España eso no se puede hacer”, “no veas cómo son mis clientes” y similares. No hace mucho unos amigos me dijeron justamente esto. Y lo peor de todo es que yo al menos no tengo argumentos suficientes para rebatirles.

Ayer estuve charlando con Xavi Albaladejo también sobre esto mismo y creo que ahora estoy mejor “armado”, puesto que puedo explicar que es posible plantear dos relaciones comerciales con los clientes: una basada en el clásico “fixed price and time” (precio y fecha cerrados) y otra basada en el contrato ágil, es decir, “time and materials” (horas x hombre cerrados) con alguna matización. A este último hay que conseguir quitarle ese “tufillo a charcutería prestación de servicios sin valor añadido” que algunos le encuentran porque no se lo explicamos bien, pero creo que esto es un problema menor.

Pero yo soy un “creyente” y sospecho que la lucha por convencer a los “no creyentes” puede ser muy dura cuando lleguemos a los argumentos fatalistas de “en España eso no se puede hacer”. Sobre todo porque muchos se escudan en ese fatalismo para no afrontar la realidad de su falta de productividad. Yo opino que el mayor problema que tenemos en nuestro sector no es que los clientes no nos quieran comprar proyectos ágiles (que no digo que no sea difícil) sino que no tenemos equipos productivos y capaces de adoptar una cultura ágil, donde todos debemos ser responsables y buscar la excelencia. Tengo la extraña sensación de que muchos equipos de desarrollo no son conscientes de que (hagan agilismo o no) no trabajan para su jefe (el que les paga las nóminas) sino para sus clientes (los que pagan las facturas y que sólo lo hacen de manera continuada si quedan satisfechos). Vale, también los continúan por razones “extra-comerciales”: sólo tengo 3 proveedores y este contrato le toca a fulanito -aunque siempre me entrega los proyectos tarde y con una calidad demencial-, o la fase X del proyecto ha sido una porquería, pero no me queda más remedio que dar la fase X+1 a los mismos porque ningún otro podría entender lo que hay hecho… Pero estas razones son muy tristes, ¿verdad?

Lo siento si alguien se molesta, pero sinceramente es lo que pienso. ¡Ah! Y no me vale que me digan que en el extranjero es igual que en España. A mi lo que me importa es que la productividad en España viene descendiendo de manera continuada desde el año 1995 y que parecemos estar cómodos con ello. La noticia es de 2006 pero no creo que hayamos mejorado significativamente desde entonces. Además, hay otros artículos más recientes (todos pre-crisis) que argumentan con más datos esto que digo.

Claro, si nuestros equipos son poco productivos porque el proceso de desarrollo es mejorable, la respuesta es fácil: mejora el proceso de desarrollo y aumentarás la productividad. Pero qué pasa si el problema es de actitud. Si cuando pides que de iteración a iteración mejoren la productividad y desde el becario hasta el jefe de proyecto, pasando por todos los seniors, ninguno asume su responsabilidad y trata de hacer mejor su trabajo y el de su equipo. He dicho mejor, no bien. Y lo digo sobre todo porque, como yo lo veo, esto del agilismo va de ir mejorando de manera continuada. Y aportar valor al cliente, no a tu jefe, sino al cliente.

Toda esta reflexión “en voz alta” me ha recordado lo que decía Ken Schwaber (uno de los autores de Scrum) pero entonces llegamos a otro tema peliagudo: la meritocracia (léase “¿son capaces nuestros gerentes de despedir a los vagos y a los inútiles?”). Glub, mejor no sigo.

Bueno, Ángel, prepárate para la charla del día 3, porque si nadie te pregunta esto ya te lo preguntaré yo. (Si no me pierdo otra vez para llegar, claro) 

Voy en metro, ilusionado, camino del segundo día del curso de Scrum de Medinilla. Y me he pillado el libro de Gojko Adzic “Bridging the Communication Gap” porque ayer surgió el tema de las especificaciones ejecutables y los roles dentro del equipo. Pero estoy un poco desentrenado porque hace mucho que no voy en metro con tiempo para leer, y el iPod lo tengo vacío de podcasts por escuchar, así que me he puesto la “música aleatoria” y mientras escucho de lo más variado (desde la deliciosa Joy Denalane hasta M-Clan, que no veas cómo me animan) he pensado en tomar notas para cumplir con una “cierta obligación”: explicar lo que me ha parecido el libro.

Gojko Adzic es un tipo que habla en inglés con un acento balcánico realmente difícil de seguir (al menos para mi), así que pensé que era buena idea comprar el libro para entender a qué se refiere cuando habla de talleres de especificaciones y de pruebas de aceptación ejecutables en entornos ágiles. Además, Gojko Adzic también imparte cursos sobre Domain-Driven Design y esa relación entre DDD y pruebas de aceptación es algo que me interesa bastante.

Voy a ser sincero, también compré el libro porque es el primero en el que se habla de Concordion, la herramienta open source en la que modestamente colaboro. Pero son apenas unas páginas y el valor del libro es mucho más que eso.

Adzic explica la importancia de que “la gente del negocio” hable el mismo idioma que “la gente técnica”. Esto muchos lo entienden como obligar a clientes y usuarios a que hablen en términos tecnológicos como “altas, bajas, modificaciones y listados (CRUD en inglés)”, o peor aún, de tablas, campos y relaciones.

En DDD hablamos de un lenguaje ubícuo, o único en todo el proyecto, y que es el que usan tanto técnicos como usuarios. Esto permite reducir los defectos producidos por malentendidos y tiende puentes entre ambos mundos, abriendo la posibilidad a una verdadera colaboración.

Un inciso melancólico. Voy ahora mismo montado (mientras escribo estas notas en mi moleskine) en el metro ligero y me he acordado de ese par de meses intensos que viví y trabajé (sobre todo lo primero) en Melbourne (Australia). Allí fui usuario del “tram” y he de decir que me parece un medio de transporte público de lo más interesante porque es a la vez rápido, cómodo y silencioso.

Pero sigamos con el libro. El grueso del mismo se basa en hablar del “agile acceptance testing” y de cómo buscamos ponernos de acuerdo en qué es lo que hay y lo que no hay que desarrollar. Para esto usamos ejemplos realistas en vez de requisitos abstractos. “Los ejemplos demuestran cómo debería actuar el sistema y cómo debería ayudar a los usuarios a hacer su trabajo”. Adzic propone que estos ejemplos sean creados por todo el equipo de implementación, no sólo por un “experto del dominio” (también conocido como “analista de negocio”) como en modelos de desarrollo más tradicionales. “Usamos los ejemplos para discutir el dominio y asegurarnos de que no hay malentendidos”.

Según Adzic, el uso de ejemplos realistas obliga a pensar más acerca de los problemas. De hecho, comenta cómo se producen muchas discusiones entre los expertos cuando se plantean ejemplos para casos extremos; discusiones que incluso les hacen a veces revisar sus propios procesos de negocio. ¡Vaya! Si resulta que podemos ayudar a nuestros clientes en vez de simplemente observar su comportamiento “desde fuera”, como si fueramos “supernanis con corbata”.

Damned! ¡Me he saltado una parada! Estaba tan concentrado… Menos mal que la frecuencia del metro ligero éste es alta y he podido llegar sólo un par de minutos tarde. Buff…

De vuelta del estupendo curso de Ángel Medinilla, sigo con el resumen del libro y me fijo en que no he explicado esto de los ejemplos. Vamos, que no he puesto ejemplos de ejemplos. Adzic pone un ejemplo en la página 45 de una regla de negocio relacionada con el descuento que le podemos ofrecer a un cliente, pero a mi me gusta más el que explica David Peterson en la web de Concordion. Es bastante más completo porque nos lleva desde la historia de usuario (el requisito) hasta la prueba de aceptación automatizada (en forma de ejemplos). Es interesante cómo David hace mucho hincapié siempre en que debemos especificar con ejemplos que expliquen comportamientos muy elementales y dejar para otras especificaciones todo aquello que quedaría fuera. Son los “Further details” en el ejemplo. También Adzic habla de esto en su libro, pero menos; y yo creo que es importante esta anotación al margen para aquellos que queráis “tomar este camino” para hacer pruebas de aceptación.

En “Bridging the communication gap” también se explica cómo conducir estas reuniones (talleres de especificación) e incluso aconseja sobre algunas herramientas. Pero creo que es interesante explicar cómo pueden encajar estos talleres en nuestro calendario semanal (ágil).

Adzic sugiere lo siguiente:

Release es todo aquello que hacemos después de la demo para dejar bien cerrado el sprint. Etiquetamos en subversion, hacemos copias de seguridad, ponemos las versiones del nuevo sprint en los pom.xml (si usamos Maven y si es que tenemos que cambiar de versión), limpiamos las pizarras… y mientras esto lo pueden ir haciendo algunos desarrolladores (típicamente los becarios, je, je) pues el resto puede estar preparando el sprint primero revisando el backlog y luego, ya con los becarios incorporados, estimando las historias y decidiendo lo que se podrá hacer razonablemente en el sprint (las próximas dos semanas).

Ojo, es una manera de organizar el trabajo durante un sprint, pero lo importante de esto es que el dueño del producto (también conocido como jefe de proyecto, analista de negocio, o incluso tester, según vuestro “mapeo” preferido) se encarga de trabajar las historias de usuario (redacción y priorización) y de los ejemplos (criterios de aceptación) antes de los talleres de especificación, pero realmente es el equipo en su totalidad quien acuerda lo esencial de los criterios de aceptación mediante la discusión que se ofrece en esta reunión. Para los que ya estéis algo picados con esto del agilismo, me permito recordar “las tres Ces” (card, conversation, confirmation). Éste es el momento ideal para la conversación, aunque ya se haya tenido una conversación previa cuando se han estimado las historias de usuario en el Sprint Planning Meeting (usando terminología Scrum).

Bueno, y hasta aquí hemos llegado. Espero que os resulte útil. Y si alguien más se ha leido este libro y quiere contrastar aquí su opinión, estaré encantado de poder charlar con vosotros porque mi intención es preparar una presentación (o un taller, ya veré) sobre este tema y exponerla bajo el “paraguas” de Agile Spain.

Hoy he terminado el curso de Scrum que imparte Angel Medinilla y que tuve que dejar a medias en octubre porque me pilló el nacimiento de mi segundo querubín.

Vale que yo iba bastante motivado, pero en la retrospectiva que ha planteado Ángel al final del curso mis compañeros lo han calificado como “completo” y “ameno”. Lo cierto es que no puede ser de otra manera. Ameno porque hemos jugado a pasarnos pelotas a ritmo de Jamiroquai o hemos visto videos como éste. Y completo porque no sólo hemos aprendido cómo se hace Scrum sino también sus principios y por qué es rentable para una empresa implantar esta metodología de gestión de proyectos.

Y además de todo esto, que es el objetivo estricto del curso, Ángel habla de muchas otras cosas y comparte su experiencia con los asistentes. Y favorece también que este intercambio de experiencias sea recíproco, con lo que todos nos enriquecemos muchísimo.

Pero yo no quería escribir para hacerle una cuña publicitaria (gratuita) a Ángel (bueno, quizás se la cobre más adelante… ya se me ocurrirá algo… je, je). Yo en realidad quería explicar que este curso de Scrum es también un curso de gestión de proyectos encubierto y, para qué engañarnos, es muy necesario formar a nuestros jefes de proyectos y líderes técnicos en lo que significa gestionar un proyecto y su relación con la rentabilidad si realmente queremos que nuestro sector sea competitivo (especialmente en estos tiempos de crisis y “cambios de modelos productivos”).

Ojalá hubiera muchas empresas en España que se dieran cuenta de que sólo es posible mejorar nuestra competitividad mediante incrementos significativos de nuestra productividad y que, como bien se ve en uno de los ejercicios que hemos hecho hoy con Ángel, no es posible producir incrementos significativos de la productividad simplemente confiando en que con el paso del tiempo tenemos más experiencia o en que “vamos a echarle más ganas”. Esperar que algo cambie sin hacer nada diferente es la definición de locura según Einstein.

Hoy estoy en medio de un curso de Scrum de dos días que imparte Angel Medinilla. Acabo de leer un artículo de “El Raúl” titulado “No sé nada de Scrum. ¿Qué hago primero?” y no he podido evitar bloguearlo porque me parece un índice de recursos muy conciso, porque da un estupendo consejo (“Estudia”) y porque me da la excusa perfecta para meter la “cuña publicitaria” de Agile Spain.

Agile Spain es la comunidad virtual donde nos encontramos muchos de los que estamos interesados en que en España haya un cambio en la manera de gestionar proyectos y se comiencen a implantar metodologías ágiles como Scrum. Creo que es el mejor lugar para comenzar a compartir vuestras dudas y para informaros de cuándo y dónde se celebran charlas, conferencias, cursos, etc. Echad un vistazo a la lista de correo y si luego os interesa, suscribíos y participad.

He estado echando un vistazo a la última “refcardz” publicada por DZone y me ha gustado. Se titula “Scrum” y es un buen ejercicio de síntesis de este “framework” para la gestión de proyectos ágiles.

También no hace mucho publicaron otra dedicada a la adopción del agilismo en las empresas y tampoco estaba nada mal.

Si alguien está interesado, se las descarga, las lee y quiere comentarlas con alguien, se puede pasar por Agile Spain o por foro-agiles (el foro hispanoamericano).

Acabo de leer el artículo que Xavi Albaladejo ha publicado en Proyectos Ágiles titulado “Métricas ágiles y cuadro de mandos balanceado para Scrum“.

En mi modesta opinión, me parece una buena recopilación de métricas (algunas difíciles de automatizar, como la del resultado de las retrospectivas, pero no por ello de menor valor. Me atrevo a preguntaros, ¿qué 5, 6 ó 7 métricas usarías para que el cliente tuviera una visión resumida del estado del proyecto? Vamos, ¿cómo construiríais el “cuadro de mandos” para vuestros clientes?

Vale, como está feo tirar la piedra y esconder la mano, ahí van las mías:

• Velocidad del equipo (para cada sprint)
• ROI. Cada historia de usuario debe tener un valor de negocio asignada por el Dueño del Producto y, por tanto, podemos saber cuánto valor de negocio se ha convertido en cada sprint.
• Las tres métricas de calidad que Xavi resalta: Satisfacción del cliente o usuario, Incidencias o defectos detectados por los usuarios, Defectos detectados por el equipo de desarrollo.
• Tiempo de puesta en producción después de cada sprint. (Esta métrica no la incluye Xavi, pero a mi entender serviría para, de alguna manera medir parte de las “Lecciones aprendidas”)

Me gustaría también ser capaz de ofrecer al cliente alguna medida del riesgo que se está asumiendo y cómo va afectando éste durante la vida del proyecto, pero sinceramente no sabría bien cómo hacerlo. Quizás una buena referencia para esto (en inglés) sería este artículo que enseña a estimar el riesgo con una hoja de cálculo.

No estaría mal mostrar el “panel de control” como una “radar chart” para poder comparar de un vistazo varias métricas de un sprint a otro, p.ej.

¿Sería diferente el cuadro de mandos del cliente y el del ScrumMaster o jefe de proyecto? Hombre, el corazón me dice que deberían ser iguales por eso de que “somos un equipo”, “la transparencia con el cliente”, y todo eso…, pero la razón me dice que a cada uno le interesa una perspectiva diferente del proyecto:

• al cliente es algo más económico, de valor de negocio, de rentabilidad de la inversión en marcha,
• mientras que al ScrumMaster le interesa más bien los impedimentos que se pueden estar acercando para poderse adelantar a su aparición.

Por eso creo que deben ser diferentes. ¿Cuáles serían vuestras métricas para el ScrumMaster?

Las mías, creo que serían:

• Velocidad del equipo. Sí, también, de hecho, con más razón incluso que para el cliente. De esta métrica se pueden sacar muchas conclusiones que contrastar en las retrospectivas con el equipo. Es muy importante averiguar a qué pueden ser debidas las variaciones en la velocidad: estimamos mejor, hemos eliminado un impedimento que puede volver a surgir, ha surgido un impedimento que nos retrasa…
• Las líneas de código. Sí, sé que es un poco llamativo y
  “anticuado”, pero me parapeto detrás de un excelente artículo de James
  Shore (autor de “The Art of Agile Development”) sobre cómo medir la deuda técnica.
• Felicidad del equipo. Bfff, esto es dificil de explicar, pero la actitud que tiene el equipo después de cada retrospectiva es importantísimo en el desarrollo del siguiente sprint. Recomiendo leer sobre el “Niko-niko calendar“, y si alguien lo pone en práctica, estaría encantado de conocer sus impresiones.
• Desviación en las estimaciones. Me parece importante ofrecer este feedback al equipo (porque el “cuadro de mandos” creo que debe ser para todo el equipo), y por ello creo que el ScrumMaster debe ser capaz de recopilar esta información y manejarla con cuidado porque puede afectar mucho a la credibilidad del equipo (incluso para ellos mismos).
• Calidad del código: cobertura, complejidad ciclomática y las reglas de calidad acordadas que podamos automatizar con herramientas como Checkstyle, PMD, JDepend… Para esto último aconsejo encarecidamente que probéis Sonar.

Algunas métricas (como el “nikocal”) no son exactamente cuantificables, pero no es importante porque de lo que se trata es de ver las tendencias. En todos los casos, lo que importa no es la “instantánea” sino la tendencia puesto que sólo de las tendencias podemos sacar conclusiones o al menos elaborar hipótesis que nos ayuden en nuestro camino.

Doy por supuesto que tenemos en las paredes o en una herramienta (como radiadores de información) nuestros paneles constantemente actualizados con las historias de usuario del sprint en curso, las iniciadas y las terminadas, así como el gráfico de “burndown” y cualquier otro que vuestro(s) equipo(s) haya(n) considerado a bien tener siempre a la vista.

Y también doy por supuesto que nuestro equipo y nuestra organización están ya lo suficientemente maduros como para no tener que medir cosas como:

• Número de veces que se rompe el build (en Integración Continua)
• Calidad de los commits en el SCM. Por ejemplo, si pasan días sin que nadie haga commit es que algo muy malo está pasando. O si los commits no llevan un comentario que permita identificarlo y trazarlo con la tarea correspondiente.