Ajedrez - antoniomartel.com

Archivos por Etiqueta: SCRUM

Libro Gestión práctica de proyectos con Scrum

Estoy terminando de escribir un libro sobre la gestión ágil de proyectos software usando Scrum. Se trata de un ebook en el que trato de explicar, de la forma más amena que me ha sido posible, la gestión de proyectos desde un punto de vista práctico evitando toda teoría y terminología que pudiera sonar rara a un novato que se acerca por primera vez a Scrum.

Dentro de un par de semanas lo publicaré en Amazon. Espero que les sea de interés. De momento les dejo un adelanto del contenido (clic en la imagen para ver el Prezi)

Libro Gestión práctica de proyectos con Scrum

Scrumdamentalismo

Scrum y técnicas ágiles
llevan solo unos años siendo populares en España y ya se está hablando de Post-Agile o lo que vendrá después de la
moda de las técnicas ágiles ¡Si no hemos tenido tiempo de aprender Scrum y ya
lo están reemplazando! En realidad el
movimiento Post-Agile no pretende ser algo que sustituya a Scrum a Kanban o a
otras técnicas llamadas ‘ágiles’ sino que más bien intentan que no se pierda la filosofía que hay detrás.
He visto a muchos
profesionales preocupados por seguir todas y cada una de las reglas que se
definen en Scrum, usando pomposos nombres para sus reuniones y un montón de
tarjetas de colores para todo tipo de tareas posibles. Dicen cosas como ‘¿Qué no actualizas la gráfica burndown a diario?
Entonces tú no estás haciendo Scrum’
, ‘¿No
mantienes una Reunión de Retrospectiva después de cada demo? Eso no es Scrum’.

En algunos casos es
una especie de fundamentalismo del Scrum que afecta a los profesionales TI y
que a veces nos lleva a convertirnos en pequeños talibanes de nuestro lenguaje
de programación favorito o de la metodología que esté de moda en ese momento. En otros
casos es algo así con una enfermedad, Scrumbutphobia, como la denomina Henrik
Kniberg, conocida también como Scrumdamentalismo, y que se define como el miedo
a seguir mal Scrum.
Hay un concepto
divertido, que proviene de las artes marciales, en las que a las fases del
aprendizaje se las llama Shu Ha Ri. Este concepto explica que cuando se está
aprendiendo un arte marcial, y esto puede aplicarse a muchos otros campos, se
pasa por estas tres etapas. La primera, Shu,
en la que los aprendices sólo se siguen las reglas que les han enseñado. La
segunda, Ha, en la que aprenden a
adaptarlas para que les funcione mejor en sus condiciones particulares. La
última, Ri, cuando ya se conocen y
dominan las técnicas simplemente se ‘ignoran’
las reglas. Uno de los síntomas de los que padecen, o hemos padecido, la fobia
a hacer mal el Scrum, es la de estar atascados en Shu, la primera fase del aprendizaje.
«¡Que le den a las reglas! Las reglas son buenas al inicio, luego rómpelas cuando lo necesites»
Si tu meta es
entregar productos de calidad que sean verdaderamente útiles al cliente y no
tener que acudir continuamente al contrato a verificar si estás obligado a
hacer esa tarea. Si te olvidas un poco de porcentajes, de complejos procesos y de tanta herramienta para centrarte en
si estás mostrando periódicamente demos que funcionan (con algún error que otro) en lugar de powerpoints y barras de progreso, entonces creo que vas por buen
camino. No te preocupes si no cumples todas y cada una de las reglas de Scrum.

Reuniones en Scrum

Dentro de la metodología Scrum se establecen una serie de reuniones con nombres algo complicados y duración, asistentes y fechas prefijadas. Les explico en este post el significado de estas reuniones y, sobre todo, cómo pueden ayudarte en tu trabajo:

Reunión de planificación del trabajo

Antes de comenzar el trabajo previsto
para las próximas 2 semanas te reunirás con el cliente (o representante del mismo y con las
personas que éste considere) y definirán qué tareas se realizarán
durante esas dos semanas (si el equipo de trabajo considera que puede hacerlas en ese tiempo) Durante esa reunión el cliente dará toda la información necesaria sobre las tareas escogidas explicándolas al equipo que va a desarrollarlas.
Tener en
cuenta la capacidad de trabajo del equipo durante esta reunión de planificación
permite, entre otras cosas, encajar los periodos de vacaciones o las ausencias de los miembros
del equipo. Es tan sencillo como explicar ‘Dentro
de dos semanas nos comprometemos a entregar solo 3 de estas tareas en lugar de las 5 habituales. Alberto y Pilar tienen vacaciones la próxima
semana
’ Esto no suele suponer un problema ya que el cliente lleva recibiendo entregas del trabajo cada dos semanas de forma consistente.

