Ajedrez - antoniomartel.com

Archivos por Etiqueta: SCRUM

Lecciones aprendidas en la implementación de Scrum

La semana pasada escribía sobre las lecciones que había aprendido en la gestión de mis propios proyectos. Les dejo esta semana con un vídeo de la charla que Jeff Sutherland dio a los ingenieros de Google sobre sus lecciones aprendidas en la implementación de Scrum en lugares como Nokia, PatientKeeper o la propia Google. Les cuento en este post algunas de las cosas que me parecieron curiosas:

  • En Google se introdujo Scrum poco a poco por temor a la resistencia de sus ingenieros que podían pensar que introducir un proceso formal no les beneficiaría sino que les ralentizaría en su trabajo. Comenzaron la implementación de Scrum usando solo las prácticas más básicas.
  • Hubo incluso resistencia para las reuniones diarias para las que también pensaban que sería un tiempo invertido en vano. Comenzaron por reuniones que duraban mucho más de 15 minutos ya que cada ingeniero tardaba mucho tiempo en explicar lo que estaba haciendo y los problemas que estaba teniendo. Después de un tiempo, cuando todo el mundo había explicado su trabajo y era consciente del de los demás, las reuniones fueron mucho más fluidas.
  • La gráfica burndown les ayudaba a darse cuenta de cuál era el tiempo real que iban a emplear en desarrollar una funcionalidad. Para una funcionalidad a la que inicialmente asignaron un tiempo de 3 semanas y 40 puntos comprobaron que en la primera semana hicieron solo 8 puntos. En la segunda consiguieron terminar solo 7,5 puntos. Aún así, uno de los responsables pensaba que tendrían la funcionalidad lista en esas 3 semanas cuando la gráfica hacía evidente que no estaría en ese tiempo.
  • En un proyecto para el sector sanitario, usado por cientos de doctores y usuarios online, la definición de Hecho (Done) se fue ampliando desde pasar inicialmente por los test unitarios y de aceptación para luego añadir a la definición de verdaderamente Hecho o Terminado algo como ésto: ‘Poner en producción y si el teléfono no suena con incidencias durante 1 hora la nueva entrega estaba completa’
  • Para mi alivio, en su Scrum inicial simplificado no usaban gráfica burndown por cada iteración sino una por cada entrega. Esto me hizo sentir mejor ya que yo no había podido nunca mantener un tablero Kanban actualizado a diario para cada Sprint (sí, ya sé, Scrumbutophobia)

5 lecciones aprendidas en la gestión de proyectos

Siempre que acabo un proyecto procuro hacer balance de lo que fue mal o de lo que fue bien en él, de lo que intenté y no funcionó o de lo que debo anotarme para no volver a hacer. Incluso cuando el balance final lo he considerado negativo, puede que el proyecto haya merecido la pena si en el siguiente proyecto no vuelvo a cometer los mismos errores.

De algunos de esos balances he extraído aquí cinco de las lecciones más importantes que he aprendido. Algunos son errores de principiante, otros los debería haber resuelto la simple lógica pero no me resultaron tan evidentes cuando estaba en ello. Ahí van:

La agilidad funciona

Es difícil de cuantificar pero desde que comencé a usar Scrum en mis proyectos, el número de horas invertidas por funcionalidad bajó y en mi opinión lo hizo bastante. Simplemente haciendo el seguimiento diario durante 15 minutos, mantener la gráfica del estado del proyecto que nos indica si vamos bien o no y las entregas cada dos semanas nos permitieron obtener el 80% de las ventajas de Scrum. Además, a los clientes parecía aportarles cierta tranquilidad que de forma consistente cada dos semanas se entregara y mostrara lo que se había acordado dos semanas antes. En los meses de julio y agosto, cuando no eran posibles las reuniones, el envío semanal de un simple documento de dos páginas con el porcentaje de realización de cada funcionalidad y dos párrafos explicando el porqué de esos porcentajes, ayudó a recuperar credibilidad en un proyecto difícil (especialmente cuando en septiembre se pudo comprobar que los porcentajes eran reales)

Todo no es positivo en Scrum

Se requiere de bastante más dedicación del Scrum Master de la que tendría si solo jugase el papel de jefe de proyecto. En esos 15 minutos de seguimiento diario te van a contar un montón de dificultades que se necesitan resolver para seguir avanzando. Intentar resolverlas te va a llevar el resto de la mañana.

Por otro lado, tener una entrega cada 2 semanas puede ser agotador. No se puede estar esprintando durante meses. Al cabo de seis meses se termina trotando (y eso con suerte) Es necesario tener esto en cuenta desde la primera planificación.

Por último, y no por ello menos importante, Scrum no es magia. Uses la metodología que uses necesitarás un equipo formado en el trabajo a realizar, dispuesto a arrimar el hombro y con ganas de aportar. Equipos así no crecen en los árboles. Si cuentas con uno, la misión del jefe de proyecto será estorbar lo menos posible.

