Un buen SCRUM Master / A good SCRUM Master

Mucho se habla (sobretodo en los procesos de selección) sobre las cualidades que un buen SCRUM Master debería tener, aparte de los conocimientos técnicos.

Es un tema de vital importancia y como tal, se discute también en trainings, cursos de certificación y en muchos foros. Porque, como en todos los trabajos, a veces son las "soft skills" las más difíciles de evaluar. Cuando contratamos a un desarrollador de software, tenemos claro las habilidades técnicas que requerimos (Java, C++, SQL, lenguajes de scripting, etc...), pero a la hora de identificar las “soft skills”, muchas veces nos limitamos a listar una serie más o menos estándar, porque tampoco somos capaces de darles la justa importancia: Queremos a alguien con capacidad de comunicación, entusiasta y "team player". Seguro que las habéis leído en las ofertas miles de veces.

En el caso de un SCRUM Master, estas "soft skills" son aún más importantes si cabe. Precisamente son sus "soft skills" las que le harán tener éxito. Si el SCRUM Master ha sido en un pasado (o es todavía) jefe de proyecto, muchas de las cualidades que necesitará ya las ha tenido que poner en práctica. Pero si el SCRUM Master es un técnico, la cosa se complica.

Según mi experiencia, las cualidades que van a hacer que un SCRUM Master tenga éxito son:

• Ser un buen comunicador.
  
  La comunicación no es una parte importante... ¡es esencial! Se calcula que un 90% del tiempo de un jefe de proyecto es la comunicación. No conozco datos sobre qué % aproximadamente pasa un SCRUM Master comunicando (cuando ejerce como tal, no cuando hace otras tareas), pero me atreviría a decir que es un porcentaje similar.


• Ser "bueno" con la gente.
  
  Puesto que esta definición es demasiado amplia y abstracta, me concentraré en los rasgos que más importantes me parecen: Ser paciente, ser capaz de entender que cada persona es diferente, saber tratar con diferentes caracteres, saber escuchar y saber razonar. A veces se dice que ser SCRUM Master es un poco como ser el padre/madre del grupo. Y para los que tienen background de jefes de proyecto, este símil no les parecerá extravagante.


• Conocer bien la teoría de SCRUM.
  
  Sí, es importante. Por eso es recomendable que quien ejerza de SCRUM Master esté certificado o haya atendido alguna formación. Por ejemplo, es básico conocer y ser capaz de explicar la importancia del SCRUM diario. Si tenemos un miembro del equipo que sistemáticamente no atiende el SCRUM diario, no dejarlo pasar ("lo importante es que saca el trabajo adelante"), sino hacer hincapié, razonando, en que ciertas "reglas" de SCRUM hay que seguirlas. Por algo hay pocas.


• Y finalmente, ser expeditivo, o en otras palabras, ser bueno resolviendo problemas.
  
  Tener esa capacidad de "arreglar las cosas", y no me refiero a arreglar descalabros técnicos, sino situaciones comprometidas, obstáculos, dificultades de todo tipo. No en vano, una de las tareas más habituales del SCRUM Master (que se cita y se practica al obtener la certificación) es la de "quitar obstáculos" (en inglés "remove blockers / remove impediments"). Por cierto, que en este ámbito, tener una "lista de obstáculos pública" muchas veces ayuda. Da visibilidad.

There is much talk (especially when recruiting) on the qualities a good SCRUM Master should have, apart from technical expertise.

It is a vital issue and as such, is also discussed in Certified SCRUM Master courses, training courses and in many forums. Because sometimes the soft skills are the most difficult to assess. When we hire a software developer, we usually know exactly which technical skills we need (Java, C++, SQL, scripting languages, etc ...), but when it comes to soft skills, sometimes we just list a series of more or less standard qualities: For example, that we want someone with good communication skills, with enthusiasm and able to be a "team player". I am sure that you have read those in job offers thousands of times.