Reuniones diarias

El equipo de trabajo y el Scrum Master se
reunirán cada día, mejor al inicio de la mañana, durante 15 minutos para
contestar a las siguientes preguntas:
  • ¿Qué se hizo desde la última reunión?
  • ¿Qué se hará desde ahora y hasta la próxima reunión?
  • ¿Qué está impidiendo hacer el trabajo lo mejor posible?

 

Ejerzo
habitualmente de Scrum Master en varios proyectos y a cada una de las reuniones
diarias llevo una hoja impresa con estas tres preguntas donde mantengo
registros de las respuestas del equipo de trabajo. Al final de cada una de
estas hojas he añadido un apartado adicional llamado ‘Tareas para el Scrum
Master’ y en él anoto todas las cosas que el equipo de trabajo necesita para
continuar o qué les está dificultando el trabajo. Anotaciones frecuentes son: ‘Llamar al cliente y pedir lista de usuarios
(¡mañana comenzamos con esa tarea!)
’ o ‘Pedir exportación de la base de datos (necesitamos una copia ya antes de
empezar a modificar datos)
’) Es habitual que me pase el resto de la mañana
intentado resolver los problemas que me han contado a primera hora.

Reunión de demo

Al finalizar cada iteración de dos semanas se concreta una fecha
de reunión con el cliente y se le hace una demostración del trabajo
realizado en esas dos semanas. En esta reunión el representante del cliente, en su función como director del proyecto, revisará
lo que se le está mostrando y dará su visto bueno o no a lo que ha visto.
Para poder cerrar
la funcionalidad es importante que esté completamente terminada y libre de
errores (serán necesarias las pruebas del equipo de trabajo y una validación
completa del cliente). Si no fuese así, se llegaría al final del proyecto según
la gráfica burndown (todas las tareas
estarían a 0 horas de trabajo pendiente) pero el proyecto aún no está
finalizado porque hay funcionalidades incompletas o con errores por corregir.
Estas entregas
periódicas permiten ver al cliente cómo va avanzando su producto, qué se ha estado haciendo durante esas dos semanas y decidir luego, en la reunión de planificación, qué quiere
ver en la siguiente reunión de demo. Esto permite ganar confianza ante el cliente que no pierde de vista a la empresa desarrolladora una vez ha terminado
la toma de requisitos para volverla a ver meses después con un producto ya
completado sobre el que tiene pocas posibilidades de modificación.

Reuniones de retrospectiva

Después de cada iteración de 2 semanas y una vez
realizada la demo al cliente, el Scrum Master y el equipo de trabajo se reúnen
para estudiar los problemas que han podido ocurrir en esas dos semanas, por qué
la demo no salió todo lo bien que debería (o sí) y si se puede hacer algo para
mejorar en la próxima entrega.

 

Es bueno que el equipo de trabajo se sienta libre de expresar lo que considera que han sido
los principales problemas aunque eso te haga subir los colores. Los problemas a
veces están en la ‘zona ciega’ del Scrum Master y la visión en conjunto ayudará a aportar luz al problema.

Contratos a precio cerrado

Hace algunas semanas me preguntaba Antonio, a través de los comentarios de este blog, por el tipo de contrato que tenía en mis proyectos y si estos contratos se realizaban con clientes internos o externos. La negociación sobre el contrato es uno de los asuntos más difíciles con los que nos podemos encontrar en un proyecto y probablemente, dónde puede surgir más fricción entre proveedor y contratante.

Trabajo en el área de administración pública de una empresa de desarrollo de software. Eso significa que, al menos en el 90% de los proyectos en los que trabajo, tengo como cliente a un organismo público. Los contratos vienen normalmente determinados por un pliego de cláusulas administrativas y otro de prescripciones técnicas en los que se detallan los servicios contratados, las características del producto a ser desarrollado y el precio máximo que puede tener la oferta. Se especifican incluso las características técnicas del software y hasta el perfil de los participantes en el proyecto. Todo está muy acotado y delimitado. Es el precio que tiene que pagar la administración pública para evitar arbitrariedades.

