Introduciendo SCRUM / Introducing SCRUM

Hace poco me pidieron crear un plan para introducir una metodología ágil (SCRUM) a nivel de toda una organización. Puesto que resumí en un plan de 5 pasos mis experiencias (y las mejores prácticas de otros autores), quiero compartirlo en el blog por si a alguien le resulta útil.

Así que, ¿quieres cambiar tu organización? Si eres un agile coach o evangelist, yo te sugeriría...

1) Estudia la situación

• Identifica quién está a favor y quién en contra: ¿Quién quiere el cambio? Y, por otra parte... ¿qué es lo que se quiere cambiar? A veces, algunas personas sólo quieren dejar de hacer "tanta documentación", otros quieren "una gestión más libre", mientras que otros quieren... todo lo contrario!


• Establece espacios abiertos, cuestionarios, foros. En este punto, toda la información que se obtenga es extremadamente valiosa.


• Obtén ayuda! Lo ideal es conseguir consultores externos (estos consultores no tienen miedo a ser despedidos y suelen decir lo que piensan!) y buenos agile trainers (a veces, los consultores serán los trainers!). Aportarán experiencia (ellos ya han estado allí antes) y darán confianza al equipo cuando tenga problemas.


• Establece las expectativas correctas: Seas tú o un consultor externo, se necesitará algún tiempo para analizar la situación y diseñar la mejor estrategia. No se pueden cambiar las cosas desde el primer minuto!

2) Empieza con un piloto

• Elije el equipo adecuado para hacer el piloto. No escojas un equipo que ofrezca resistencia o un equipo con miedo al cambio. Elije un equipo que haga del piloto una historia de éxito. La idea del piloto es convencer al resto de la organización que SCRUM funciona! El primer paso (análisis) te ayudará a elegir el equipo adecuado.

3) Comunica y capacita

Establece un proceso de comunicación y formación para otros equipos desde el principio.

Comunicación:

• Haz la buena información más visible que la mala información, con actualizaciones por correo electrónico, presentaciones, etc. Da a conocer "quick wins" y pequeñas victorias!

Formación:

• Prepara formaciones basadas en historias de éxito de lo que está ya ocurriendo. La idea es que los otros equipos participen en el cambio y quieran empezar con SCRUM.


• A veces, además de la formación de los equipos, es útil designar a "champions" dentro de cada equipo, personas que te ayudarán a hacer el cambio.


• Forma a los altos directivos y mandos medios por separado. Realizan funciones distintas y tienen problemas muy diferentes!

Equipo SCRUM de introducción:

• Algunos autores abogan por un equipo de gerentes diseñado para "eliminar los obstáculos" en el proceso mismo. Yo estoy a favor. Si estamos llevando a cabo un cambio en toda la organización, tendremos que quitar "blockers" por el camino, así que, ¿por qué no utilizar el paradigma de SCRUM a un nivel superior?

4) Despliega SCRUM a otros equipos gradualmente

• En primer lugar, identifica la velocidad correcta de despliegue (por ejemplo, cuantos equipos por mes, etc)


• Poco a poco ve desplegando SCRUM a los otros equipos, en consonancia con el programa de comunicación y de formación mencionados en el paso 3.


• No te olvides del departamento técnico! A menudo es el punto de fallo de estas implementaciones!

5) Comunicación final

• A medida que se acerca el final del despliegue a nivel organizativo... prepara bien la comunicación final de resultados: Ha sido difícil, lo que queda seguirá siendo difícil (SCRUM es un cambio constante!), pero los buenos resultados superarán los problemas!

I was recently asked to put together a plan to introduce Agile methodology (SCRUM) organisation-wide. Since I summarised my experiences (and best practices from other authors), I thought it would be useful to share it.

So, do you want to change your organisation? If you are an agile coach or evangelist and you find yourself in that scenario, I would suggest you...

1) Study the situation

• Identify supporters: Who wants to change? And, moreover… what do they want to change? Sometimes, some people just want to drop "documentation", others want "more self-management", while others… want just the opposite!


• Set up open spaces, questionnaires, forums. At this point, all information is extremely valuable.


• Get help! Ideally, get consultants in-house (consultants are not afraid of being "made redundant" and speak their mind!) and good agile trainers (sometimes, the consultants will be the trainers!). They will bring experience (they have been there before) and will give confidence to the team when they encounter problems.


• Set the right expectations: Consultant(s) will need some time to analyse the situation and design the best strategy. Don’t expect them to go changing things from the very first minute!

2) Start with a pilot

• Choose the right team to do the pilot. Don’t go for a team that offers resistance, don’t go with a team afraid of change. Choose a team that will make the pilot a success story – The idea of the pilot is to convince the rest of the organisation that SCRUM works! The first step (analysis) should help you in choosing the right team.

3) Communicate and train

Set up a communication and training process for other teams from the beginning.

Communication:

• Make good information more visible than bad information, with email updates, presentations, etc. Publicize quick wins and small victories!

Training:

• Aligned with communication, prepare trainings based on success stories happening already. The idea is to involve other teams in the change and make them want to start with SCRUM.


• Sometimes, apart from training the teams, it does help to designate "champions" within the teams, people who will help you making the change happen.


• Communicate and train top managers and middle managers separately. They perform different functions and have very different problems!

SCRUM introduction team:

• Some authors also advocate for a team of managers designed to "remove impediments" in the process itself. I think this can be very valuable! If you are undertaking an organisation-wide change, you will need to remove blockers along the way, so why not use the SCRUM paradigm at a higher level?

4) Gradually roll out SCRUM to other teams

• First, identify the correct speed of rollout (how many teams per month, etc.)


• Gradually roll out SCRUM, aligned with the communication and training program mentioned in step 3.


• Don’t forget technical dept.! It is often a point of failure for implementations...

5) Final communication

• As the end of the rollout approaches, prepare for properly communicating the results: It has been hard, it will still be hard (SCRUM implies continuous change!), but the good results are outweighing the problems!

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).