Incorporar más trabajadores al equipo no consiguirá más que ralentizarlo

Bueno, esto ya se decía desde hace un montón de años en el libro The Mythical Man-Month. Aún así es necesario recalcarlo, no hay excepciones a la regla. No importa lo ajustado que sean los plazos: nueve personas no pueden crear un bebé en 1 mes.

¿Quién es el dueño de todo esto?

Da igual cómo lo llamemos: identificar a los interesados, designar el product owner o hacer partícipes a los stakeholders. Al final necesitaremos saber quién va a validarlo en realidad. Y no me refiero a quién va a firmar la factura. Necesitarás conocer también a quién va a usar el producto. El proyecto sólo será un éxito si después de entregarlo funciona y es útil.

En algún proyecto el director de área nos facilitó toda la documentación, validó las entregas parciales, testeó toda la aplicación y nos felicitó por el trabajo realizado. Lamentablemente, cuando su secretaria acudió a la sesión de formación una semana antes de la puesta en producción nos dijo: ‘Esto no me sirve: esa ya no es la plantilla correcta y necesito recoger datos diferentes de los que ahí pone’. Esto significó una semana de horas extra y esfuerzo adicional además del riesgo de poner en producción un producto que podría ser inestable.

Producto Mínimo Viable

Si ya tienes algo que puede ser útil al usuario, entrégalo, ponlo en producción, sácalo a la venta. No esperes a tener todas y cada una de las funcionalidades terminadas. Si recuerdas el principio de Pareto con sólo el 20% de ellas conseguirás completar el 80% de los usos que tendrá tu producto.

Cuando esté en producción comenzarás a obtener las impresiones de los usuarios. Ellos sabrán con mayor exactitud qué es lo que de verdad necesitan y tú sabrás qué has hecho mal y cómo puedes mejorarlo. Si apuestas por una única entrega final sólo cuentas con una única bala para acertar en la diana (haber hecho esto nos habría ahorrado un montón de problemas con el producto mencionado en el punto anterior)

Estas son mis lecciones aprendidas. Espero que a alguien le sirva de ayuda como lo hizo para mí.

Si te interesa saber más sobre la certificación, estimaciones, ventajas y desventajas de Scrum o cómo gestionar proyectos de forma ágil quizás te interese mi libro: Gestión práctica de proyectos con Scrum.

Libro Gestión práctica de proyectos con Scrum

SCRUM Pros and Cons

If you are considering SCRUM as a working method but you do not know very well what SCRUM is all about. You’ve heard a lot of people talking about the benefits of this system but, how many technologies and techniques have appeared quickly and disappeared even faster? All of them promised to be revolutionary. When we hear so much hype about a new one we bow in critical eyebrow .

A few months ago I published a prezi to explain the advantages and disadvantages of implementing SCRUM in an organization (I tried to be impartial, I promise):

In this post I will explain this prezi using words instead of pictures.

The team may be tempted to take the shortest path

You have to deliver things every two weeks. At the last delivery the team was not able to complete all planned functionality. The team velocity does not predict that you will finish on time this time. It is then when a new problem arise: the team may be tempted to resolve pending tasks in a hurry leaving behind them technical ‘debts’. Apparently everything goes well, more functionality made​, new ones are started, and the customer is happy because they are on schedule.

But whenever a blur is left behind you can be sure that you will have to face it sooner or later. If new things are built on this blot, the ‘debt’ begins to multiply. Soon you’ll have to stop everything and commit to repay the debt (with interest rate). The project does not come to an end when there was little to finish it: burndown chart seems to have a horizontal asymptote at 0 (sorry, some Maths)

Do you need dates of delivery well in advance?

This is one of the most common critics to SCRUM. In a way it makes sense, it is not possible to predict when you’re going to end if what you are going to build may change and vary over time. But do you prefer a product that is known with certainty to be completed in 10 months but it is built on the ideas and opinions you had 10 months ago? Maybe you prefer a product that could be finished within similar time but it can evolve to your real needs.


Stress!

We can not spend our lives sprinting. As soon as we deliver a new functionality, we are committed to the following one, which is only a couple of weeks away. Then another and another one. If we had to travel many miles, we can begin with a quick sprint to reach the first goal but we’ll be walking slowly to reach the last one.

Is your team self-organized?

One of the principles of Scrum is that the team should make their own decisions and manage themselves. Furthermore, it requires that there is no members of the team focused only in specific tasks such as analysis or testing. Inside the same team you should have someone able to test, to code, to write a specification, to analyse, and so on. Do you always have a team like that? What if we do not have it?

It is certainly a problem but, is there any methodology that can finish projects successfully not having at hand people with the required skills?

¿Qué significa ser ágil?

Debido a mi trabajo, por el blog o por lo que sea, estoy usando cada vez con más frecuencia muchas de esas palabras de moda como Ágil, Sprint, Historia de usuario, velocidad de la iteración o backlog del producto. He repasado algunas de mis entradas en este blog y lo veo lleno de expresiones un tanto huecas como ‘ser ágil’ o no serlo, aportar valor al producto o aceptar el cambio.

