Juan Palacio, David Alfaro y un servidor grabamos un podcast este pasado sábado sobre el papel que en Scrum juega el Propietario del Producto o Product Owner.

Cualquiera que se haya aproximado mínimamente a Scrum sabe que la labor del Propietario del Producto es representar la voz del cliente asegurando que el equipo de desarrollo se enfoca en los temas adecuados desde la perspectiva del negocio.

Evidentemente dentro de esta definición caben muchísimos matices y detalles. Precisamente esto es lo que tratamos en el podcast.

Los asuntos más relevantes que hemos tratado son:

Las labores del Propietario de Producto, todas ellas relacionadas con la gestión de los requisitos del proyecto de un modo u otro:

Mantener contento al cliente.
Realizar la captura de requisitos.
Priorizar los requisitos.
Digerir esos requisitos antes de que lleguen al equipo de desarrollo.

También hemos hablado sobre la diferencia entre el papel que juega el Propietario del Producto comparándolo con roles como el de Product Manager que aparece en otras metodologías. Hemos comentado sobre este punto como la principal diferencia es el uso de determinados artefactos (product backlog, historias de usuario) y liturgias (scrum planning meeting, scrum review) y como la labor del Propietario del Producto esta en todo momento guiada por la búsqueda de valor para el cliente.

Hemos hablado también de como la priorización de requisitos es la técnica que lleva a lograr ese retorno de la inversión.

Hemos hecho mucho hincapié en la importancia de tener este rol perfectamente detectado entre los participantes en el proyecto y que su voz debe ser única y respetada en todo lo relativo a que se debe hacer en el proyecto.

Sirva este post de introducción al tema y de invitación a que escuchéis el podcast.

Si os a gustado este postcast no os perdáis otros muchos relacionados con Scrum y la agilidad en el canal Open Knowledge Scrum Manager.

¡Espero vuestros comentarios!

El pasado martes estuve participando como ponente en las ALM’09 Sessions. Un exitazo de evento que reunión a más de 800 profesionales interesados en mejorar la gestión del ciclo de desarrollo de sus aplicaciones. La agenda que propuso Microsoft y la calidad de los ponentes tubo una clara respuesta. Plain Concepts era uno de los patrocinadores del evento y colaboramos con tres charlas. Yo hablé en el track de procesos, mi compañero Jose Luis Soria hablo de ecosistemas heterogéneos de desarrollo y Team System, y mis compañeros Pablo Peláez y Ricardo Acosta, hablaron de como integrar a los diseñadores en el ciclo de vida.

Como no podía ser de otro modo hablé de Scrum, aderezándolo esta vez, con un poco de buenas prácticas y con un tema que cada vez me preocupa más, la gestión de la configuración en equipos ágiles. El motivo es que veo cada vez más aberraciones de arquitectura, complejidad innecesaria y disfunciones en el ciclo de vida que se pueden solucionar con una política de gestión de la configuración. La gestión de la configuración es una de las ramas más desconocidas, más infrautilizadas y peor utilizadas cuando se usa, de la ingeniería del software.

Os dejo la presentación que realice:

Como siempre, lo mejor en este tipo de eventos fue la oportunidad de charlar con compañeros de la comunidad, amigos, clientes y gente interesada en la gestión de sus proyectos y las tecnologías de Microsoft.

¡Un saludo!

Escribía hace un tiempo sobre el triangulo de gestión de proyectos y la férrea dictadura que impone sobre la gestión de proyectos. En esencia, uses la metodología que uses para la gestión de proyectos o incluso si no usas ninguna hay cuatro factores sobre los que, como gestor de proyectos, puedes llevar a cabo tu gestión: la calidad, el alcance, el coste y el tiempo. De todos estos factores, el cliente puede controlar como máximo, tres. El cuarto será el que nos permite gestionar. Si el cliente o alguien externo a la gestión del proyecto controla la totalidad de los aspectos ¿que papel nos queda como gestores del proyecto?.

Dado que el dichoso tirano triángulo nos impone su realidad, cabe plantearse una serie de cuestiones sobre el mismo y su relación con Scrum: ¿Cuál es la relación de Scrum con estos factores? ¿Cómo se actúa sobre ellos en Scrum? ¿Cómo condicionan esta metodología? ¿Qué decisiones explicitas han tomado los diseñadores de Scrum sobre ellos? Estas son las preguntas que quiero responder, en la medida de mis conocimientos, con esta serie de post.

Hoy hablaremos de la calidad, desde la perspectiva de Scrum.