In the case of a SCRUM Master, it is a very different scenario. His/her soft skills are precisely what will make him/her succeed. If the SCRUM Master has been in the past (or still is) a project manager, he/she surely has practiced many of the qualities needed. But if the SCRUM Master is a software developer with no management experience, things get complicated.

In my experience, some of the qualities that will make a SCRUM Master be successful are:

• Being a good communicator.
  
  Communication is not just “important" ... it is essential! A project manager spends an estimated 90% of the time communicating. I don’t know what % of time a SCRUM Master spends communicating (when he/she acts as SCRUM Master, not when he/she is doing another tasks that might be part of his/her job), but I am sure that it is a very similar percentage.


• Being "good" with people.
  
  Since this definition is too broad and abstract, I will focus on traits that seem to me the most important ones: Be patient, be able to understand that each person is different, knowing how to deal with different characters, listening and being able to reason. Sometimes, it is said that being a SCRUM Master is a bit like being the parent of the group. And for those who have a project management background, this comparison won’t seem too strange!


• Knowing well the theory of SCRUM.
  
  Yes, it is important. It is therefore recommended that the person exercising as SCRUM Master is a Certified SCRUM Master (CSM) or has attended training on SCRUM principles. For example, it is essential to know and be able to explain the importance of daily SCRUM. If we have a team member who consistently does not attend the daily SCRUM, the SCRUM Master should not let it pass ("it does not matter if the team member does not attend daily SCRUM, what matters is that he/she gets the job done"). The SCRUM Master should emphasize why it is important that the SCRUM "rules" are to be followed (there are not that many, anyway!)
  


• And finally, be “a fixer”, or in other words, be good at solving problems.
  
  It is important to have the ability to "fix things" - and I don’t mean to fix technical setbacks, but to solve difficult situations and overcome obstacles of all kinds. Not surprisingly, one of the most common tasks of a SCRUM Master (as explained in training courses or when you get the certification) is to remove blockers / remove impediments. By the way, in this respect, having a "public impediment list” sometimes helps. It gives a lot of visibility to what needs to be fixed.

Estimaciones / Estimations

Es de sobras conocido que la estimación es una de las áreas más problemáticas en todo proyecto de software. Pero en esta entrada no quiero centrarme en los problemas más habituales cuando estimamos (cómo conseguir estimaciones lo más cerca de la realidad posible), sino en un punto directamente relacionado con SCRUM. Un punto en el que he visto, muchas veces, que hay confusión.

Por si fuera poco con los problemas intrínsecos de la estimación, cuando estamos empezando a trabajar con SCRUM surgen dudas, que yo llamo "logísticas", sobre cómo vamos a estimar. ¿En horas? ¿En puntos de historia? ¿Qué relación hay entre las unidades de estimación y estimar en tareas o historias de usuario?

Voy a explicar mi punto de vista, basado en mi experiencia. Pero quiero dejar claro que no hay un método estándar. Es cierto que algunas herramientas (estoy pensando en TFS) pueden predeterminar cómo entrar las estimaciones (por ejemplo en horas), pero no hay una fórmula mágica. Y esto es bueno, porque es flexible.

SCRUM te da la posibilidad de adaptar cómo estimamos a nuestra necesidad. En general, las historias de usuario se estiman en puntos de esfuerzo mientras que las tareas en horas.

Las historias de usuario forman el Product Backlog. Del Product Backlog, las escogeremos para nuestro Sprint (el Product Backlog está ordenado por prioridades del negocio) y compondremos con él el Sprint Backlog.

En la reunión de Sprint Kickoff, analizaremos las historias de usuario y refinaremos su estimación. Aquí es donde yo suelo descomponer las historias de usuario en tareas y asignar horas.

Es decir:

• Las estimaciones de las historias de usuario son más globales y las utilizo para dar estimaciones al negocio. Es muy útil en el caso que el negocio necesite tener buenas estimaciones del proyecto en sí: cuando, por ejemplo, es crítico cumplir plazos.


• Las estimaciones en horas por tareas las utilizaré para controlar el Sprint, con el Burndown Chart.

