Retrospectiva

Cuando terminamos un ciclo o proyecto, llega el momento de echar una mirada retrospectiva.

Es independiente a la metodología de proyectos que se utilice. Scrum realiza sus Sprint Retrospectives al finalizar el sprint, y en un Waterfall se llevaría a cabo una vez finalizada la ejecución del proyecto.

Llevar a cabo la retrospectiva es fundamental para la mejora continua.

Una retrospectiva parte por identificar las cosas que se han hecho bien y las cosas que se han hecho mal.

Identificar las cosas que se han hecho bien no es tan fácil como parece, ya que solemos dar más importancia a los problemas que a los logros o éxitos (salvo que sean muy notorios). Llevar a cabo éste ejercicio es útil para identificar cuáles son nuestros puntos fuertes y así poder llegar a potenciarlos. O por lo menos para alimentar nuestro ego antes de recibir las malas noticias ;)

Por supuesto, la tarea que más trabajo tiene es la de ver que cosas se han hecho mal. Debemos analizar los problemas y fallos generales, aunque a priori no se consideren como errores propios, y luego unirlo a una profunda labor de autocrítica.

Una vez tenemos los puntos negativos, llega el momento de analizarlos para comprender por qué se llegó a esa situación, cómo se podría haber evitado, y cuales serian las medidas, o actitudes a tomar para evitar ese problema concreto en el futuro.

De hecho, si fuera un sprint en Scrum, el último punto sería precisamente plantear esas acciones para corregir lo que no se ha hecho correctamente, para llevarlas a cabo en el siguiente sprint.

Un juego para plantear la retrospectiva en equipo es realizar una selección anónima e independiente de puntos positivos y a mejorar por parte de cada miembro del equipo, sumarlos para establecer cuales son los más repetidos, y una vez identificado un número limitado, plantear las propuestas correctivas. Incluso es buena idea, si es posible, asignar las tareas de mejora a los miembros del equipo.

Es cierto que esas hipotéticas soluciones no son realmente válidas hasta que no se ponen en práctica y tienen éxito, y en algunos casos no se podrán poner en práctica nunca, pero nos serán útiles para completar la experiencia que hayamos adquirido.

Y también es cierto que encontrarte siempre los mismos problemas en una retrospectiva puede causar desconfianza y frustración. No siempre se tiene la capacidad para cambiar ciertas situaciones.

Al final de todo se aprende, y en la medida de lo posible, es importante llevar a cabo la retrospectiva para sacar lección tanto de lo bueno como de lo malo.

¿Alguna experiencia fruto de una retrospectiva que queráis compartir?

¿Scrum o PMBOK?

La gente más afín a Scrum te dirá que si no practicas una metodología dentro del marco Agile estás anclado en el pasado, que para software es mucho más efectivo, y que es una metodología que aplican las grandes tecnológicas como Google, Yahoo, etc. Si te interesa Scrum y Agile, hace poco publiqué un post de introducción sobre ello.

Por otro lado, la gente que utiliza PMBOK te dirá que no hay nada como el desarrollo en cascada o Waterfall, con toda la información y requerimientos antes de iniciar el desarrollo, y que Scrum es una perdida de tiempo, sobretodo en España.

Personalmente, creo que todos tienen parte de razón. No hay una opción buena o mala, mejor o peor. Ambas opciones son bien válidas, hay que saber aplicar la metodología adecuada para cada situación.

El objetivo, la fecha, y el entregable

En un mundo ideal, bajo un PMBOK tienes muy claro cual es el objetivo final porque todo el proceso está descrito al detalle, mientras en Scrum tienes la idea del objetivo y el desarrollo se lleva a cabo sobre la marcha.

En un desarrollo en Waterfall tienes una fecha final de desarrollo medianamente realista porque está completamente planificado, teniendo siempre presente que cualquier desvío en las tareas retrasa la salida porque no tienes un producto entregable.

En Scrum te vas acercando poco a poco y de forma incremental a esa idea final, pero siempre acabando el ciclo de la iteración con un producto entregable. Es decir, que una vez llegada una supuesta fecha final, puede que no tengas el proyecto finalizado, pero puedes realizar una entrega totalmente funcional de un porcentaje avanzado del mismo.