Si se ha tenido suerte y se ha podido ganar el concurso público nos enfrentamos luego, tanto cliente como proveedor, con la cruda realidad de los proyectos. Y es que las circunstancias cambian, aparece nueva legislación que afecta al proyecto o lo que se pensó que era correcto unos meses antes se ha podido comprobar que ahora las necesidades son distintas. ¿Qué hacemos? Si adaptamos el producto a todos los cambios que el cliente necesita,  nosotros como proveedores, sufriremos ese coste adicional. Si negamos al cliente cualquier posibilidad de cambio, remitiéndonos siempre al contrato y a los pliegos, corremos el riesgo de entregar al cliente un producto ajustado a un decreto del año anterior o que, por otras causas, ya sabe que no le va a servir a sus necesidades.

La forma de evitar ésto, por lo menos la que mejor me ha funcionado hasta ahora, ha venido dada por la propia forma de trabajar en estos proyectos, usando Scrum. Al inicio del proyecto hago una lista con las funcionalidades que hay desarrollar y le asigno a ellas una puntuación que el cliente conoce desde el principio. Si el cliente quiere incluir dos nuevas funcionalidades le pido que me indique qué otras funcionalidades de similar puntuación sacamos de la lista. Normalmente esta solución le sirve para resolver la situación y no tiene problemas en renunciar a otras funcionalidades que ahora sabe que no son tan importantes. Si todo queda constatado en un acta de reunión y, sobre todo, queda entendido a qué se renuncia y qué se va a obtener a cambio, no suele haber muchos problemas.

Esta es la solución que yo aplico. Como siempre, espero que le pueda servir a alguien.

5 Lessons learned in Project Management

Whenever I finish a project I try to have a look at what went wrong, what worked as a charm, and what I tried but it didn’t work out. Even when I get a final negative balance, the project may has been worth it if I don’t make the same mistakes again.

From some of these balances, I have extracted five of the most important lessons I’ve learned. Some are beginner mistakes, others should have been solved using simple logic but, by then, it wasn’t that evident to me. Here you go:

Agility works

It is difficult to quantify it but since I started using Scrum in my projects, the number of hours spent by functionality went down. Just doing the daily meeting for 15 minutes, maintaining project status chart that tells us if we are going well or not and a delivery every two weeks allowed us to obtain 80% of the benefits of Scrum. In addition, delivering consistently every two weeks, showing client what was agreed two weeks earlier, seemed to bring customers some comfort. In July or August, when meetings were not possible, the weekly delivery of a simple two-page document with the percentage of completion for each functionality and two paragraphs explaining the reason of those percentages, helped to restore credibility in a difficult project (especially in September when they could check that those percentages were real)

Everything is not positive in Scrum

It requires much more dedication of the Scrum Master than it would if you only were playing the role of project manager. Those 15 minutes at the daily meeting will tell you a lot about the difficulties that need to be solved to keep going forward. Trying to solve them will take you the rest of the morning.

On the other hand, having a delivery every 2 weeks can be exhausting. You cannot be sprinting for months and months. After six months you will be ending trotting (hopefully) You need to take this into account since the first planning.

Last but not least, Scrum is not magic. Whatever methodology you use you will need a team able to perform at a good level, willing to pitch in and eager to contribute. Teams like that do not grow on trees. If you already have one of those teams the project manager mission will be to interfere as little as possible.

Adding more workers to the team will slow it down

Well, this is already said for a lot of years in the book The Mythical Man-Month. Yet it is necessary to emphasize this, there are no much exceptions to this rule. No matter how tight the deadlines are: Nine women cannot make a baby in one month.

Who is the owner of all this?

No matter how we call it: identifying stakeholders, designating the product owner or involving the stakeholders. At the end we need to know who will actually validate. And I do not mean who will sign the bill. You also need to know who will use the product. The project will only be successful if after delivering it works and it is useful.

In certain project, the client’s director gave us all the documentation, validated partial deliveries, tested the entire application and congratulated us for the work done. Unfortunately, when his secretary attended the training session a week before sending the product to production, she said: ‘This is not going to help me: that one is not the right template and I need to collect different data than the one showed there’ . This meant a week of overtime and extra effort and the risk of putting into production environment a product that could be unstable.

Minimum Viable Product

If you already have something that may be useful to the user, give it to it, put it into production, take it out for sale. Do not wait until you have completed every single functionality. If you remember the Pareto principle, with only 20% of them you will obtain 80% of uses of your product.

While in production you will begin to get the impressions from its users. They will know more accurately what they really need and you will know what you did wrong and how you can improve it. If you bet on a single final delivery you will have only one bullet to hit the target (to do this would have saved us a lot of problems with the product mentioned in the previous point)

Those are my lessons learned. I hope someone will make the most of them.

Suscríbete