I recently read Clean Agile by Uncle Bob and probably that's why my Kindle recommended me to read Scrum: The Art of Doing Twice the Work in Half the Time on Agile by another founder of the Agile Manifesto.

Well, if there is one person who is more equal among the 17 founders, maybe it's Jeff Sutherland. At least in regards to Scrum. He clearly considers it the best way of doing things - if done right.

Deliver more with less

He brings examples to support his points. Not one or two but many.

The most fascinating one is probably the one of the FBI. The Federal Bureau of Investigation had been using an ancient computer system. Maybe it'd be better to say system, without "computer". They had most of their reports on paper, but anyways, they used a gigantic mainframe system that was built in the 80s.

It was called the Automated Case Support system and often agents avoided using it as it was so cumbersome and slow. Many claim that even 9/11 could have been prevented with a modern system. In any case, by 2001 a new system called the Virtual Case File system was under development.

But it was a disaster. The project ran late. It was budgeted for $100 million, then when the project was killed in 2005 they had already spent $170 million.

A new project was announced, Sentinel for $451 million and was promised to be fully operational by 2009.

In 2010 already $405 million was spent, but only half of the project was developed and independent analysts estimated an additional 6 to 8 years of development and at least $350 million.

That's the point when agile got involved and the new project lead promised a delivery for the fall of 2011 with an ~80% staff reduction and with the remaining budget.

The project got late, but finally, Sentinel was turned on in July 2012 that's years before the previous estimation with much fewer people and money.

Those who were responsible to turn the project around consider the usage of the agile methodology a game-changer.

Not relying on fixed ways of working, but constantly trying new things to eliminate impediments and inefficiencies of the processes made the teams more committed and faster.

Not relying on made-up yet rigid plans, but having a constantly updated view on the status and always taking the tasks that would bring the most value added the feeling of success and predictability.

It let the project go even faster.

The problem of Gantt charts

Who hasn't see Gantt charts? You know it's the popular chart diagram showing tasks displayed against time.

It was designed during the beginning of 1910s by a person called Henry Gantt and it was meant to represent plans for systematic routine operations.

One of its first major use was in the First World War by the US Army. World War I doesn't have the reputation of an organizational success story, yet we use this tool in modern project management shamelessly.

And do you know what's the main characteristic of these charts? They lie. They always do. The plans look good, but they always fall apart almost immediately. Reality is not taken into account and at the first delay, at the first tiniest change it loses its relevance and it has to be redone. According to Sutherland, there used to be people whose job consisted of nothing more than preparing these charts and keep them up to date.

The OODA loop

Instead, Scrum is not about creating schedules in advance that cannot be hold. It's about adapting to a constantly changing environment.

This need and the presented principles of adaption were extremely important at the Vietnam War where the author was a fighter pilot.

At the US Air Force, he got a training that helped him (and many others) to never lose his cool. The four actions to follow was

• Observe
• Orient
• Decide
• Act

It's also called the OODA loop which was formalized by Colonel John Boyd.

Take the 4 actions in loops. It's such an important concept that there is even a street in Alabama named after it.

First, both in warfare and business, you have to observe the situation, you have to understand the big picture. Then you have to orient yourself not just in a way to understand where you are, but you also have to take into account what you're capable of seeing.

With proper observation and orientation, you can (and have to) quickly make decisions and act upon them and then start the loop over.

In scrum, the result of such a loop is a working increment that helps the product owner to decide what's the next most important story to act upon, what will bring the most value to the customer.

There is Gantt chart to follow, there is the constantly changing world around us that we have to observe and orient ourselves within.

Size matters

One more interesting thing I wanted to mention from the book is that size matters and maybe a different way that you'd expect. I say maybe because if you've read the seminal book of Fred Brooks, The Mythical Man-Month you probably remember that simply adding more people to a project will not make it go faster.

Team dynamics form more difficult at scale. A lot.

It seems that this has something to do with our short term memory. As it was shown by studies, an average person can retain about seven items in their short-term memory. That's also the ideal size of the team.

You might err by +-2, but if you do, you should do on the negative side. Think about the number of communication channels in a team (n*(n-1)/2), where n is the number of members.

I never understand when managers form 10+ agile teams. They never work, people usually don't even know who the others are (especially in remote teams), what they do, why they are there. If you have such a team, it will naturally break down into smaller entities, but it's not something positive either.

Avoid it by forming small teams.

Conclusion

The end of the book could have been left out. No matter which side you are, you shouldn't involve politics in professional books I think and I say that as someone who was actively involved in politics. You have to be able to draw some borders.

Apart from that, I think it's an inspiring book with many real-life examples and pieces of advice. Some I'll follow, like the OODA principle and some I'd be happy if managers would follow such as the number of people on a team.

And if you've never seen a successful agile project (like many of us), then at least you'll have a few references.