Entonces diréis… Scrum es mejor, porque puedes entregar el 80-90% del proyecto en la fecha de entrega. Pero la verdad es que, ¿Cuando os habéis encontrado un proyecto donde os dejen entregar una parte y no os pidan el producto completo? Aunque se puedan fasear cierto aspectos o detalles, la mayoría de las veces os pedirán todo o nada.

Información y elementos disponibles

La diferencia principal entre Scrum y PMBOK es que éste último necesita de una toma de requerimientos previa a la planificación, un análisis tanto funcional como técnico, y una vez todo está firmado y planificado hasta el mínimo detalle, entonces arranca el ciclo de desarrollo.

En cambio Scrum juega con el Caos, es decir, no tiene porque existir un funcional, solo un rol que tenga la idea clara del desarrollo que se encargará de guiar al equipo hacia su objetivo priorizando las tareas y dando feedback continuo. Cada iteración constituye en sí una toma de requerimientos, análisis, planificación, ciclo de desarrollo, y entrega de producto.

Esta es la diferencia que determina el porque Scrum es mas abierto a cambios, porque desarrollar en ciclos cortos permite que una idea pueda ser maleable, mientras en PMBOK cualquier cambio de requerimiento supone para el proyecto, revisar los funcionales, y replanificar. Esto último en el mundo ideal, en el mundo real te comes el cambio y te callas :)

El Equipo

Un equipo en Waterfall sigue unas indicaciones, mientras que en scrum el equipo se auto-organiza en base a unas prioridades. Para llevar a cabo el trabajo Scrum dice que necesita de un equipo maduro.

¿Y eso que significa? Pues que en Scrum se necesita un equipo que haga suyas las tareas y responsabilidades, y se comprometa a cumplirlas en el plazo que el mismo equipo ha considerado. En cierto modo en PMBOK el equipo vive más tranquilo por no ejercer ese conjunto de responsabilidades, aunque se acaba trabajando igual.

Adquirir tanta responsabilidad no es algo que quiera todo miembro de un equipo. Muchas veces te encontrarás que hay gente que necesita que le detalles las cosas, y que prefiere no coger la iniciativa a la hora de resolver los problemas que surjan a lo largo del desarrollo.

Debes estar seguro de que tu equipo está preparado antes de aplicar Scrum. El equipo es fundamental para el éxito en Scrum.

Si pensabas que no afecta al equipo, estabas bien equivocado.

Reuniones y seguimiento

En el caso de PMBOK, se realizan reuniones para el inicio del proyecto, reuniones de seguimiento del proyecto, y reuniones de fin de proyecto con carácter de revisión de errores y aprendizaje de los mismos. Por supuesto, las reuniones están ya fijadas antes de iniciar el ciclo de desarrollo, y según el avance del mismo, se pueden llegar a establecer más reuniones de seguimiento si es necesario.

En el caso de Scrum, es un concepto bastante parecido pero aplicado a la iteración corta y con más seguimiento por la falta de detalle del proyecto. Tenemos las reuniones diarias para revisar en equipo el compromiso de cada uno, las reuniones de planificación, las de review del producto y feedback de Product Owners, y por último las de retrospectiva, también para analizar problemas y errores, y aprender de ellos de cara a la siguiente iteración.

Si quieres saber más, hace un tiempo publique un post sobre Los Scrum Meetings.

Resistencia al cambio

Aquí no vamos a diferenciar entre ambas metodologías, ambas se encuentran con el mismo problema: La resistencia al cambio.

Por una parte PMBOK es muy estricta en cuanto a sus necesidades y organización, pero no encontraras empresas en España (o casi) que cumpla religiosamente con lo que dicta la PMO y la guía de PMBOK. Siempre hay problemas en la toma de requerimientos, no siempre se espera a tenerlos cerrados y firmados para empezar el desarrollo. Por otro lado, cuando no se ha cambiado un requerimiento cuando el desarrollo está en marcha…

En Scrum no es necesario tener un funcional en mente, pero eso no significa que no se deba realizar un esfuerzo de síntesis para tener la idea del proyecto clara con todas las implicaciones posibles. Ese acaba siendo un problema, porque no se realiza ese esfuerzo. Y por otro lado, la gente tiene puestos de trabajo que les mantienen demasiado ocupados como para dar el feedback continuo que requiere un desarrollo incremental sin el nivel de especificación de PMBOK.