La calidad no es opcional, no es un factor sobre el que podamos especular. Ni siquiera lo podemos gestionar explícitamente: cualquier decisión que tomemos puede ser dañina, vaya esta en el sentido de incrementarla como en el sentido de reducirla. Es un aspecto que siempre decide el cliente no quien gestiona el proyecto. Si decidimos recortar calidad para ganar velocidad, por ejemplo, tarde o temprano lo pagaremos si la calidad que logramos no es la que el cliente está dispuesto a aceptar.

El riesgo, ocurre a menudo, es sobrereaccionar. Para asegurarnos de que cumplimos las expectativas ponemos más calidad de la necesaria en el proyecto. El problema es que la calidad adicional tiene un coste, pero sin embargo, no es percibida por el cliente. Suelo poner siempre el mismo ejemplo, que explica muy bien este asunto, solo es un ejemplo, que nadie se quede con los valores absolutos. A mi me gusta el vino, el buen vino, estoy dispuesto a pagar por un vino de cierta calidad. Si alguien me quiere regalar vino, que no se gaste más de 25 euros, ni menos de 10. Por debajo de 10 euros, es probable que el regalo no cumpla su cometido de agradarme, por encima de 25, estará tirando el dinero, ¡mi paladar no es capaz de distinguir un vino de 25 euros, de uno de 35!. A partir de 25 euros todos los vinos me parecen excelentes. Descubrir el nivel de calidad que satisface al cliente al menor coste, es nuestra principal labor a la hora de gestionar la calidad.

El otro aspecto clave la gestión de la calidad es mantenerla a lo largo del proyecto. Es sumamente difícil medir el nivel de calidad de una manera objetiva, precisamente, por que es algo que depende de los usuarios, de los clientes y de su percepción subjetiva. Pero siempre tenemos una idea más o menos intuitiva o analítica (será más analítica si tenemos métricas claras, un proceso de aseguramiento y validación y sobre todo si tenemos testers) sbore cual es nuestro nivel de calidad que nuestro cliente requiere. Y sobre todo de cuan lejos estamos del nivel de calidad que nuestro cliente esta dispuesto a aceptar: ¿se beberá nuestro cliente un Don Simón o un Castillo de Vulpi (dignísimos vinos en brick para calimotxo, pero capaces de corroer una copa de cristal) sin negarse a pagar la cuenta?. Supongamos que no, ¿cómo podemos descubrir que nuestro cliente no se conformará con nuestro Don Simón, sino que quiere mínimo un rioja joven un poco decente y en botella?. Y sobre todo, una vez que lo descubrimos, que sabemos el nivel mínimo de calidad que satisface a nuestro cliente, ¿cómo aseguramos que no estamos elaborando Don Simón?. Por que estaremos de acuerdo en que si estamos elaborando Don Simón es muy muy difícil que al final, hagamos lo que hagamos, logremos que nos salga un Vega Sicilia (¡hay clientes muy exigentes!). Debemos evitar a toda costa darnos cuenta al final de que no hemos alcanzado el nivel de calidad que nuestro cliente requiere, es un riesgo que no podemos asumir.

El único enfoque que funciona, es, sin duda el mantener de manera constante, durante toda la vida del proyecto, un nivel de calidad que sea aceptable al cliente. Si no averiguamos el nivel de calidad que el cliente esta dispuesto a aceptar y no lo mantenemos a lo largo del ciclo del vida del proyecto, a final, cuando los recursos y el tiempo que nos queden sean más bien justos, tendremos que, aunque la funcionalidad este completa, el proyecto se alargará para alcanzar el nivel de calidad necesario.

Las claves son claras: descubrir el nivel mínimo de calidad que el cliente esta dispuesto a aceptar y mantenerse alrededor del mismo durante todo el proyecto. La pregunta es ¿qué mecanismos establece Scrum para que esto ocurra?: El sprint review y los incrementos de funcionalidad potencialmente entregables.

El sprint review, actúa como regulador de la calidad. Por un lado nos va a permitir detectar, mediante el feedback que los asistentes aporten, si estamos lejos o no del nivel de calidad requerido. Además, que el equipo presente las nuevas funcionalidades, es un catalizador clave de la calidad: asegurando una calidad mínima (da mucha vergüenza que te ‘casque’ una demo) y asegurando que el equipo percibe cual es el nivel de calidad mínimo aceptable.

