Scrum, by Jeff Sutherland, Part 2: The Most Useful Lessons

This is what I really wanted to post about when I first created this series, however, coming out bluntly with this content, without context, seemed strange, so that's why I created of this series, in order to introduce the topic more gently.

Now I will be writing about some of the most pragmatic topics of the management discussion in the book. The 6 most important and impactful ones are, in my opinion — their brief titles will hopefully be more clear later on —:

1. Teams Outpacing the (huge) Disparity between Individuals (p. 41)
2. Communication Channels inside Teams (p. 59)
3. The Multitasking Loss Table (p. 90)
4. Fixing Mistakes Now vs Fixing Mistakes Later (p. 98)
5. The Productivity/Burnout Graph (p. 102)
6. How We (should) Will All Work One Day (p. 222)

Before you start, I would like to add that \( Production = Productivity \times Hours \ of \ Work \). Most people will force themselves and their colleagues to increase the last term, but only to later find out that productivity dropped due to burnout; and that the production output is either less or equal to before. What we should actually focus on is productivity, efficiency. It will grant us a more enjoyable experience, more time and, as research shows repeatedly, more production.

Note: I've also included in the sections' titles the pages (e.g. "p. 41") where you will find the respective discussion inside the book. I've read it in the Kindle version, but the pages there are indexed in the same order as they appear in the physical version.

This is something closely related to my experience as a team athlete more than 10 years ago. People who have never had experience with teams, where the goal necessarily demands that everyone help each other, tend to display very selfish behavior; and I've seen some report that they would rather do the work by themselves because their colleagues are not as good or present a waste of time for them. This is not only selfish but irrational and wrong, because the point is to compete against other teams, not against your own.

In this light, it was then appalling to me when I saw Go players having poor reactions while playing in pairs: they had developed such an individualistic point of view of the game that they couldn't positively interact with someone who wasn't at the level of their standards.

Needless to say that working in teams is basically mandatory in the real world. Individually, it would take us forever to complete the same projects teams can tackle. And yet, we tend to not teach people how to properly play on teams, we tend to put an erroneously enormous value on individuals.

When hiring, we would like to simplify our choices by simply looking for the best professionals, the best individuals. However, some studies indicate that prioritizing individuals might be a crucial mistake, we should actually put more importance on how the individual can work with the team.

In a Yale study trying to figure out what separated top from normal (computer science) students, it was found that the fastest students outpaced their slow counterparts by a ratio of 10:1. Impressive, huh?

In another study that looked at some 3,800 different projects, ranging from work done at accounting firms to software development for battleships to tech projects at IBM, the researchers discovered that the fastest teams outpaced the slowest by a whopping 1000:1 ratio.

The borderline here is: who cares about 10:1 ratios when you can gain 1000:1 if you invest elsewhere?

What, then, separates a mediocre from a lightning fast team? The biggest challenge to getting into the 1000:1 select club is actually the mindset. It takes convincing, it takes a lot of arguments, it takes talking to people and being (wrongfully) rejected multiple times. But, once the change is made, the span of improvement is jaw-dropping high. As Sutherland puts it later in the book:

I can double a team’s productivity in a month, but an individual? That could take a year.

In the end, what usually seems as an overinvestment on teams is probably not the case, because the rewards are actually astronomical. Committing yourself to improving teamwork is probably more valuable to everyone than improving yourself.

Scrum has this team focus implicit in its foundations. For example, Daily Stand-Ups were created as a way to share information and enhance team synergy. In a study that tried to find out how people can code faster, one of the subjects was the legendary team at Borland, in which each coder was writing a 1,000 lines each week. Their key to this was that their communication saturation had the highest rating ever: 90% (most companies hover around 20%). What was the source of this very impressive rating? One hour Daily Meetings — Sutherland mentions that he thinks that's a bit too long; that's why Scrum's Daily Stand-Ups last 15 minutes at most.

It's a common saying, at least in software development, that large teams only make projects take longer. That mostly comes from experience, but it also has a scientific background.

In teams, people have to communicate to each other. Information has to flow, to be shared. In this way, the group will develop communication channels between every couple of individuals. By connecting everyone, the total amount of communication channels in the team grows very fast. If you wish to prove it to yourself, draw polygons of increasing number of sides and connect all of the vertices to each other. In the end, you might realize that the number of Communication Channels (CC) follows the following quadratic formula:

\[ CC = \frac{n^2}{2} - \frac{n}{2} = \frac{n (n - 1)} {2} \]