¿Qué significa realmente todo esto? ¿Qué es eso de ser ágil y por qué iba nadie a querer ser ágil? Esto de la agilidad es más una filosofía que un concepto claro y bien definido. Supongo que es una forma de ahorrar palabras y evitar tener que dar una definición completa de cada concepto cada vez que hablamos pero quien nos escuche debe estar pensando ¿qué diablos dice?

No sé si será suficiente pero quizás pueda aportar algo de luz utilizando la presentación de Henrik Kniberg en el Paris Scrum Gathering (échenle un vistazo, no tiene desperdicio) Pongo aquí un par de puntos que me parecen muy destacados:
Esta imagen de la torre Eiffel es bastante descriptiva por sí misma. Representa bien este balance entre el caos y la burocracia (exceso de documentación, formalismos o rigidez del contrato) Uno nunca se puede mantener un equilibrio perfecto, algunas veces te quemarás un poco y otras uno recibirá un pinchazo. Mientras se esté intentando no caer en la burocracia sin abrasarse mucho no iremos por muy mal camino.
Estas dos imágenes de arriba explican también de forma muy clara lo que significa ser ágil: ¿Alguien tiene una idea? Vamos a probarla, ¿son aburridas esas reuniones? ¿Probamos a quitarlas y vemos qué tal nos va?
Y por último, la idea que a mí más me gusta y la que, al mismo tiempo, me parece más divertida (aunque aún me falta para llegar a esto):

SCRUM para proyectos de mantenimiento

Hace algunos días hablaba con un colega en este mundillo ágil sobre si era posible aplicar SCRUM a proyectos en los que, además de las tareas previstas y planificadas, suele haber interrupciones frecuentes para resolver problemas de mantenimiento o corrección de errores. Muchos jefes de proyecto se enfrentan a este tipo de problemas y utilizan diversas aproximaciones para resolverlo. Aquí van un par de ellas:

Sprints cortos

Con esta solución mantendremos las tareas ya programadas en la planificación del sprint. Al tener sprints de 1 o 2 semanas de duración podremos incluir la tarea no planificada como prioritaria en la lista de cosas a hacer en el siguiente sprint. Si el sprint tiene 1 semana de duración tardaremos una media aproximada 3 días laborales en comenzar a acometer la tarea urgente.
Esto funcionaría en un mundo ideal pero no todas las tareas pueden esperar varios días para ser solucionadas. El servicio entero podría depender de ella.

Factor de dedicación bajo

Si sabemos que con frecuencia nos llegarán tareas inesperadas que debemos resolver con mucha rapidez podemos bajar el factor de dedicación durante el sprint para dar ‘hueco’ a la resolución de estos problemas.
Sabiendo que en cada sprint el equipo tiene capacidad para resolver 10 puntos de historias programadas podríamos comprometernos a entregar solo 7 para que el equipo tenga tiempo de resolver las incidencias urgentes. De este modo no fallaremos un sprint tras otro en entregar lo prometido.
En mi opinión esta solución puede ser útil en ciertos proyectos pero puede crear otro problema. Me explico: Habitualmente el factor de dedicación es del 75%, si lo bajamos para poder dedicar un 30% del tiempo del equipo a las tareas urgentes deberíamos aplicar un factor de dedicación del 40-50%. Sobre este 40% aplicamos SCRUM pero ¿cómo se está gestionando el resto del tiempo del equipo? ¿qué sabemos sobre esa pila de tareas que estamos resolviendo sprint tras sprint?

Un equipo separado por cada tipo de tarea

Esta solución consiste en tener un equipo SCRUM para las tareas identificadas y planeadas y un equipo Kanban para las incidencias de resolución urgente. Con Kanban podemos añadir las nuevas tareas a la columna TO-DO a medida que van llegando y así seguiremos su evolución hasta que llegan a DONE. Con esto el equipo será aún más ágil disminuyendo el overhead de reuniones y planificaciones que tiene SCRUM.
Aún sigue existiendo un problema con las tareas no planeadas y es que son eso, no planeadas. En ocasiones el equipo Kanban que da soporte podría estar sobredimensionado para las pocas incidencias ocurridas en ese momento pero una semana más tarde el número de incidencias y su importancia podría ser tan alta que toda ayuda es poca.
Para minimizar estos riesgos podemos apoyarnos en las soluciones anteriores: Un sprint corto para que el equipo SCRUM de desarrollo planifique sus tareas para la próxima iteración y usar también un factor de dedicación un poco más bajo para que el equipo tener un hueco en su planificación para echar una mano si fuese necesario. Del mismo modo, el equipo de soporte puede colaborar con las tareas planificadas para el sprint actual cuando su columna TO-DO se está quedando vacía. Para aprovechar esto al máximo sería bueno que los miembros de cada equipo se intercambiasen de vez en cuando para que todo el mundo conozca todos los aspectos del trabajo.

Suscríbete