Los incrementos de funcionalidad potencialmente entregables son otro aspecto clave de Scrum. Si algo es ‘potencialmente entregable’, como debe ser el resultado de todo sprint en Scrum, debe cumplir las expectativas de calidad de nuestro clientes (o de su proxy, el Product Owner). Si algo no cumple las expectativas del cliente, no está completado y no se sigue avanzando. Esta es la única manera de asegurar que el equipo no toma atajos sacrificando funcionalidad o no cae en el preciosismo, añadiendo calidad que el cliente no está dispuesto a apreciar y mucho menos a pagar.

Un error habitual es recortar el sprint review o saltárselo, de tal manera que el equipo nunca llega a descubrir cual es el nivel de calidad mínimo aceptable por el cliente o no se asegura que no estamos lejos de este.

En la próxima entrega, Scrum y el triangulo de la gestión de proyectos: El alcance.

Aun estoy que no me lo creo. Pedazo de evento nos ha salido, y cuando digo nos ha salido me refiero a los 160, si 160, asistentes. Aunque los patrocinadores y la organización también hemos tenido algo que ver seguro. No cito a nadie de la organzación para no dejarme a nadie: compromiso compartido y responsabilidad compartida, para lo bueno y lo malo.

No esperaba yo tanto de este evento, sobre todo era bastante escéptico en lo que al formato de open space se refiere. Eso de no tener una lista de sesiones de antemano me ponía un poco nervioso ¿cómo podía saber que las sesiones merecían un viaje desde Bilbao? ¡Nada me garantizaba tener un hueco a pesar de que mi empresa patrocinaba el evento! ¿y si no había temas suficientes? ¿y si había mucho? ¿y si construir la agenda era un proceso eterno?… El resultado a tener de la retrospectiva que entre todos los asistentes realizamos al final del evento no puede ser más satisfactorio. En lo personal decir que a sido uno de los eventos en los que más he disfrutado… y mira que he participado en eventos ¿eh?…

La primera jornada del evento, viernes por la tarde, se dedicó a montar la rejilla. Básicamente el proceso es escribir el título de tu propuesta (sesión, debate, charla magistral o lo que sea) y tu nombre en una tarjeta, comentar en un minuto de que va el tema y luego poner tu tarjeta en un panel con una chincheta. Luego todos los asistentes cogen tres pegatinas rojas que representan votos y las reparten por aquellas sesiones de su interés. Se recogen las sesiones más votadas y de manera colaborativa se distribuyen por la rejilla de sesiones. Entre mi compañero Jose Luis y yo propusimos cinco sesiones (tampoco hay que abusar) y salieron las cinco. Una pena que una de J se solapo con una mía y no pude asistir. El que salgan todas tus propuestas tiene una pega, no puedes ir a las sesiones de los demás… es el único  pero que puedo poner. A continuación podéis ver la rejilla. Repasando la rejilla he visto que hay una sesión mía a la que no asistí, ¿Ya tengo Scrum y ahora qué?, se fusiono con otras y no me di cuenta. Pensé, erróneamente que se había quedado fuera, lamento el error y pido disculpas.

Las sesiones a la que acudí fueron:

Artesanía del software, propuesta por Xavi Gost

Esta sesión molo de verdad, la más friki, de todas la que asistí, sin duda. Pura diversión. La radical propuesta de Xavi (al que le ‘da vergüenza ser tan frki’ jajajaj…) era dejar fuera de la sala todo lo que oliese a negocio y centrarnos en la parte más artesanal, lúdica y motivadora del desarrollo de software. A final la sesión se centro en la belleza del código. Xavi defendía que el código debe ser bello, que el código bello en un valor en si mismo y yo, en otra línea más utilitarista comentaba que para mí el código bello es el código bueno. No todo el mundo compartía mi opinión. Se habló de analizadores estáticos, que garantizan un mínimo de calidad pero nunca belleza y todos concluimos por unanimidad que el camello de Perl es tan bello como mal ejemplo de código mantenible. También se hablo de las escuelas de programación y su relación con las escuelas de Kung Fu. La idea de Xavi que comparto plenamente es que a programar se aprende principalmente con maestros, con gente que te ayuda, es paciente contigo, te corrige el código con cariño (o tobas, en esto no nos pusimos de acuerdo), y leyendo buenos libros. Podéis ver otro resumen de esta sesión (y de otras) y la lista completa de libros propuestos en el post que ha publicado Jose Manuel Prieto sobre el evento.

Control en proyectos ágiles, propuesta por mi

