This post is about insights I learned from comparing what people tell me about Scrum to how one of its creators, Jeff Sutherland, intends it to work as described in his book “The Art of Doing Twice the Work in Half the Time”.

Disclaimer: I work as an Agile Coach at Zalando, most of the issues described in these posts refer to talks with people from other organizations.

Having worked in the software industry in Berlin for a while, I have had a lot of discussions about how teams organize the way they work. Quite often teams say they are using Scrum, because it is sort of the “default workmode” to fall into when doing agile software development. Again quite often people do not seem to be happy with it, often citing endless planning meetings, pointless standups, powerless scrum masters and product owners demanding too much from the team.

In my opinion most people only conduct the ceremonies of Scrum, without understanding their intent, thereby creating unnecessary pain and friction. So I decided to have a look at the deeper philosophies behind Scrum by reading “The Art of Doing Twice the Work in Half the Time” by Scrum’s Co-Creator Jeff Sutherland.

Sutherland describes Scrum as a way to change the world for the better by being a framework to enable teams to deliver much more value and much faster than in “traditional ways”.

He concludes the book by describing how Scrum can be used to revolutionize our educational system, improve government efficiency and end poverty (seriously</u>[1]). Another sign that Sutherland thinks extremely high of this way to work is that he does not shy away from using successful army interventions, the Declaration of Independence or even the arab spring as a backdrop for stories where Scrum was used.

The traditional ways he often rallies against are anything where organizations build barriers between people that could profit from each other and remove employees from the actual value creating activities. His deterrent example is the NASA design process that has 7 different and disjunct phases. So what is Scrum?

What is Scrum from the ground up

According to the book Scrum is a framework for teams to create products. Scrum comes from the software development world, but works (presumably) everywhere.

The core of scrum is the not the manager or the individual employee, but the team, that is creating the product. The term comes from the game of rugby and refers to the way a team moves the ball down the field. The mental image of a team by Jeff Sutherland’s liking is apparently the All Blacks NZ rugby team.

Yes, this is the way your bunch of geeky software developers is supposed to look, according to Jeff Sutherland. Or well, at least they should aspire to achieve the kind of teamwork you see in awesome sports teams that seem to play together like one. What you can see there is:

  • Careful alignment
  • Unity of purpose
  • Clarity of goals

These are already the most important elements of Scrum (and great teams in general): purpose, alignment, goals. If you have that you are basically doing Scrum, no matter how else you organize your work.

If you do not have these, you are not doing Scrum, even if you are doing weekly sprints, daily standups and regular retrospectives and reviews. An additional ingredient that you get for free in a sports match is transparency. In Scrum, all information should be transparent to the team, the less secrets there are, the more productive a team can be. This goes for visions, milestones, progress, problems, and ideally even compensation. A very honest illustration of this principle is given by Sutherland in his own company: Salaries are shared among employees.

Sutherland carries the metaphor of the Rugby team even further. Look how the All Blacks team prepares before a match:

This is the inspiration for the daily stand-up meeting! After the meeting, this team has:

  • An intense focus on the common goal
  • Intense collaboration, think of interlocking arms in the Scrum
  • A hunger to crush their enemies (and/or impediments)
  • Universal excitement on reaching the goal

I think it is slightly exaggerated to compare your software team to the New Zealand Rugby team, but I see no reason why your aspirations should not be high.

Of course there is more than this most important and basic lesson. This is what I learned about common Scrum elements from this book:

Scrum vs Kanban - one origin

It is often seen as a choice to either use Scrum or Kanban (i.e. Toyota Production System) style processes for software teams. However, Scrum is deeply inspired by ideas from the Toyota Production System (TPS). It is introduced in the first chapter and presented as the guideline behind Scrum. Sutherland does not really explain why this was the inspiration, but most Scrum concepts are introduced by referring to their counterpart in TPS

  • Eliminate Waste / Mura - Removing impediments
  • Kaizen - Retrospective after sprint
  • Tact / Rhythm - Sprints, Stand-ups etc. are designed to form a working rhythm
  • Chief Engineer - Product Owner

And so on. So this should be the answer if people are haggling about whether to use Scrum or Kanban: Scrum is an instance of TPS, just like Kanban is one element out of it.

Demo cool stuff that works

Teams often struggle with presenting finished pieces of work at the demo to stakeholders. Complaints are often that things are finished only to be “demoable” and there is a fear that punishment follows if there is not enough things to demo.