La aplicación de cualquier metodología ya sea PMBOK o Scrum no requiere un cambio de chip del equipo de desarrollo y responsables, sino que requiere una implantación y cambio de filosofía que aplica a prácticamente toda la empresa, o por lo menos todas aquellas áreas implicadas en proyectos de desarrollo.

Si esto no se lleva a cabo correctamente y la empresa no se toma en serio la organización y apoyo necesario para su funcionamiento, el fracaso (retraso de fechas, producto erróneo, etc.) está más que asegurado.

¿Alguna conclusión?

Al final, cualquier opción es buena si te ayuda a alcanzan los objetivos marcados.

No te dejes llevar por modas, o influencias. Debes seleccionar como afrontarás el proyecto teniendo en cuenta donde trabajas y como se trabaja, los elementos con los que cuentas, el equipo, y la libertad que te dejarán. Acabas adecuando la metodología a la forma de trabajar de tu empresa. No es obligatorio utilizar una u otra de forma estricta (aunque sería lo ideal), puedes utilizar sus detalles según tus necesidades: desarrollo en ciclos cortos, reuniones diarias, requerimientos funcionales, reviews, dar más responsabilidades al equipo, etc.

Aplicar cualquier metodología de proyectos, ya sea utilizando un clásico Waterfall bajo PMBOK, o bajo el marco Agile como Scrum,  y aplicarlo en el desarrollo, puede ser un poco frustrante. Especialmente en España. Lo primero que te puedo aconsejarte es que tengas paciencia, y lo primero que puedo decirte es: Ánimo! :)

Me gusta la filosofía de Scrum, pero en España no es fácil encontrar empresas que realmente se vuelquen en su aplicación, responsables que confíen y tengan la paciencia para llevar a cabo la adaptación, y que además se den las condiciones necesarias. Los casos de éxito son lamentablemente escasos. Ojalá me equivoque y sea cosa mía.

Si consideras que me equivoco en algo, quieres añadir detalles que he omitido, o simplemente quieres compartir tu experiencia, por favor ¡No dudes en hacerlo!

Desarrollo Ágil y Scrum

Antes de centrarnos en Scrum, comenzaremos centrándonos en el desarrollo y manifiesto Ágil.

Citando a Wikipedia: El desarrollo ágil de software es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto.

Entre los más conocidos están Scrum y eXtreme Programming (o XP).

Principales valores del manifiesto Ágil

  • Individuos e interacciones sobre procesos y herramientas.
  • Software que funciona sobre documentación exhaustiva.
  • Colaboración con el cliente sobre negociación de contratos.
  • Responder ante el cambio sobre seguimiento de un plan.

Principios del manifiesto Ágil

  1. Satisfacer al cliente mediante la entrega temprana y continua de software que aporta valor.
  2. Aceptar cambios de requisitos, incluso en etapas tardías del desarrollo.
  3. Entregar software funcional frecuentemente.
  4. Los responsables de negocio y los desarrolladores deben trabajar juntos diariamente.
  5. Los proyectos se desarrollan en torno a individuos motivados.
  6. El método más eficiente y efectivo de comunicación es la conversación cara a cara.
  7. El software funcionando es la medida principal de progreso.
  8. Los procesos Ágiles promueven el desarrollo sostenible.
  9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
  10. La simplicidad es esencial.
  11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
  12. El equipo reflexiona sobre cómo ser más efectivo.

Una vez ya hemos presentado el desarrollo bajo el manifiesto Ágil, podemos plantear…

¿Qué es Scrum?

Como ya hemos comentado, Scrum es una metodología de proyectos incluida en el marco del Manifiesto Ágil. Es un marco sencillo para dar productos valiosos a clientes a través de la potenciación de los equipos con funcionalidades cruzadas y auto organizadas.

Scrum proporciona una plataforma para que la gente trabaje junta de forma efectiva y hace visible cualquier problema que aparece en su camino.

Scrum es sencillo, aunque la implantación es difícil.

Los tres pilares de Scrum son: transparencia, inspección y adaptación.

El Desarrollo en Scrum

El Desarrollo en Scrum es Iterativo, Incremental, y Orgánico.

Desarrollo Lineal vs Iterativo: No es un proceso en cadena completo, se divide en ciclos cortos.

Desarrollo Modular vs Orgánico: No divide para después integrar, deja que la aplicación crezca de forma natural.

¿Beneficios de Scrum?

  1. Siempre hay un entregable.
  2. Se desarrollo antes lo que aporta valor al cliente.
  3. Abierto a cambios.
  4. El timeboxing ayuda a la toma de decisiones y control de resultados.
  5. Los pequeños objetos son fáciles de estabilizar y significan menos errores.
  6. Los equipos se comprometen, se auto-organizan y gozan de la autoridad necesaria.
  7. Comunicación eficiente entre el equipo y el cliente.

En un artículo anterior ya hablé de Los Scrum Meetings, y en el próximo seguiremos hablando de los Roles y Artefactos de Scrum, o quizás haga una breve comparación entre el desarrollo lineal (waterfall) y el iterativo y cuando aplicar cada caso.

About Scrum Meetings

Implementing Scrum in a business is not an easy task, sometimes it may be a hard and long road. It involves a change that usually affects much of the company, and change management is always traumatic.
I would also like to point out that it isn’t a methodology only for software development projects.

The most common process is to adapt the concepts and practices of Scrum gradually based on the real needs of the company or department.

In this post I want to talk about the Scrum Meetings, part of Scrum practices in a Sprint (or iteration).

Usually, in my experience with Scrum, meetings are the easier concepts to implement. Receive good feeback in short term, could be considered as quick wins.
Each meeting has its own function or purpose.

Daily Meetings

The Daily Meetings are (as they mean) daily morning meetings that serve as synchronization between the different team members, and also for the Scrum Master or meeting moderator.

In this meeting, each team member answers 3 questions:
– What I committed yesterday?
– What I commit to do today?
– What blocks or impediments I have?

This meeting cannot exceed from 15 minutes, in fact it usually takes less time. It is recommend to carry out the meeting at a specific time, without waiting for late members. In our case, we apply a “financial penalty” depending on the time of arrival.

It usually has a positive reception and feedback among Team members. Sometimes there’s a lack of communication even within the same department, and this quick meeting allows a very efficient way to communicate and share the situation point of the project, cross project issues, and of course raise problems.

Normally, the term “commitment” isn’t used on the questions examples of the Daily Meeting. In Scrum, self-tasking is an exercise in self commitment and above all with the team. Scrum needs maturity. This is a detail I was told (with other colleagues) at the Scrum Training.

Also it is said that team members should focus on answering the three questions, and resolve blocks outside the meeting. But in small teams with more than one project in parallel, it is good to use the meeting to resolve conflicts and share knowledge, not allowing to become a debate.

While not considering moving to Scrum, I recommend the practice of Daily Meetings even though is to make up for a lack of communication.

Sprint Review or “Demo”

Sometimes confused with the Retrospective. It is an assessment of the project by the customer or owner. May be equivalent to user acceptance testing.

According to manuals of Scrum, should be done at the end of sprint, but in my opinion should be carried out once the development is considered completed within the sprint. If it’s done before the end of sprint, we’ll receive earlier the feedback, which is essential in an incremental development.

It is very important to know customer’s feedback from a project before deploy into productive environment. And its validation involves the owner or customer directly to the proper functioning of the project (or should be).

Sprint Retrospective

It is a very important meeting at the end of the sprint where to analize the sprint, focused on improving team performance and productivity. It is said that should be carried out after the Review (if the review is done once at the end too).

The basic points of the meeting are:

  • What works. Not only must focus on negative things, we must also celebrate well done job.
  • What must we improve. Identify areas of improvement in a constructive way, not need to be taken as negative points because this meeting isn’t for blame on anybody.
  • Identify the obstacles that doesn’t allow carrying out the work of the team. This will be a task for the Scrum Master or moderator. It is also very frustrating when you don’t have any authority, because this blocks tend to repeat over the sprints.
  • Define targets (milestones) to improve for the next sprint. These objectives can be assigned to team members. This permits to involve team members with roles of responsibility.

A game that usually works in this meeting: tell the team to write 3 things that are done well and another 3 that need to be improved. So everyone, without any external influence, should express their personal opinion. This may motivate and involve the team.
Once you have all the points, unify them by received votes. And in case of negative ones (to be improved), one by one search for solutions that would be the objectives or points of improvement for the next sprint.

In 2-week sprints, I do not usually spend more than an hour.

I hope this post would be helpful. I personally recommend adopting these practices of Scrum.

I also want to note that only speak from experience I’ve acquired, but I’m not a “guru” or Scrum Trainer and Coach, although I am a certified Scrum Master.