Esta es una forma de hacerlo, pero no la única. Por ejemplo, en un proyecto que realicé tuvimos suficiente con las estimaciones de historias de usuario, puesto que eran pequeñas, (de 1 o 2 días de duración), y no valía la pena dividirlas en tareas. Como en ese caso tampoco utilizábamos ninguna "herramienta sofisticada" para llevar el tracking del proyecto (nuestro Sprint Backlog era un fichero excel y nuestro Burndown Chart, un gráfico derivado de dicho excel), pudimos cambiar nuestro "modus operandi" y trabajar con puntos de esfuerzo sin mucha complicación.

En general es importante entender los conceptos básicos (historias de usuario, tareas, etc.), pero es más importante aún saber adaptarlas a tu entorno (necesidades del negocio, equipo, etc.). Y, muchas veces, cambiar: A veces el equipo puede tener dificultad estimando en puntos de esfuerzo por estar muy habituado a estimar en horas, mientras que otras veces, al cabo de poco, estimar en puntos de esfuerzo resultará más afinado.

It is widely known that estimation is one of the most problematic areas in any software development project. But in this post, I don't want to focus on the most common problems of estimation (how to obtain estimates as close to reality as possible), but on a question related to SCRUM that I've seen many times.

As if the problems of estimating were not difficult enough, when we begin to work with SCRUM a lot of questions on how to estimate arise. Questions which I like to call "logistical". Do we estimate in hours? In history points? What is the relationship between tasks and user stories?

Let me explain my point of view, based on my experience. But let me make clear that there is no standard method. It is true that some tools (I'm thinking TFS) can predetermine how to set the estimates (for example in hours), but there is no magic formula. And this is good, because it is flexible.

SCRUM gives you the ability to adapt how you estimate to your real needs. In general, user stories are with history points while tasks are estimated in hours.

User stories compose the Product Backlog. Then, every Sprint some user stories are chosen and compose the Sprint Backlog (the Product Backlog is sorted by business priorities).

In the Sprint Kickoff meeting, the user stories will be analyzed and assigned, and the estimations will be "refined" to make them more accurate. This is when I usually break the user stories into tasks and assign hours to them.

That is:

• Estimates of user stories (history points) are more global and I use them for the business. This is very useful when the business has the need for good estimates of the project itself: When, for example, is critical to meet deadlines.


• Estimates of tasks (hours) are more specific and I use them to track the Sprint (Burndown Chart).

As said, this is a scheme that has worked for me, but it is not the only one. In one project I worked, we had enough with user stories estimates, since they were small, (1 or 2 days), and it was not worth splitting them into tasks. As in that case we used no "sophisticated tool" to track the project (our Sprint Backlog was an excel file and our Burndown Chart, a graph produced from that excel), we changed our "modus operandi" and worked with history points without much hassle. But, I repeat, each case is unique.

In general, it is important to understand the basics (user stories, tasks, etc.), but it is more important to learn how to adapt it to your environment (business needs, team, etc.). And don't be afraid to change: Sometimes, the team might have difficulty estimating with history points as they are used to estimate in hours, while other times, after a short period of time, estimation with history points becomes simpler and more accurate.

Iteraciones / Iterations

Cualquier persona que empiece a leer sobre SCRUM se dará cuenta de la importancia de que las iteraciones (o sprints) tengan una duración determinada a lo largo de un proyecto. Fijar la duración de los sprints es uno de los pocos principios de SCRUM. Por ejemplo, no se puede variar, a medio proyecto, los sprints de 2 a 3 semanas, y después a 2 de nuevo. Crea confusión en el cliente y en el mismo equipo, y no ayuda a establecer un buen ritmo de trabajo.

Ahora bien, algo más complicado es decidir cuál es la mejor duración en cada caso.

Cuando me preguntan qué duración es la adecuada para una iteración SCRUM, siempre respondo que “depende del caso”. Es una respuesta imprecisa, con lo que quiero aprovechar este post para dar mis razones para no aconsejar una duración estándar de un sprint (sin conocer los detalles del proyecto).

Cuando estamos implantando SCRUM por primera vez, mi sugerencia (¡para esto y para tantas otras cosas!) es tomarnos nuestro tiempo entendiendo el entorno. Llegar como consultor expertísimo en SCRUM e intentar aplicar el proceso que te ha funcionado en otras ocasiones a un nuevo “ecosistema” es una receta para el fracaso. Muchas veces, la implantación de SCRUM se servirá de un proyecto prototipo. Considero aceptable variar la duración del sprint después de dicho prototipo (¿para qué nos sirven los proyectos prototipos si no es para probar?). Pero, cuando se haga un despliegue de la metodología a nivel departamental o de toda la compañía (o sea, incluyendo múltiples proyectos), sería adecuado mantener sprints más o menos similares, porque ayuda a una mejor comprensión a nivel organizativo de SCRUM y de cuando esperar resultados.

En general, se debería tener en cuenta:

• Procesos organizativos y entorno


• ¿Es un producto interno o para un cliente externo?


• ¿Qué procesos de autorización existen para ponerlo en producción? Por ejemplo, los complicados procesos que pueden existir en un entorno bancario o en según qué clientes externos, incluyendo departamentos de operaciones, etc.


• Disponibilidad del cliente


• Número de usuarios


• Necesidades de formación cada vez que se lanza una nueva release


• Localización / disponibilidad en general


• Naturaleza de la solución (producto realizado)


• ¿Cuán urgente es la necesidad de nuevas funcionalidades?


• Madurez del equipo de desarrollo


• Conocimiento de SCRUM, cómo de multidisciplinares sean sus miembros, etc.


• ¿Cuál es la capacidad de utilización / reacción / tolerancia de los usuarios a las nuevas iteraciones?

En resumen, no es lo mismo realizar un producto para un grupo de usuarios internos que lo conozcan bien y sólo necesiten una mínima formación que no, por ejemplo, una release de software bancario para un cliente externo en el que son necesarios un par de días de pruebas más formación y documentación para los usuarios, etc. En el primer caso se podría pensar en iteraciones de incluso 1 semana, en el segundo, de 1 mes. Y según mi opinión, ninguna sería más correcta que la otra.

Anyone who starts reading about SCRUM will realize the importance that iterations (or sprints) have a fixed duration during a project. It is one of the few SCRUM principles to maintain a fixed sprint duration. For example, it is not a good idea to have sprints of 2 weeks and, in the middle of a project, change them to 3 weeks, only to change them back to 2 weeks afterwards. It creates confusion in the customers and it does not help to establish a good pace within the development team.

But to decide this sprint duration is somewhat more complicated.

When I am asked about what is the appropriate duration for an iteration in SCRUM, I always reply that "it depends on the case". It's a vague answer, so I will use this post to explain my reasons behind not recommending a standard duration of a sprint (without knowing the details of the project).

When you first implement SCRUM, my suggestion (for this and many other things!) is to take your time and understand the environment. Being hired as a SCRUM coach and try to apply the same process that has worked for you in the past to a new "ecosystem" is a recipe for failure. Many times, the implementation of a SCRUM project will use a prototype. I consider acceptable to vary the length of the sprint after this prototype (why do we use prototypes, if not to experiment?). But, when deploying SCRUM to other departments or even company-wide (i.e., including multiple projects), you should have defined similar sprints. It helps the organisation to understand better how SCRUM works, and what to expect.

In general, when deciding sprint duration, you should consider:

• Organizational processes and environment


• Are you building an internal product or do you have external customers?


• What authorisation processes exist? How do things get deployed into Production? For example, the complicated processes that exist in banking, operation departments procedures, etc.


• Customer Availability


• Number of users


• Training needs whenever a new release is launched


• Location / availability in general


• Nature of the solution (product)


• How urgent is the need for new features?


• Maturity of the development team


• Knowledge of SCRUM, skills and competencies of the members, etc.


• What is the reaction / tolerance of users to new iterations?

In summary, it is not the same to develop a product for a group of internal users who know it well and need basic or no training at all, than building software for external customers who need a couple of days of testing plus training and user documentation, etc. In the first case we could think of 1-week iterations in the second case, 1-month iterations. And in my opinion, one option won’t be more correct than the other.

Introducción a Agile Testing / Introduction to Agile Testing

El tema de cómo testear software siempre levanta mucha polémica, pero cuando entramos en un desarrollo Agile, hay además bastante confusión. La pregunta que he escuchado en más ocasiones es la de: ¿Cómo vamos a involucrar a un testeador desde un principio, si el desarrollo no está acabado?

Para resolver esta duda, hay que empezar mencionando que Agile es una metodología que pone mucho énfasis en la calidad. La calidad entendida no sólo como calidad del código (sin bugs, bien diseñado, etc.) sino como proceso global: Lo desarrollado es útil al negocio, responde a las expectativas cambiantes, se pone en producción en iteraciones relativamente cortas, etc.

Por eso, porque la calidad es algo que se mantiene en todo momento, un testeador se involucra desde el principio de la iteración. No se pone a trabajar sólo los dos últimos días del ciclo (como he oído en algunas ocasiones).

En general, un testeador:

• Colabora con el Product Owner para definir las condiciones de aceptación.


• Muchas veces, en esta fase se descubren "puntos oscuros" que ni el Product Owner tiene del todo claro. ¡Considero que esta parte es vital!


• El testeador se encarga de que las user stories sean claras y tengan sentido. Es en esta parte donde cobra importancia lo mencionado antes de la calidad no sólo entendida como código bien escrito.


• Crea los planes de test, los casos de test y los planes de regresión, a partir de dichas condiciones de aceptación.


• Se encarga de los entornos de test y del proceso de build (y muchas veces de los repositorios de código).


• Se encarga de la automatización del test.


• Testea.


• Informa de los resultados para estadísticas, análisis, etc. ¡Los testeadores suelen ser una parte importante de las sprint retrospective!

Por supuesto, hay múltiples variaciones, dependiendo del perfil de los testeadores con los que se cuente, pero los puntos mencionados antes son los que yo considero básicos cuando se habla de test en un entorno Agile.

How to test software is always a tricky subject, but when you develop software using Agile methodologies, often there are also misunderstandings. The question I’ve heard more often is: How are we going to involve a tester from the beginning of the cycle, if the code is not ready?

To answer this question, we must keep in mind that Agile is a methodology that puts great emphasis in quality. Quality understood not only as code quality (no bugs, code well designed, etc.) but as a global process: The code is useful to business, responds to changing expectations, is delivered to production in relatively short iterations, etc.

Therefore, because quality is something we focus in all the time, a tester is involved from the beginning of the iteration. The tester does not work only during the last two days of the cycle (as I have heard in some cases!).

In general, a tester:

• Collaborates with the Product Owner to define the acceptance criteria.


• Often, during this, "dark areas" that not even the Product Owner is clear on are discovered. I think this part is vital!


• The tester ensures that the user stories are clear and meaningful. Here is where the concept of quality not only as well-written code makes more sense.


• Creates the test plan, test cases and regression test plans, based on these acceptance criteria.


• Is responsible for test environments and build process (and often code repositories).


• Is responsible for test automation.


• Tests.


• Gathers and reports the results for statistics, analysis, etc. Testers are often an important part of the sprint retrospective!

Of course, there are multiple variations to this depending on the skills of the testers in the team, but I consider the responsibilities mentioned above as the basic ones when we are in an Agile development environment.

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

Una Solución pre-Scrumban / A pre-Scrumban Solution

Hace unos meses, leyendo las aportaciones de la comunidad española que trabaja con prácticas ágiles, me topé por primera vez con el término “Scrumban”. A partir de allí me leí el estupendo paper de Kanban vs SCRUM, y me alegré al saber que compartía problemas con ellos y podía leer sobre sus soluciones.

En este post, voy a centrarme en un problema que me he encontrado en el pasado y en una solución que adopté, y en siguientes posts voy a estudiar cómo se relacionan con las tendencias Scrumban que mis compañeros de agilismo están explorando.

En proyectos en los que he implantado SCRUM, había una serie de problemas recurrentes. Uno de estos problemas era qué hacer cuando el equipo de desarrollo también realiza tareas de soporte. Muchas veces, el equipo de desarrollo no sólo tiene que desarrollar nuevas funcionalidades, sino también arreglar bugs y realizar soporte puro y duro. En compañías grandes, los equipos suelen estar diferenciados, pero cuando se trata de empresas pequeñas, los desarrolladores tienen que contestar el teléfono y “apagar fuegos”.

El problema con SCRUM es que no permite incluir tareas nuevas cuando un Sprint ha empezado. Esto no es una restricción caprichosa, pues tiene un buen fundamento: hay que acotar el nivel de cambio dentro de un equipo para poder entregar el paquete de software prometido a final del Sprint. Si estamos cambiando continuamente el alcance de un Sprint, los conceptos de velocidad y compromiso por parte del equipo a entregar lo acordado para ese Sprint, se pierden. ¡No vamos a comprometernos a entregar algo que no sabemos qué es!

Pero si el equipo de software también tiene que ofrecer soporte... ¿cómo podemos decirle a un cliente (usuario, manager…) que tiene que esperar a que el Sprint se acabe para solucionar el problema? Aunque el problema sea urgente, tendrá que esperar a que el Sprint acabe, se priorice la solución en la pila de producto (por el Product Owner) y finalmente, se entregue al final del Sprint siguiente (supongo que, como el problema era urgente, el Product Owner lo prioriza). En el mejor caso, si el problema sucede el último día de un Sprint, el tiempo de respuesta seria la duración del siguiente. Y en el peor, si sucede el primer día del Sprint, dos veces esta duración. E incluso podríamos calcular un tiempo medio de respuesta, haciendo estadísticas de cuando suceden los problemas durante un Sprint en nuestra compañía, calculando su distribución temporal y obtener un tiempo medio de finalización del Sprint en curso (al que sumaríamos después la duración del siguiente). Sea como sea, esto no funciona si el problema es realmente urgente y se debe solucionar.

En un pasado, yo utilicé un método “híbrido”: bajábamos la velocidad de equipo de forma artificial para dejar un buffer para “soporte”. Hay que recordar que en SCRUM, los equipos son multifuncionales y por lo tanto todos los miembros del equipo podían realizar soporte. Definíamos una serie de tareas del Product Backlog como “opcionales”, utilizando una versión reducida del Moscow Method:

- Tareas M “Must”: conformaban el Sprint, el compromiso del equipo.
- Tareas S “Should”: estas tareas se realizarían si no había tareas de soporte. En caso de que surgieran dichas tareas, las tareas “Should” podrían descartarse. No formaban, a priori, parte del compromiso del equipo con el cliente.

Este método no es perfecto, pues también limita la capacidad de soporte del equipo, pero dicha capacidad máxima de soporte era algo que se acordaba con los clientes/usuarios. Por ejemplo, “el equipo dedicará un máximo de 20% a soporte”. Entonces “Tareas Must” = Compromiso = Velocidad - 20%. Si no se realizaban tareas de soporte, el equipo debía realizar las tareas “Must” y “Should”. Las soluciones de bugs se ponían en producción cuando el Sprint finalizaba, con lo que el tiempo de respuesta se reducía.

A few months ago, reading the contributions of the Spanish community working with agile practices, I first encountered the term "Scrumban". Afterwards I read the great paper of Kanban vs. Scrum, and I was glad to realise that I had similar problems than those they had, and I could read the solutions they propose.

In this post, I will focus on a problem I've encountered in the past and I a solution I once adopted, and in following posts I will explore how this relates to the trends my fellow agile buddies are exploring

In projects where I have implemented SCRUM, there were a number of recurring problems. One of them was what to do when the development team also performs support tasks. Often, the development team must not only develop new functionality, but also fix bugs and offer support. In large companies, teams are normally different, but when it comes to small businesses, developers have to answer the phone and "put out fires".

The problem with SCRUM is its inability to include new tasks when a Sprint has started. This is not a capricious restriction, as it has a good reason: we must limit the level of change within a team, so it can deliver the promised software package at the end of the Sprint. If we are constantly changing the scope of a Sprint, the concepts of speed and commitment to deliver are lost. We cannot commit to deliver something if we do not know what is!

But if the software team must also offer support... how can we tell a client (user /manager...) that has to wait until the Sprint is finished to get the problem fixed? Although the problem is urgent, the user has to wait for the Sprint to finish, for the Product Owner to prioritize the solution in the Product Backlog and finally, for the next Sprint to finish (I am assuming that, since the problem was urgent, the Product Owner will prioritise it). Best case scenario, if the problem happens on the last day of a Sprint, the response time would be the duration of the next Sprint. Worst case, if it happens the first day of Sprint, twice this duration. We could even calculate an average response time, by collecting statistics of when problems occur during a Sprint in our company and get an average time for the current Sprint (which would add after the duration of the next). Anyway, this does not work if the problem is really urgent and must be fixed.

In the past, I used a “hybrid” method: we artificially lowered the velocity of the team, to have a buffer for "support”. We have to keep in mind that in SCRUM, teams are multifunctional and therefore all team members could perform support. tasks. We then identified a number of tasks of the Product Backlog as "optional", using a reduced version of the Moscow Method:

- Tasks M "Must": as the Sprint, the team's commitment.
- Tasks S "Should": these tasks would be made if there was no support tasks. In the event of any such tasks, the tasks "Should" could be dismissed. They were not, a priori, part of the team's commitment to the customer.

This method is not perfect; it also limits the ability to support the team, but the capacity of the team for support was something that was agreed with customers/users. For example, “the team will spend up to 20% for support”. Then “Must tasks” = Commitment = Velocity - 20%. Although, if no support tasks were performed, the team was expected to fulfil “must” and “should” tasks. This way, the support fixes were put into production when the Sprint ended, and the response time was reduced.

Miedo a la libertad / Fear of freedom

El otro día oí a una psicóloga explicar que la historia de la humanidad, desde un punto de vista sociológico, viene marcada por alternancias de movimientos que, respectivamente, reclaman más libertad del pueblo o “piden” más control. Después de épocas en las que florecen las libertades, el género humano parece decantarse por regímenes dictatoriales. La explicación ofrecida me llamó la atención: ante una libertad a la que no estamos acostumbrados, sentimos una necesidad de control, un alivio al dejar que se tomen las decisiones por nosotros. La responsabilidad asociada a nuestra libertad nos abruma.

Pensé en un problema que aparece a veces en los equipos en los que se introduce una metodología ágil. El equipo experimenta una sensación de más libertad y de más responsabilidad que en un típico grupo “jerárquico” donde el líder técnico o el gestor de proyecto te dicen qué hacer y cómo hacerlo en todo momento. Equipos auto-gestionados. ¿Todos contentos? Al contrario.

Muchas veces los miembros del equipo se asustan. No se sienten cómodos, no sólo con el cambio (¡el miedo al cambio podría y seguramente inspirará otra entrada!), sino también a la novedosa libertad. Escuchar a la psicóloga hablar del miedo a la libertad a nivel sociedad me hizo darme cuenta de que es un miedo fundado, racional, que no debe ser despreciado.

Cuando se trata de miedos muy arraigados en la consciencia de cada uno, pretender que con un par de frases en una presentación de equipo se van a solucionar es un gran error (error que, sin embargo, he visto muchas veces). “Vamos a ser todos ágiles – ¡veréis qué bien!”. No; hay que hacer un esfuerzo continuado, de seguimiento, de cada miembro del equipo. Ayudarles a que vayan tomando responsabilidades de forma progresiva. Cada persona es un mundo y uno de los problemas más habituales es obviar esto por falta de tiempo y tratar al equipo como un “todo” en la delicada materia de cambiar la forma de trabajar.

Una técnica que funciona bien es tener con cierta regularidad reuniones one-to-one con cada miembro del equipo. No vale ahorrárnoslas porque todo parece ir bien o por demasiado volumen de trabajo; y sobre todo en las primeras etapas del cambio. Si el SCRUM Master es el gestor del proyecto (o sea, el jefe inmediato), este caso es ideal, porque ya se suelen tener reuniones one-to-one. Además, tendrá la autoridad para tomar decisiones si llegan a ser necesarias.

Pero todos sabemos que el SCRUM Master no siempre es el gestor del proyecto, es más, muchas veces es aconsejable que no lo sea. En este caso, debería hacerse otra reunión de frecuencia variable con el SCRUM Master, porque en el típico one-to-one con el jefe el SCRUM Master quedará fuera. Una reunión para que el SCRUM Master pueda entender, persona a persona, sus miedos respecto al cambio, las situaciones particulares en las que se sintieron demasiado presionados, etc.

Finalmente, mencionar que otro problema importante con el que me he topado al introducir SCRUM es la presión del grupo. El típico ejemplo: ¡todo el mundo parece tan encantado de trabajar ágilmente! Algún miembro tiene sus reticencias, pero no se atreve a hacerlas públicas durante una reunión con todo el equipo por la famosísima presión del grupo o peer pressure: “No quiero que me tachen de waterfall”. Otro buen ejemplo de porqué las reuniones one-to-one son tan importantes es porque en estas conversaciones es cuando se desenmascaran los miedos de cada uno y se pueden solucionar los problemas.

The other day I heard a psychologist explain how the history of mankind, from a sociological point of view, is defined by alternating movements: respectively, tendencies demanding more freedom and tendencies “asking” for more control. After times of unusual freedom, humanity seems to opt for dictatorship. The explanation struck me: confronted with a feeling of freedom we are not used to, we feel a need to be controlled and have the relief of having others make decisions for us.The liability associated with our freedom overwhelms us.

I thought of a problem that sometimes appears when introducing agile methodologies. The team has a sense of having more freedom, more responsibility, as opposed to being in a typical "hierarchy" where the technical lead or project manager is telling you what to do and how to do it, at all times. Self-managed teams. Is everyone happy? On the contrary.

Often, team members are scared. They don’t feel comfortable not only with the change (the fear of change can, and will, inspire another blog entry!), but also with this new freedom. Listen to the psychologist talk about the fear of freedom made me realize that it is a well-founded fear, rational, and should not be neglected.

When fear is deeply rooted in the consciousness of each, thinking that a couple of sentences in a team presentation will solve the problem is a large error (error that, however, I have seen many times). “We'll all be agile - and you will see how cool it is!” It does not work like that. We must make continued efforts, tracking each team member’s progress. Help them to gradually take responsibility. Each person is different, and one of the most common problems is to obviate this and treat the team as a "whole" in the delicate matter of changing the way we work.

One technique that works well is to have one-to-one meetings with each team member, regularly. It is not worth skipping them because everything seems to go well or because of a heavy workload, especially in the early stages of change. If the SCRUM Master is also the project manager (i.e., the immediate boss), this case is ideal, because you usually have meetings one-to-one. You also have the authority to make decisions if they become necessary.

But we all know that the SCRUM Master is not always the project manager, and, moreover, many times it should not be. In this case, you should have another meeting between the SCRUM Master and every member of the team, because in the typical one-to-one with the boss, the SCRUM Master will be left out. A meeting so the SCRUM Master can understand each person’s fears about change, see particular situations in which they felt quite depressed, etc.

Finally, just say that another major problem I encountered when introducing SCRUM is peer pressure. The typical example could be one like follows: “Everybody seems so happy to work agile! I am not, but I don´t dare to make it public during a meeting with the team as I do not want to be accused of being waterfall!". This is another good example of why the one-to-one(s) are so important, because in these conversations, people don’t feel peer pressure and we can solve more problems.