Ricardo Mestre

I’ll be a speaker at Agile Manchester 2015!

Posted in Uncategorized by thewatcher on April 1, 2015

Very happy to announce that I will be a speaker at Agile Manchester Conference, May 8th!

Here is a link to my talk:

It’s going to be very interesting to present our Ways of Working (a.k.a. Project Magellan) to the external world 🙂 Looking forward to get a lot of questions from the audience 🙂

… See you there!


Great article about how to use spikes in Scrum

Posted in Uncategorized by thewatcher on March 17, 2014
Tagged with: ,

All the info you can get from a Cumulative Flow Diagram

Posted in Uncategorized by thewatcher on October 16, 2013


Tagged with: ,

Identification of bottlenecks on a Cumulative Flow Diagram

Posted in Uncategorized by thewatcher on September 2, 2013
Tagged with: ,

Kanban simulator

Posted in Uncategorized by thewatcher on August 20, 2013

Here is a simulator of a Kanban system, where you can adjust WIP limits and observe the impact on you Lead Time, done by IT-Agile, a Munich-based company. Very very interesting, and very useful.

Tagged with:

Another extensive article about reading Cumulative Flow Diagrams

Posted in Uncategorized by thewatcher on August 20, 2013
Tagged with: ,

On Kanban: reading a Cumulative Flow Diagram

Posted in Uncategorized by thewatcher on July 25, 2013
Tagged with: ,

On mistaking speed with getting what you need

Posted in Uncategorized by thewatcher on July 26, 2012

In Scrum, we define velocity as the average of the story points finished by the team in the last “x” sprints.

How much is “x”? It’s up to you to decide. I use the average of the last 5 sprints as the definition of velocity for my teams.

There are several different ways that a Scrum team can use the knowledge of their velocity.

The first one that comes to mind is that velocity can be used a measure of productivity. If we have a look at Wikipedia’s article about it (http://en.wikipedia.org/wiki/Velocity_(software_development)), we can confirm that this is the only use that is described there.

By itself, this definition is simplistic, and, in a certain way, dangerous :).

Why so?

Consider this hypothetical scenario: let’s treat velocity as the sole measure of productivity. We are measuring the productivity of a Scrum team which is actually quite motivated.

This team knows that the sole measurement of their performance is velocity, they are motivated, they want to succeed.

What they’re gonna do? They are going to try to get as many story points done during their sprints, obviously.

Sounds too go to be true, no? That’s because it actually is.

The ugly truth is that, after a certain plateau, if a Scrum team tries to artificially inflate their velocity (we all want to be winners, right?), they will deliver more product, together with an ever increasing technical debt (bugs, brittle code, you name it).

A sprint, is by definition, a time box. Delivering within a time box builds pressure onto the team – up to a certain level, that is healthy.

But if that pressure increases (even when that increase is self-inflicted), the team will start cutting corners.

One might argue, that a proper Definition of Done, in conjunction with  proper demos (at the Sprint Review), will keep the technical debt under control. That is true, but only to a certain extent; even then, the technical debt will increase, on a silent way.

We must remember that we want that our team achieves the best productivity possible at a sustainable pace :).

That’s the key: sustainable in terms of effort, and in terms of the quality of the finished product. 

Then a question remains: what’s a good use of velocity?

In my opinion, velocity is more useful as a tool that will help the team do realistic commitments.

Realistic commitments will help the team to perform great, and delivery consistently their commitment at the end of their sprints.

And consistent deliveries will increase the team predictability. 

Which will allow that the Product Owner can start thinking in terms on milestones in a roadmap, with more confidence!

And we are talking about creating software here, not making bricks… so that type of predictability is highly desirable.

Tagged with: