Ajedrez - antoniomartel.com

Archivos de Autor: Antonio Martel

When everything is a priority, nothing is a priority

I remember when I read the book “Prioritizing the Product Backlog” by Roman Pichler. He wrote: “I’ll never forget the day when I suggested to the product manager of a new health-care product to prioritize the use case pile in front of her. She looked at me, her eyes widening, and replied, ‘I can’t. They are all high-priority’”.

Quoting to Karen Martin: “When everything is a priority, nothing is a priority”. I have faced this issue too. I tried to solve it by telling the manager that the team couldn’t be working on five tasks at the same time and asked her what she wanted to obtain first. She didn’t hesitate a second and pointed to one of the user stories. “No doubt,” she said, “this one, definitively”.

How does Agile help you to deliver?

Have you ever wondered why Agile is so widely adopted? How does it help companies to deliver sooner and better? Here are some tips:

  • Releasing frequently improves customer satisfaction and allows the client to decide how the product is evolving.
  • Sprints are small milestones. They help you to overcome the Parkinson laws and avoid feared deadlines at the end of the project, when little can be done if something went wrong.
  • The Kanban board, the backlog and the sprint backlog make visible the pending work and how we progress (have a look at the Checklist Effect by Atul Gawande).

Deadline Driven Development

I have recently read the article «Deadline Driven Development» from Simón Muñoz. Quite a captivating one.
As in TDD, we create tests before developing the solution, he suggests setting a deadline before estimating, and then doing only what can be done until that deadline.
There are multiple perks to that approach: product managers avoid scope creep, and adding unnecessary features to the product being built. Other than that, developers will reduce the overengineering or creating too complex solutions, far beyond what is needed.
We will be reducing waste by building applications or services with just the two or three most important uses cases . Then, we can release our service, and see what was useful, what our clients require now, when they can use the product. From that point we can make more informed decisions on investing more, and better (or to cancel the product).


See the link to the original blog post (in Spanish): Deadline Driven Development by Simón Muñoz.

Mi experiencia con SAFe

En muchas empresas de tamaño grande han estado teniendo problemas con la adopción de Scrum. Tienen múltiples equipos trabajando en diversos productos interconectados y cada vez que tienen que acometer un desarrollo en el que hay dependencias distribuidas entre esos equipos, los tiempos de entrega se alargan indefinidamente.

Es por eso que un porcentaje alto de esas empresas han decidido adoptar SAFe (Scaled Agile Framework Enterprise) buscando escalar la agilidad al tamaño de sus proyectos. Cuando me enfrenté a esta forma de trabajar por primera vez, lo hice algo preocupado porque fuera un monstruo demasiado grande de digerir y se tragara la posible agilidad que pudiéramos tener.

Lo cierto es que tiene algunas cosas buenas: el Product Owner debe aprobar cada desarrollo (lo que suele implicar que todo el mundo revise bien su trabajo para evitar un rechazo) y los Planning Interval cada tres meses te fuerzan a tener en mente los objetivos a largo plazo que tiene la empresa.

Por otro lado, esa planificación tan a «largo» plazo puede hacer que se pierda algo de flexibilidad. Además de que las reuniones de coordinación entre todos esos equipos de trabajo hacen que el tiempo empleado en reuniones (y la multidud que asiste) se multiplique por varios órdenes de magnitud.

Desde luego, no ha estado mal la experiencia. Quizás, cuando la vea dentro de unos meses, valore haber ganado, o perdido, otras cosas de las que ahora no me doy cuenta.

¿Sprints de solo una semana?

Hace algún tiempo me preguntaron por la duración de los sprints en los equipos en los que trabajaba, y les contesté que eran habitualmente de dos semanas. Habíamos hecho alguno de solo una semana, pero nos parecía demasiado overhead de reuniones y eventos de Scrum. También alargábamos a tres semanas durante las vacaciones de verano y Navidad, pero teníamos la sensación de perder de vista en qué semana del desarrollo estábamos.

Ya no veo tan mal los sprints de una semana. Con los de dos vemos siempre que la gráfica de burndown se mantiene plana durante todo el sprint, y baja solo durante los dos últimos días de la iteración (ya conocemos la Ley Parkinson: el trabajo se expande hasta que ocupa por completo el tiempo destinado para su realización).

Con solo una semana por sprint, la gráfica sufre el mismo problema, pero en la mitad de tiempo. Además es más fácil acertar en la velocidad del equipo y lo que puede comprometerse: tienes una mejor idea de lo que puedes hacer en solo cinco días (y reaccionar si surge algo imprevisto). Cuestión de seguir probando.

Suscríbete

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad