2013 Product Development Chain

Como os introducía en el anterior artículo, fruto de las retrospectivas y con la motivación de concretar más nuestro método de trabajo, hemos iterado nuestro proceso de desarrollo.

El proceso se divide en tres grandes grupos y responde a las necesidades actuales, lo natural, en caso contrario deberíamos preocuparnos, es que lo volvamos a iterar en pocos meses:

• User Research & Design
• I+D
• Quality Assurance

El objetivo no es necesitar tres sprints para poder aportar valor al usuario, si no que el equipo de trabajo, disponga de horas durante el sprint para trabajar en la definición y estimación de las tareas que van a ser acometidas durante los siguientes sprints. Pero que el flujo de generación de valor sea contínuo durante los sprints (15 días)

El método individual debe ser igualmente madurado, introduciendo conceptos de TDD. Necesitamos mejorar la calidad de nuestros desarrollos, y el test coverage de nuestras producciones. 

Así mismo, un trabajo más real en las tareas de estimación y proveer a la compañía de un calendario de producto. Algo nada fácil dado el generoso alcance de ForceManager. Pero que es fundamental para una correcta toma de decisión.

Una necesidad clara que teníamos durante este pasado 2012, además de la disponibilidad pública de un calendario, era basar nuestro trabajo en métricas que dirijan a nuestro jinete (Switch).

Hemos definido KPI en tres grandes grupos:

• Método de trabajo. Insights que midan el seguimiento del método de trabajo definido
• Quality Assurance. Insights que midan el nivel de estabilidad de nuestros productos
• Customer Commitment. Insights que midan impactos positivos/negativos con nuestro cliente (consecución de calendario previsto, tiempo promedio de liberación de una nueva funcionalidad, tiempo medio de liberación de una incidencia)

Para compartir estas métricas con todo el equipo y toda la compañía, hemos seguido las buenas guías de Visual Management, y hemos creado diferentes cuadros.

Por una parte gestionamos el LogOfWork del equipo diariamente para todo el sprint, con el objetivo de incentivar en el uso de JIRA, todos sabemos lo importante que es conocer la velocidad como equipo. Así como la realización de los StandUp matinales.

A continuación un cuadro resumen de:

• Bugs graves reportados por clientes durante el sprint. El objetivo es durante el sprint meeting repasar los bugs y mediante técnicas como 5whys identificar oportunidades de mejora
• Customer Earned Value. Valor generado al cliente durante el sprint
• Feature Speed. Tiempo requerido para liberar funcionalidades e indicencias

Por último, hemos iterado el Cardwall del equipo, para ilustrar las nuevas fases de nuestro LC. Dando visibilidad a todo el equipo tanto del trabajo del presente sprint, como de lo que está por venir en los siguientes sprints.

Una última novedad en el modelo de trabajo ha sido la de incluir un SCRUM MASTER rotativo, de manera que todo el equipo en mayor o menos medida tiene que involucrarse en el método, y en algún momento del año, en realidad en varios momentos, va a ser responsable de liderar al grupo.

Tengo que decir que ya, en tan solo un sprint de 2013 hemos empezado a notar un cambio de dinámica positiva. Una imagen vale más que mil palabras (Velocity Report JIRA) ... apoteósico el cambio en el LogOfWork del equipo.

Un abrazo,