Mi idea para esta sesión era debatir y compartir con los asistentes las métricas y técnicas de control y seguimiento de proyectos que utilizan las metodologías ágiles. Utilice la siguiente ppt para romper el hielo:

Luego a base de preguntas a la audiencia y su participación llegamos a las siguientes conclusiones, que fuimos poniendo en una pizarra durante la sesión:

La base del seguimiento del avance de un proyecto de un proyecto es utilizar tareas pequeñas y binarias.
Es necesario visibilizar y medir el avance.
La métrica clave es la velocidad, pero hacia fuera del equipo interesa más el grado de cumplimiento de lo comprometido en el sprint.
Para cumplir hace falta compromiso, sin equipos dedicados no se logra compromiso. Definir tus equipos es vital.
Solo con estimaciones colegiadas y consensuadas, logramos compromiso por parte del equipo.
Es vital la priorización. Cuando las métricas cantan que estamos retrasados, no tenemos más opción que recortar funcionalidad.
Sin priorización ese recorte deja fuera características importantes y daña el resultado del proyecto irreversiblemente.

Tres años de proyecto con Scrum, propuesta por mi

En esta sesión, ya un clásico, pues la he presentado en una u otra forma en varios foros diferentes trate de comentar mis experiencias de tres años en un proyecto gestionado con Scrum y Team System como herramienta de gestión. Una vez más use una ppt para romper el hielo:

En esta sesión hable de las dificultades, las acciones tomadas ante ellas y los resultados que nos ha dado la adopción de Scrum y Team System en el desarrollo de Captor 3 en Sisteplant. Angel Agueda tiene un excelente resumen sobre esta sesión en su blog, así que os remito a el.

Oficina de proyectos ágil, propuesta por Xavier Albaladejo.

Lo mejor de la sesión sin duda, escuchar las experiencias de Xavier en Indra y ver como está cambiando el panorama de la gestión de proyectos en empresas de esa envergadura gracias a tipos como él. La otra gran cosa fue coincidir con mi viejo conocido Angel Medinilla. Angel es uno de los grandes del agilísmo en España, coincidí con él en el curso de CSM y desde entonces, de un modo u otro hemos estado en contacto. Poder debatir con él la visión de una oficina de proyectos ágil fue toda una experiencia. La principal conclusión de la sesión para mí fue que una oficina de proyectos (PMO) que de una visión global de todos los proyectos de la empresa y que de soporte en ingeniería ágil a todos los proyectos es posible y deseable. También fue muy interesante la aportación de gente que ya está en PMOs, como Juan Mari Huarte de Orona.

Documentación ágil e historias de usuario propuesta por Jose Luis Soria, también de Plain Concepts y por otra persona cuyo nombre no recuerdo (disculpas):

Excelente sesión en la que se trataron temas como:

¿Cúal es la utilidad de la documentación?
¿Cómo de útiles son las historias?
¿Cómo es una buena historia?
La importancia de las condiciones de aceptación
Documentar frente a refactorizar

Las principales conclusiones:

La documentación es un subproducto del software que funciona. Debemos evitarla.
Los wikis pueden ser de gran ayuda, pero también tienen problemas relacionados con la organización, la responsabilidad sobre el contenido etc…. Ninguno de estos problemas anulan su utilidad.
Debemos tender a generar toda la documentación.
La única documentación única es aquella que evoluciona a la vez que el código.

Seguro que Jose Luis nos contará más cosas sobre esta sesión y sobre la otra sesión que propuso sobre gestión de la configuración en proyectos ágiles.

Destacar la aportación de Joao Gama en esta sesión. No todos los días se encuentra uno con un Product Owner profesional y que se dedica a ello ‘full time’. Esto es algo que me encanto del formato open space, ¡cualquiera puede aportar en una sesión!.

Mi conclusión sobre el evento: excelente, no he estado nunca en un evento más participativo. Todo el mundo tuvo voz y todo el mundo tenía cosas interesantes que decir. Pensé que no tenía mucho que aprender sobre agilidad, que era un campo ya muy arado, ¡como me equivocaba!.

Y sabéis lo mejor ¡este era el primer evento de Agile Spain!… en próximas ocasiones no se que va a ser esto…

Por último decir que también aprovechamos para constituir oficialmente como asociación Agile Spain. Puedo presumir de ser uno de los que han firmado los estatutos aun a costa de casi perder el avión… menos mal que lo cogí, sino me cuesta el matrimonio y con razón.

Podéis encontrar una recapitulación de post, fotos y twits sobre el evento en esta página.

¡Un saludo!