Research has shown that we can only keep 4 (sometimes up to 7 at best) pieces of information at the same time, in our working memory. A more or less classic team formulation is of 7 +- 2 people, because the number of communication channels can range from CC(5) = 10 to CC(9) = 36, which we can kind of manage optimally, but is already frightening in comparison to what our working memory can handle. Now, imagine when you put a seemingly not that many 12 people on the same team. While we would have 15 communication channels in a team of 6 people, this number grows to 66 for 12 people, basically 4x what is considered manageable.

Having too many people on the same team will not only be a catastrophe because it will be difficult to achieve good communication, but because information will spread very slowly and, since there will also be more steps (people) before it stabilizes, it will more easily become corrupted, leading to a scenario where misinformation happens more frequently, causing people to invest a lot of time into fixing what they do because it was probably wrongly specified. So, what managers should do is to actually keep their teams small. If you have a department — please, try to eliminate departments... — with more than 9 people, it's better to break it into smaller teams.

It is common to witness "highly productive" executives bragging about how they can multitask and juggle multiple projects at the same time. But that actually should not be a source of pride. Research has shown time and again that multitasking is a highly inefficient way of spending one's time.

Every time you switch from a context to another, your brain takes time to readjust itself and, more often than not, you will also have to recreate a specific hardware or software setup in order to properly manage the task, which adds to the inefficiency.

In one of the classic works on how to develop computer software, Quality Software Management, by Gerald Weinberg, the Context Switching Table is presented — which was mostly built from experience with a reasonably large amount of projects —:

For example, if you have only 2 projects to be managed, already your inherent loss to context switching goes to 20%, which is unexpectedly high. But, if you go to the extremes of where most executives live (5+), you will find that each project will have effectively only at best 5% of the available time.

A scientist named Harold Pashler demonstrated this in the early 1990s. He called it “Dual Task Interference.” He conducted a few simple experiments. He would have one group do one really simple thing, say press a button if a light went on. And then he’d give another group that task plus another simple one, like pressing a different button depending on the color of the flashing light. As soon as another task was added, no matter how simple, the time involved doubled. Pashler theorized that there was some sort of processing bottleneck — that people can really only think about one thing at a time. He reckoned that a certain amount of effort is involved in “packing up” one process, reaching into your memory and pulling out another, and then running that job. And each time you switch tasks, that process takes time.

It is true that sometimes it is inevitable to multitask, but that should be avoided and the exception, and definitely not in the bragging standards.

Regarding production efficiency, it seems logical to think that it would be much easier to systematically take notes of what is not correct across the production line and then, at the end, have a team fix all the issues all at once. But things are not that simple...

If you do it that way, there will most likely be an informational loss between the person diagnosing the error at first glance and what the fixer will see. Not only is it an interpretational problem, but there is also the fact that other components will be built on top of the mistake, which might change the behavior the fixer later sees, possibly leading to a very different diagnosis.

Building on top of mistakes seems to be argument enough for people to discard fixing issues at the end of the production line. But, unexpectedly, it is in use in many companies, including some that pride themselves in their service or product quality.

Mercedes-Benz, Audi and BMW are some of the examples — at least at the time of the writing of the book. For BMW, it would take 57 hours to make a car, and they would have 78.7 defects for every 100 vehicles. Of the 57 hours, 15 to 20 would be spent trying to fix all of the issues.

In contrast, Toyota, Honda and Nissan would take 16.8 hours to manufacture their high-end cars, with only 34 defects per 100 vehicles. The German manufacturers were taking more time to fix their cars than the Japanese were taking to manufacture a totally new one from zero to finish.

The mistake here is assuming that fixing mistakes should be in the same category of any other production task. But it absolutely is not. It is much easier and quicker to fix mistakes right away rather than later because, as previously mentioned, nothing will have corrupted the source of the problem, it will be easier to find the root cause and you won't have to undo anything. For these reasons, the Japanese manufacturers will have all of their line workers capable of fixing a problem and, in order to not have the production line stop, whenever an issue arises, all of the nearby workers swarm it and fix it as quickly as possible.

When it comes to computer software, the problem is similar, but maybe even more drastic. A company called Palm, which developed some of the very first PDAs (Personal Digital Assistants), managed to track automatically everything they were coding, including bugs and testing. Later, in an internal study, they analyzed how much time it took to fix a bug — i.e., how much time it took a software developer to fix a problem he'd introduced into the system. More specifically, they analyzed the difference between fixing the bug now and fixing the bug later (3 weeks) — much like Toyota's and BMW's productions lines —, with data coming from hundreds of developers. What do you think was the difference?

