The agile speed lie

“My job is to get speed in here!” With these pithy words the Agile Transition is heralded in many companies. This often leads to the following result: staff turnover increases and the promised increases in productivity fail to materialise. It is precisely with this statement that agile work is often sold: Agile methods are supposed to bring speed to supposedly lame organisations. Such promises not only mislead the client and deprive him of the true opportunities of agile work, they also over promise him too much. I call that the agile speed lie! But how did it come that agile work is so misinterpreted? How can it be that agile work is often equated with speed?

The art of doing double work in half the time

Agility has become a management hype. So unbearable that I have already proclaimed “Stop agility”¹.

Of course, the term “agility” in itself says something: Quick, flexible and fast, all this is meant by the adjective agile. And the inventor of Scrum have added to that with their bestseller, “Scrum, The Art of Doing Twice the Work in Half the Time”. That’s something: The double work in half the time? The decision maker calculates quickly: “Aha, so 300% increase in efficiency That sounds really good, that’s what we’re doing now.”

In addition, sports metaphors are often used in an agile context. Scrum is a term borrowed from rugby, Sprint is a discipline in athletics and Velocity is another word for speed. So it is not surprising that agile methods are often sold via a speed advantage.

But is speed really the goal of agile methods or is it not the result of a better way of working? Let’s drill a little deeper and look at the term “velocity”, one of the core metrics of agile methods and Scrum.

The agile metric velocity

Velocity is one of the best known metrics in agile methods. What is it about? With velocity, a team measures how much work is done in a sprint. The work itself is measured by the team in story points or effort points. The story points indicate the approximate effort per request or user story. In the course of the sprints, at least that’s the theory, a constant team velocity settles in. This is a kind of “speed” with which the team works through its tasks and is on its way.

That sounds really good at first: An indicator that measures the speed of a team? For the inexperienced manager, it’s now obvious to do things right. Can’t I just apply this metric to all teams? What is the velocity of Team A compared to Team B? Why does the velocity break into Team C? Who is to blame? And anyway, how can I increase the velocity as continuously as possible? There are countless articles on this last point on the net. By the way, these articles are often written by tool manufacturers who want to sell their products. In 2016, for example, the tool manufacturer VersionOne published the following statistics with a little naive eyes²:

How do you recognise success in agile projects?

VersionOne asked its customers: How do you measure success in agile projects? The result is devastating for me: By a clear margin the daily check of the team velocity was in 1st place. In 2nd and 3rd place the BurnDown charts were checked, which doesn’t make things much better if the speed of processing is controlled. The first directly usable metric from my point of view, “Work in Progress”, ranked 8th.³

Customer benefit in quality instead of speed

Why is velocity or thinking in speed dangerous at all? Velocity does not only lead to pure quantity being measured. It’s much worse: when pressure is applied to increase velocity, bad work is rewarded. The developer simply writes fewer tests, works more carelessly and the velocity increases. And if there’s one thing agility isn’t about at all, it’s the increase in output to the point of nonsense. It’s about generating customer benefit in quality. However, customer benefit cannot be measured in story points.

By the way: The agile SAFe framework pushes the subject of velocity to an inglorious peak: there are even “normalised” story points so that all apples and oranges can be compared across teams.

A well-functioning team is like a good band

Scrum and agile methods can make your projects faster. Speed or much more productivity is rather a possible result and not the goal of agile work. First of all Scrum makes things even slower: Daily Standups, Refinement, Planning and the Retrospective, all these meetings cost a lot of energy and time. Scrum only shows its strengths when there is peace and quiet and the team can work in harmony. When Developer, Scrum Master and Product Owner pull in the same direction and have found their own rhythm for the team. Yes, I even think the whole thing has something to do with music and harmony. It’s not about getting faster, it’s about getting more harmonious. The purpose of measuring velocity should be only one thing: The team should discover its rhythm and its own speed.

And how does the increased productivity promised by Jeff Sutherland materialise? How do you double the number of results in half the time? Quite simply, where peace reigns and an optimally assembled team gains protection, time and clarity to make the right decisions. That is the core of the whole: Good and top-class work based on the best possible decisions. And the best possible decisions are made through short intervals and direct feedback from those involved.

The anti-dopamine: if you’re in a hurry, go slow

I therefore plead for the following: If you really want to work agilely and productively with your team, then you’d better go slower and calmer. As a manager, ignore metrics like velocity. Please don’t be interested at all in how many stories your team creates or doesn’t create. You should rather pay attention to a good composition of the team, to structure, rhythm and undisturbed work. Be interested in the content of your teams’ work, because nothing demotivates teams more than executives who don’t appreciate products at all. I promise you that the desired speed and performance will be achieved all by itself. And maybe you don’t even need Scrum. And if a consultant says: “My job is to get speed into this,” then please send him to hell. Excuse me!

Notes:

My book tip: It Doesn’t Have to Be Crazy at Work

Finally, I’d like to give you a book tip. Currently the book is only available in English, but I am convinced that it will be published in German soon. Jason Fried and David Heinemeier Hansson are managing directors of Basecamp and have already written the very successful books Rework and Remote.

In their latest book It Doesn’t Have to Be Crazy at Work the authors describe why quiet and continuous work is more successful in the long run than project stress, deadlines or trying to increase the speed of teams. The basic statement is almost banal: Let people work in peace and please don’t disturb them. By the way, Basecamp also works agilely, but not in the form of Scrum.

[1] Stop agility – Blog post about agility and the agility mania
[2] Ron Jeffries was intensively occupied with the Grafik of VersionOne: Do you want Crappy Agile?
[3] All listed metrics have a good and a bad side. When used correctly, velocity is very helpful for the team in self-assessment. Customer satisfaction is helpful, but requires a lot of translation so that the team can derive concrete measures from it. The Work in Progress metric can also be misused if, for example, it is used to target the workload of all team members.
[4] Normalised Story Points in SAFe

This is the second part of André Claassen’s triology on agile work. The first part is the already mentioned article ” Stop agility “. The third part is called “The agile label fraud”.

Here you can find contributions by André Claassen in the t2informatik Blog:

What does t2informatik actually do? One click and you'll know.