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.

Agile para estudiantes / Agile for students

No hace mucho, el propietario de una empresa de software, alguien que no estudió ingeniería informática, me preguntó si yo lo había hecho. Cuando le contesté afirmativamente me preguntó qué era lo que se estudiaba en la facultad en el ámbito de la gestión de proyectos y la ingeniería de software. El contexto donde la pregunta fué formulada era inmejorable: un curso sobre SCRUM y metodologías de gestión Agile. No era yo la única que había estudiado la carrera, éramos en el curso una muestra representativa en cuanto a educación universitaria en informática se refiere. No es extraño que una discusión muy interesante siguiera.

La duda era cómo se podía incluir metodologías Agile en el plan de estudios de una facultad de informática. Y no tiene fácil respuesta.

El propietario de la empresa comentó que a finales de los años 80, los que como él ya trabajaban en el mundillo informático, viendo el desorden que había en los proyectos, creyeron que los estudios de ingeniería de software eran la solución. Se decía que uno de los objetivos de la carrera era la de formar a profesionales que dominasen metodologías ordenadas e “hiciesen las cosas bien”.

En efecto, a finales de los 80 y durante los 90 (yo me gradué en 1999) se estudiaba el modelo Waterfall en las asignaturas de ingeniería de software. No es extraño y refleja los estándares de la industria al respecto. Tampoco niego que es mejor el Waterfall a no utilizar ninguna metodología. Pero en el momento en el que nos encontramos, en el que las metodologías Agile están copando el mundo anglosajón y buena parte del europeo, quizás llegue el momento de revisar qué se está estudiando en nuestras universidades.

Durante mi época de estudiante, los profesores provenían predominantemente del ámbito académico. No se habían encontrado con los cambios de opinión del cliente, con las modificaciones a última hora o con tiránicas restricciones de tiempo y presupuesto.

Una alumna más joven que el resto y que había acabado la carrera recientemente, comentó que un profesor sí les había hablado de SCRUM y XP. Curiosamente, dicho profesor provenía del mundo corporativo y compaginaba las clases con labores menos académicas. Así que actualmente se estudian las metodologías Agile en la universidad, averiguamos los más veteranos. Nos quedamos satisfechos.

Pero luego una duda me asaltó. Vislumbré un potencial problema, arraigado en la forma en la que se enseña en las universidades. Mi preocupación es cómo al enseñar las nuevas metodologías a alumnos que aún no están en el mercado laboral y que no se han peleado con los problemas que Agile intenta solucionar, puedan ellos entender realmente los beneficios.

Pese a alegrarme al oír como el mundo de la enseñanza refleja como las empresas se adaptan a la realidad utilizando nuevas metodologías, ¿podrán los alumnos entender el porqué están proliferando estas metodologías? ¿su verdadero valor?

¿Cómo se puede hacer entender a un alumno lo que se va a encontrar en el mundo de la empresa? ¿No sería útil un modelo de prácticas más adecuado a la realidad? Los informáticos trabajamos, la mayoría de las veces, en proyectos. ¿No sería una buena idea que los profesores actuasen como clientes, cambiando los requerimientos, rechazando proyectos, etc.? De esta forma, en sucesivas asignaturas, los alumnos aprenderían a usar SCRUM y verían las ventajas que realmente aporta.

Curiosamente un alumno contó que uno de sus profesores (allá en los 80!) le rechazó una práctica y cuando él protestó, le contestó: “¿Acaso esperabas que la primera versión me gustase?”. A él se le quedó grabada la conversación por lo inusual. Y después, cuando se sumergió en el mundo laboral y se dió cuenta que era el pan nuestro de cada día, le dio a la actitud del profesor el reconocimiento que merecía.

Si no se hace así, me asusta pensar que los estudiantes verán SCRUM o XP como el modelo Waterfall. Una manera como otra de hacer las cosas. Le planteé mi duda a la chica que había estudiado XP en la facultad. Y ella me respondió que, precisamente, así lo había visto. Como una anécdota.

Not so long ago, the owner of a software company, who didn't study software engineering himself, asked me if I had studied the degree. When I said yes, he asked me what areas of project management and software engineering are covered in college. He asked me this during a SCRUM and Agile methodologies course. And I was not the only one there who had studied software engineering - some of the students had done so as well. So a very interesting conversation followed.

We discussed how we could include Agile methodologies in software engineering school.

The software company owner explained that during the late eighties, those who worked in the IT arena, looking at the mess that surrounded most of the projects, thought that studying software engineering was going to solve the problem. In university, people would get trained in the "proper way of doing things" and most of the problems when managing projects would disappear.

Effectively, during the 80s and the 90s (I finished college in 1999), the Waterfall approach was studied. It is not strange - it represented the standards of IT industry at the time. I can't say that studying Waterfall is worse that not studying any methodology at all. But nowadays, when Agile methodologies are becoming the standard in the IT world (in America and a significant number of European countries), maybe the time has arrived to review what it is being studied in our universities.

While I was a student, teachers were academics and rarely had worked in the corporate world. This meant that they had not really faced problems so important and common like the customer changing his mind, last time changes or very tight restrictions of time and money.

One of my students, who was significantly younger than the rest and had finished her studies recently, explained that one of his teachers did explain SCRUM and XP. Funnily enough, this professor came from the corporate world and taught in the university part-time, while still working in some companies. So, we learnt, Agile methodologies are effectively being taught in university! We were happy.

But afterwards, a question arose in my mind. A potential problem that dealt with the very same way of the educational model. How can we teach these new methodologies to students that have never worked and that have not "fought" the problems that Agile is trying to solve?

Although I am very happy to learnt that some teachers in universities explain how companies adapt to reality using new methodologies... how can students understand why these methodologies are becoming that popular? Their true value?

How can you explain to a student what he/she will find in the real world? Wouldn't be useful that, when students hand over their work to teachers, the teachers act like "customers"? IT Professionals work in project most of the times. Why don´t we treat the work that students have to do like small projects? That is, with teachers changing requirements, not signing off work done, etc? This way, even if students would get frustrated in the beginning (as most of us, IT professionals, do in corporate world!), they would really appreciate SCRUM afterwards. They would understand its true value.

Curiously, a student explained that one of his teachers back in university (in the eighties!) turned down one of his works. When he complained about it, the teacher replied: “Did you expect me to accept the first version?”. He has always remembered this because it was very unusual. And later, when he started working in the corporate world and realised that this kind of behaviour was common practice between customers / stakeholders, he realised that the teacher was behaving quite realistically and appreciated why he behaved like that.

With such an approach, I am afraid students will see SCRUM or XP like Waterfall. Just another way of doing things. I actually asked my student about what she thought of XP in university and she confirmed, funnily enough, that she did see XP as a "very curious thing".