Una Solución pre-Scrumban (II) / A pre-Scrumban Solution (II)

Como mencioné en el anterior post, voy a hablar un poco más del método pre-SCRUMBAN que he utilizado en proyectos anteriores.

Una variación era la de tener solamente 1 o 2 miembros de equipo con tareas Must y Should. Es decir, tener sólo a máximo un par de miembros como responsables de solucionar las incidencias de producción y otros problemas durante un Sprint. Normalmente, en nuestro equipo teníamos para ello a un perfil de desarrollador y a otro de testeador. A estos perfiles les llamábamos "Production Incidents Champion". Con el nombre, resaltábamos que sólo se solucionaban problemas de producción; es decir, el tipo de problemas en los que el tiempo de respuesta no puede ser de un Sprint y pico. El tiempo que se podía pasar en estas incidencias, como expliqué en el anterior post, venía predefinido con el número de story points de desarrollo que poníamos como Should.

Algunas ventajas de hacerlo así eran:

• Seguíamos con la filosofía SCRUM de tener equipos multidisciplinares, pues durante el Sprint al que le tocaba ser "Champion" debía solucionar las incidencias del producto, hablando con quien fuese necesario si no tenía los conocimientos suficientes.
• No "quemábamos" al equipo. Según mi experiencia, a la gente no le gusta mucho el rol de "Production Incidents Champion". Algo bastante lógico, por otra parte: generalmente ¡significa pelearse con problemas de solución difícil y urgencia muy alta! Rotando la figura entre los miembros del equipo, la carga se hacía más llevadera.
• Se distraía menos la dinámica de desarrollo del grupo en general. La mayoría continuaban trabajando en nuevos desarrollos "olvidándose" de los incidentes de producción durante los Sprints en los que no estaban nominados como "Production Incidents Champion".

Otro "refinamiento" del método consistía, después de varios Sprints utilizándolo, medir el tiempo real que se pasó resolviendo incidencias, hacer estadísticas y después ajustar con ellas el tiempo de soporte que se acordaba para un Sprint.

Idealmente, el tiempo medio debía ser menor al tiempo máximo que se había destinado = el número de story points marcados como Should. Se habían dado algunos casos de incidencias muy peliagudas, de difícil resolución, que se habían "comido" algunas horas de Must, pero en general el "Production Incidents Champion" realizaba todos sus Must (su Commitment), algunos Shoulds y resolvía alguna incidencia.

Finalmente, otra variación con la que jugamos era la de introducir Coulds. Las tareas Could eran una alternativa a "tomar las siguientes en el Product Backlog", por si algún miembro del equipo acababa su trabajo antes de la finalización del Sprint. No suponían una gran ventaja respecto al método tradicional, solamente que ya las estimábamos y asignábamos de antemano (planning poker).

As mentioned in previous post, I'll write a little more of the pre-SCRUMBAN method I have used in former projects.

A variation was to have only 1 or 2 team members with Must and Should work. That is, having at least a couple of members responsible for solving production incidents and other problems during a Sprint. Normally, in our team we had a developer and a tester in every Sprint: We would call them "Production Incidents Champion". With this name, it is highlighted that they were supposed to be the problem-solvers of the Sprint. The time available for these incidents, as explained in the previous post, was pre-defined, with the number of development story points that we had put as Should.

Some of the advantages of doing so were:

• We were loyal to the SCRUM philosophy of having multidisciplinary teams. When it was your turn to be "Champion", you should fix the problem whatever the area the problem was, talking to other team members if you didn’t know how to fix it.
  
• We didn't "burn" the team. From my experience people don’t like much the role of "Production Incidents Champion". Quite logical, because it usually meant fighting with difficult issues! Thus, rotating the task amongst team members, the burden became more bearable.
  
• More dynamic development and less distraction in new developments work. The team continued working on new developments "forgetting" to production incidents during the sprints in which they were not nominated as "Production Incidents Champions".
  

Another variation of the method was to measure the actual time spent resolving incidents, make statistics and then adjust them support time to be spent for Sprint.

The average time spent in support should be less than the maximum time that had been marked = number of story points marked as Should. There were some incidents that became very tricky and "ate" some hours of Must, but in general, the "Production Incidents Champion" performed all of its Must (the Commitment), some Shoulds and resolved some issues.

Finally, another variation was to introduce Coulds. Coulds were an alternative to "take the following task of the Product Backlog", if any team member finished his work before the end of the Sprint. They were not a great advantage over the traditional method, just that we had estimated and asignated them beforehand (planning poker).