It took 24x longer to do it later — if you had not given the proper value to Test-Driven Development (TDD) yet, now is your chance. Procrastinate and a 1-hour bug will turn into a whole 24-hour ordeal. In short, do things right the first time.

In the book, Sutherland mentions the story of Scott Maxwell. Scott worked at McKinsey & Company in the early 1990s and had to endure the firm's culture of inhuman overworking. The bare minimum was to basically work 7 days a week. For religious reasons, Maxwell was only able to work 6 times a week. However he soon realized that, somehow, he was able to deliver more than his more hard-working colleagues that came in all day everyday. How?

When working too many hours, we inevitably get tired, and, therefore, it becomes very easy to involuntarily and unconsciously make mistakes. In the end, very often, his colleagues would be using their working hours to create and fix their own mistakes without even noticing the pattern. Slowly, he managed retract into only working 5 days a week, later finding out that he was still delivering more than his colleagues. He thought about trying to work for only 4 days a week, but was afraid of the repercussions.

Later, when Maxwell got his own venture capital firm, he crossed paths with Jeff Sutherland, who inspired him into studying and investing on the topic again. This time, after collecting some data, he came up with his Maxwell Curve, i.e., Amount of Work Produced vs Hours of Work per Week. The results are shocking to some workaholics. And should be a very big lesson to executives who love to micromanage their subordinates and force them to go beyond the usual 40h/week journey.

It turns out that the peak in production is actually less than 40h/week. After noticing it, Maxwell started to send people home early, which resulted in more output for the company, better product quality and happier workers.

With the results given by Scrum and other new methods of management, it is clear that it is time to break away from the traditional, old methods. But how? How would you organize your structure to boost production and free the employees in order to guarantee innovation while still controlling the company?

Formed in the 1990s as a videogame company making revolutionary hits such as Half-Life and Portal, Valve is completely self-funded and owns all its intellectual property. Almost all of its 300-plus employees are located in a single office tower in Bellevue, Washington. The company has over fifty million customers, and it makes hundreds of millions of dollars a year. And no one is really in charge.

What do they mean by no one is completely in charge? Here is an excerpt of Valve's New Employee Handbook, entitled "Welcome to Flatland":

It’s our shorthand way of saying that we don’t have any management, and nobody “reports to” anybody else. We do have a founder/president, but even he isn’t your manager. This company is yours to steer — toward opportunities and away from risks. You have the power to green-light projects. You have the power to ship products.

A flat structure removes every organizational barrier between your work and the customer enjoying that work. Every company will tell you that “the customer is boss,” but here that statement has weight. There’s no red tape stopping you from figuring out for yourself what our customers want, and then giving it to them.

If you’re thinking to yourself, “Wow, that sounds like a lot of responsibility,” you’re right.

Every Valve desk has wheels. Once people have agreed on a product or project, they move their tables to a more fitting area in order to better work together. It's a living organism!

The traditional structure, as it stands, actually doubts the employee will deliver a product. Micromanagement and infinite reports become common practice. While that is the only way of making some people work, many, if not most, actually do want to work and create and micromanaging them will cripple their abilities innovate.

Of course, Valve has to be very careful when hiring people, and, in their manual, they emphasize that hiring is the single most important task in the whole company. Without people with the correct mindset and capabilities, the whole environment might work against the company's values and objectives.

Continuing Valve's justified rant about the typical organizational structure:

Valve is not averse to all organizational structure — it crops up in many forms all the time, temporarily. But problems show up when hierarchy or codified divisions of labor either haven’t been created by the group’s members or when those structures persist for long periods of time. We believe those structures inevitably begin to serve their own needs rather than those of Valve’s customers. The hierarchy will begin to reinforce its own structure by hiring people who fit its shape, adding people to fill subordinate support roles. Its members are also incented to engage in rent-seeking behaviors that take advantage of the power structure rather than focusing on simply delivering value to customers.

Evidently, unfortunately, not all departments can work like that. Support and IT departments, for example, even at Valve, still do have more or less traditional structures. Nevertheless, we shouldn't stick so fiercely to old models, to the comfortable status quo that has repeatedly been proven to instill bad habits, low quality of life and low productivity. The traditional structure is not the only way, there are in fact other, better structures.

Instead, embrace change, free your mind. Think about implementing improved, new management methods first and only fall back to traditional ones if the new ones aren't a good fit — note that there is no assumption that you need to be a software company for these methods to work; in fact, many other companies already use them in other areas, such as building cars that get over a hundred miles per gallon (Team Wikispeed) or being the global leader in tomato processing (Morning Star).

Free your mind... and your ass will follow.

Funkadelic, 1970.