It helps to look at where Sutherland got this idea from: His office neighbors in Boston was a start-up robotics lab, with many small and new projects. They determined whether they should continue a project or not, by having everyone show something cool and finished from their projects every couple of weeks. The point was to get feedback from peers and together decide if this was worth pursuing. In our business, cool probably could be substituted by providing value, so the point of the demo becomes showing what cool things you achieved for your user (and get feedback from them).

Planning should be fast

I know that for many teams Scrum planning meetings are dreadful and endless. Interestingly in this book, only 1 paragraph is spent on this meeting. The reason is obvious: Sutherland thinks the planning meeting should be a well-prepared, efficient meeting. Stories are supposed to be ready before the meeting (with a proper definition of ready, e.g. through the INVEST criteria. Planning Poker should be a fast process, where only differences greater than 3 levels are discussed. In all other cases you just add the numbers and average them.

Let’s look at other elements of the planning process, stories, velocities, estimation and sizing.

Stories

For many teams, stories end either end up being lists of tasks, or some weird and confining way to write down intentions. Stories are supposed to give more context than a simple description of a task, enabling better decisions:

  • Who needs something to be done
  • What needs to be done (this is what a task only consists of)
  • Why something needs to be done

I think the last point is crucial, because understanding the intention behind a change greatly makes it easier to implement it.

Velocity is for improving

Estimating stories and tracking velocity seems to be the most painful part of Scrum that teams seem to drop earliest. So why are they brought upon us?

The reason Sutherland added this element to Scrum, is so that the team is able to evaluate improvements. The philosophy behind Scrum (coming from the TPS) is to reduce waste. Put positively (the way Scrum does it) is that a team’s goals is to always accelerate and always improve the amount of value they deliver. All over the book, Sutherland rarely talks about teams delivering something, but always about teams accelerating their delivery. And I must agree, the most objective way to evaluate any improvement you do is to see if you are able to get more work done.

Relative sizing helps your brain

When teams estimate stories they have to use some unit for it. Often Fibonacci numbers are recommended, leading at some point to the team estimating the work by number of hours they think it will take. Why is this a bad thing?

The reason lies in psychology: Humans are Bad at absolute sizing but good at relative sizing. This estimation can also be seen as a relief: You do not have to know how long it will really take you. Only if you think that task A is that much bigger than task B.

The Cliff if you feel too comfortable

So you keep improving and improving. At some point you are great and can just continue as you do and stop wasting an hour a week doing retrospectives.

Sutherland says no, and I agree. If you (as a team) stop having the aspiration to continuously improve your performance, you will become complacent, accepting occasional slips and in the long run develop bad habits that will bring your team to a screeching halt. How to make this visible?

You have to keep measuring your performance by outside indicators: Velocity, Customer happiness, quality of code or even team happiness. There are so many areas for improvement, there is no way you are ever done.

The Product Owner inspires to deliver

In many companies these days you have separate pools of Product Owners and Scrum Masters. Often they are seen as a kind of antagonism around the team, the product owner wanting more things delivered, the scrum master wanting process improvement.

Interestingly in his first Scrum project Sutherland filled out both roles at the same time. As the Leader he was responsible that the team actually creates something of value (PO part). And he wanted the team to accelerate and become faster with every iteration (Scrum Master part), to be able to deliver more value. As you can see, the goals of these two roles are obviously the same. The reason he split it was to ease the high burden on the people fulfilling these roles[2].

The role model for the PO role is the Chief Engineer at Toyota. This is an engineer that is responsible for a whole production line, for example for a car. However he does not have direct authority over other workers, he has to inspire people with a vision and motivate them to work towards it. This role model maybe helps if your product owner is struggling to fulfill his role.

Conclusion

What I miss a bit is some hint how to bring in stories that are necessary to build a solid technical base, but do not directly provide visible value to a customer. The most prominent example is a refactoring that enables easier change later on, but is completely transparent to a customer. After reading the book I would try to phrase this as a story with the product owner as character.

What I like was how Sutherland based a lot of his decisions on sound psychological research. Planning poker for example is devised to prevent, anchoring, the bandwagon effect, halo effect and groupthink. Also using relative sizes is important, because research has shown humans are very bad at absolute sizing, but rather good at relative sizing.

All in all reading the book was a great way to better understand the aspects of Scrum that teams often seem to struggle with. What is Scrum from the ground up, Scrum vs. Kanban makes no sense, Demos are to show cool stuff that works, planning meetings should be quick and painless, velocity is for improving, relative sizing helps your brain and the product owner inspires the team to deliver a great product.