SCRUM

The system used by the FBI to reorganize and streamline investigative methods after the September 11, 2001 attacks

Central Ideas:

1 – The Scrum system helped reorganize and streamline the FBI’s methods after 9/11. How? By defining sequential objectives in demarcated timeframes. With drastically reduced lead times and budgets, the system had an impressive impact on the powerful agency.

According to Putnam’s research, teams with more than eight people took much longer to complete tasks. Teams of three to seven people expended about 25% of the effort of those with between nine and 20 members.

3 – A team should hold daily meetings of no more than 15 minutes. The meeting must take place at the same time every day. Everyone must be present and actively participate, standing up during the meeting.

4 – What makes people happy? They are the same things that produce great teams: autonomy, mastery, and purpose. It is the ability to control one’s destiny, the feeling of being improving in some activity, of serving a greater purpose.

5 – The ideal is to work first on the tasks that add the most value and bring the least risk. With the incremental deliveries of the scrum, the goal is to start with elements that generate revenue immediately, to eliminate the “risks” of the project, the so-called “peaks”.

About the authors:

Jeff Sutherland is CEO of Scrum Inc. and a senior consultant at OpenView Venture Partners, where he provides coaching for venture capital investment firms. The co-creator of Scrum and the method’s leading expert, he has extended its benefits in software development to other segments, such as finance, healthcare, and telecom.

J. Sutherland, a journalist, spent most of his career covering wars, conflicts, revolutions, disasters, and terrorist attacks for the National Public Radio, in the United States. Today he writes and advises corporations and NGOs on how to use Scrum.

To overcome the shortcomings of over-meticulous but unproductive plans, in 1993 I invented a new way of doing things: Scrum. It is a radical change from the prescriptive and hierarchical methodologies employed in project management in the past. Unlike them, Scrum resembles evolutionary, adaptive, and self-correcting systems. Since its conception, the framework has become the way the technology industry creates new software and products. But despite its great success in software and hardware project management in Silicon Valley, Scrum remains relatively unknown in the business world at large. That is why I wrote this book: to reveal and explain the Scrum management system to industries outside the technology world. I will show how we organize projects around small teams – and why this is such an efficient way to work.

Chapter 1 – The Way the World Works is Wrong

Jeff Johnson was sure that day was not going to be good. On March 3, 2010, the Federal Bureau of Investigation’s (FBI) most ambitious modernization project was canceled – a project that was supposed to prevent another 9/11 but had turned into one of the biggest fiascos ever in the software industry. For more than a decade the bureau had been trying to upgrade its computer system, but now it seemed that the plan would not be realized.

The project was the long-awaited new computing system that would take the FBI into modern times. In 2010 – the age of Facebook, Twitter, Amazon, and Google – most of the agency’s reports were filled out by the paper. The system used by the FBI was called Automated Case Support. It ran on giant computers that had been the height of technology at some point in the 1980s. Many special agents didn’t even bother to use it. It was too slow and inconvenient for a time of terrorist attacks and savvy criminals.

In 2005, the agency announced a new program, Sentinel. This time it worked. They would take all the necessary precautions, perform the right budgeting procedures, and use the right control tools. They had learned their lesson. The price? A mere $451 million. By 2009, the system would be up and running.

What could go wrong? In March 2010, the answer fell on Jeff Johnson’s desk. Lockheed Martin, the company contracted to develop Sentinel, had already spent $405 million of its budget, had developed only half of the project, and was already a year behind schedule. An independent study estimated that it would take six to eight more years to complete the Sentinel, plus another $350 million in taxpayer dollars.

Jeff Johnson knew that the Scrum system could solve the impasse. For Scrum to work, someone high up in management needs to thoroughly understand that the obstacles are practically criminal. It took the Sentinel team about three months to figure out how long it would take to complete the project. Why? The answer brings us back to that “inspect and adapt” cycle. Scrum works by defining sequential objectives, which must be achieved within a defined time frame.

After reviewing the Lockheed project, it was concluded that it would be possible to finish Sentinel if the development was done by the agency itself and if the number of developers was reduced. This would allow them to deliver the most difficult part of the project in less than a fifth of the estimated time and for less than a tenth of the budgeted amount.

The system has had an impressive impact on the FBI. The ability to communicate and share information has fundamentally changed what the agency can do. In January 2013, an FBI agent was called when a small business account was hacked. The amount of $1 million had been transferred to another country before American banks could stop it. Using Sentinel, the local office was able to coordinate a joint action with the embassy of the destination country. The embassy alerted the local authorities, who in turn prevented the transfer from being completed in the banking system.

Chapter 2 – The origin of Scrum

I had worked at MidContinent and had helped to get ATMs up and running in the USA and around the world. Over the next 20 years, I ended up working for several companies as VP of Engineering. An unusual thing happened when I was near the MIT staff company in Cambridge, Massachusetts. They had subleased space from my company. This company was a manufacturer of robots. On one particular day, a six-legged robot came into my office and chased me around. I asked the robotics people how this could happen. Then Rodney Brooks, one of the founders of the robot company, appeared to clarify.

Rodney explained to me that he had used a completely different approach with his robots. Instead of designing a machine with a single central brain, his team built a robot in which each of the six legs had its brain. A processor in the skeleton had some simple rules: walk forward, backward, don’t hit the other legs. The neural network chip in the robot’s head knew these rules and acted as an arbiter for all parts of the body. When it encountered an obstacle, it would report to the legs what it saw through the camera.

Rodney Brooks’ work inspired me. In 1993, I took those ideas with me to a company called Easel, which had hired me as vice president of technology. The company executives wanted my team to develop in six months a new product line that would be offered to some of their largest customers – such as Ford, which was using their software to design and develop in-house functionality. I met with my development team and told them that I knew it was not possible to do this using the old software development model.

One day, one of the developers brought up an article published in the Harvard Business Review in 1986, written by two Japanese business professors, Hirotaka Takeuchi and Ikujiro Nonaka. The title was “The New New Product Development Game”. Takeuchi and Nonaka had analyzed teams from some of the most productive and innovative companies in the world. They argued that the old method used for product development, symbolized by NASA’s Phased Program Planning system – a waterfall system – was completely flawed. Instead, the best companies used an overlapping development process that was faster and more flexible. Teams were cross-functional. They had autonomy.

Japanese professors compared teamwork to a rugby team and said that the best teams acted as if they were in a scrum: “The ball is passed around by the team as it moves, in unity, down the field.”

At Easel, we had nothing to lose. We decided to try the new approach, even though the focus of the article was product manufacturing, not software development. I thought those ideas addressed a fundamental point, a descriptive process of how human beings work best together in any endeavor. They had been present in every other experiment I had conducted since my first private-sector job at MidContinent.

This was the formal birth of Scrum. We delivered the product to Easel within six months, without spending the entire budget, and with fewer bugs than any previous delivery. In 1995, at an Association for Computing Machinery research conference, I presented a paper with Ken Schwaber entitled “SCRUM Development Process” that systematized these practices. From then on, my work focused on refining Scrum for business.

Chapter 3 – Teams

Lawrence Putnam is a legendary figure in the field of software development, and he has devoted his life to studying how much time is spent getting things done and why. His work repeatedly showed that projects with 20 people or more took more effort – much more. A large team took about five times as many hours as a small one. He saw this repeated on several occasions, and in the mid-1990s he decided to conduct a comprehensive study to try to determine the ideal team size. He analyzed 491 medium-sized projects in hundreds of companies. All of them required the creation of new products or functionality, not a reformatting of old versions. Putnam divided the projects according to team size and noticed something early on. When teams were larger than eight people, they took much longer to complete their tasks. Teams of three to seven people took about 25% of the effort of those with between nine and 20 members to do the same work.

At the time of the first Scrum team, I often showed the team members a video of the All Blacks preparing for a match. The All Blacks, a legendary rugby team from tiny New Zealand, are a transcendent team. Before every match, they perform the haka, a Maori warrior ceremony. The haka is a dance that energizes people who are about to face battle. Watching it, you can almost feel the energy coming out of each player merging into a great unity. From hand and foot stomps and synchronized chants, you see ordinary men transform into something greater.

After the exhibition, the members listed four aspects that deserve to be emulated. The first is the intense concentration on the goal, the second was the extreme collaboration, the third was the drive for destruction, and the fourth was the excitement when someone managed to advance with the ball. So we set up this structure of sprints, daily standing meetings, reviews, and retrospectives, and I realized that we needed someone whose job it was to make sure the process worked. The group gave this leader a name: Scrum Master. He would lead all the meetings, make sure there was transparency, and help the team figure out what was holding up the progress of the project.

Smaller is better. Small teams work faster than large ones. The rule of thumb is that seven members are ideal – it can be more or less two.

Chapter 4 – Team

In the early 1990s, I was invited to work at Borland Software. Among other things, I noticed that the daily meeting there lasted at least an hour. This seemed too long to me, so I examined what were the essential issues to be addressed at this time. And so the daily meeting was put into practice. We had certain rules. The meeting took place at the same time every day, and everybody had to participate. If the whole team was not present, communication simply would not work. And it didn’t matter what time we scheduled, as long as it was the same time every day. The point was to give the team a regular rhythm.

The second rule was that the meeting could not last longer than 15 minutes. The idea was to get as much valuable and useful information as possible in as short a time as possible. The third rule was that everyone had to participate actively. To help with this I asked everyone to stand. In this way, we would talk and listen actively. This would also help to keep the meetings short.

At Easel, with the first Scrum team, we implemented the daily meeting during the third sprint. We had planned four weeks for that sprint – about the same workload we had the previous month. We finished it all in one week. A 400% improvement. On that Friday, the members looked at each other and said, “Wow!”. It was then that I realized that maybe I was on the right track.

Scrum changes the way you look at time. After participating in a few sprints and daily meetings, you stop seeing time as an arrow pointing into the future and start seeing it as something cyclical. Each sprint is an opportunity to create something new, a chance to improve.

Chapter 5 – Waste is a Crime

As I have already mentioned, most of the ideas in Scrum come from the Japanese manufacturing model presented in the classic book The Toyota Production System by Taiichi Ohno. In the United States, this method has been interpreted as a “lean” production model. The intention is to eliminate as much waste as possible in the manufacturing process. Of course, most of us are not trying to improve the flow of the automobile industry, but some of the ideas apply to any kind of work.

One concept I want to address here is that of “work in progress”, or just “inventory”. We should remember that it is wasteful to have around us a bunch of items that are not being used to build anything. Many things can be lying around in the factory, not having a use. An example of what is going on is a bunch of half-built cars in the automobile industry. This means that it has spent a lot of money and labor, but has not created anything that has any value. In lean manufacturing, the idea is to minimize the amount of half-built material sitting around in the factory. The power of this idea can be applied to any kind of work.

As already stated, there is a rhythm to the work in Scrum. In each cycle or sprint, the team tries to do several things. But to move into the “Done” column, the product needs to be complete, ready to be used by the customer. At the end of the sprint, something half-done is worse than something not yet started, because resources, effort, and time have been spent and nothing has been developed to the point where it can be delivered. It is like having half a car. Maybe it would be better to create something smaller, but that works.

Chapter 6 – Plan for reality, not fantasy

In your job, how many times have you been given a task that you don’t understand why it needs to be accomplished? Someone asks you to determine the month-to-month sales variation in region A in stores larger than 50 square meters. You do it, but you don’t know why it is necessary. And because of this, you may provide the wrong kind of data, misinterpret the question, or resent being given a lot of useless work. Or, if you are a manager, you may be shocked that your employees do not understand at first that you are considering closing small stores and opening large ones.

The problem is that you are not getting or providing enough information to get the job done the right way. People think through narratives, through stories. This is how we understand the world. We intimately understand characters, desires, and motivations, but we have difficulty extracting discrete roles from the main plot and dealing with them out of context.

So when you are designing an assignment, the first elements you should take into consideration are the characters or roles – for example, a client, a bride, a reader, an employee. For whom is this work being done? Should we put ourselves in whose shoes as we build this thing, make this decision, or deliver this product?

Next, you ask yourself what – what do we want to do first. We usually start and end projects with this information. But it is only in the middle of the process that we are executing. Finally, you need to think about motivation. Why does this person want this? How is this product going to serve and delight this customer? And in a way, this is the most important part. Motivation is what gives color to everything.

In practice, we have found that if the stories are ready, the team will double the speed of implementation. And if the stories are completed by the end of a sprint, teams can double speed again. This is one of the tricks needed to do twice as much work in half the time.

Know your speed. Every team should know how much work it can accomplish in each Sprint. And they should also know how much they can increase that speed by working smarter and removing barriers that slow them down.

Chapter 7 – Happiness

To be effective, a sprint requires a certain level of emotional maturity and an environment of trust. Everyone must remember that they are not looking for a culprit, but rather examining the process. Why did it happen that way? Why didn’t we understand it? What would make us work faster? Individuals must take responsibility for the process and the results as a team and seek solutions as a team. At the same time, individuals need to have the emotional structure to bring up the issues that bother them in a way that seeks a solution, not in a way that appears accusatory.

The “happiness metric” was the best method I found to capture all of this. It is a simple but very effective way to get at what kaizen [improvement, in Japanese] should be, but also the kaizen that will make people happier. I’ve used this technique and had great results.

At the end of each Sprint, each team member answers a few questions:

on a scale of 1 to 5, how do you feel about your role in the company?
On this same scale, how do you feel about the company as a whole?
Why do you feel this way?
What would make you happier in the next sprint?

What makes people happy? It’s the same things that produce great teams: autonomy, mastery, and purpose. Or, using more words to say the same thing, it is the ability to control one’s destiny, the feeling of getting better at some activity and of serving some higher purpose.

As I mentioned before, I don’t care much about individual performance; all that matters is the performance of a team. I can double the productivity of a team in a month, but that of an individual? An entire company? That could take forever. So I use transparency to focus on improving the team. I often find that the team itself can solve individual performance problems. The members of the group know exactly what people are doing, who is helping, who is hindering, who makes the team great, and who makes the work painful.

The “happiness bubbles” is a subject that calls for comment. They are of great concern because they are the point at which the Scrum formulas may get off track. I have seen this repeated several times: the team does everything Scrum teaches – prioritization, doing one task at a time, cross-functionality, review rituals – but stops improving. The staff relaxes: “We don’t need to improve anymore.” The consequences are predictable…

Chapter 8 – Priorities

The key, therefore, is what you decide to accomplish first. This is the question that must be asked: what are the items that have the greatest impact on the business, that are most important to the customer, that can generate the most money, and that are easiest to do? You need to keep in mind that there are a lot of items on the list that will never be put into practice. The ideal is to work first on the tasks that add the most value and bring the least risk. With the incremental development and delivery of Scrum, the goal is to start with the elements that will generate revenue immediately, to eliminate the “risks” from the project.

In product development, there is a simple rule that has been proven true time and time again. I have talked about it before: 80% of the value is in 20% of the functionality. In anything you buy, most of the value – most of what people want – is concentrated in only one-fifth of what has been developed. The trick with Scrum is to determine how to develop that 20% first.

When choosing a Product Owner, hire someone who can put himself in the shoes of the person who will get the value from what he is producing. As a friend of mine says, “My wife is the perfect Product Owner; she knows what she wants. I just have to realize it”.

The Product Owner not only needs a broader range of skills than the Scrum Master. These skills also need to be put into practice according to a different set of standards. The Scrum Master and the team are responsible for the speed of the work and how much they can increase it. The Product Owner is responsible for translating the team’s productivity into value.

Chapter 9 – Change the World

I have begun to see the method being applied in the most unlikely areas, to solve the thorniest problems facing humanity. Think about some of these problems. For example, people living in poverty, are not only demeaning but also generate a host of social ills, such as crime, corruption, war, and destruction. There is also our educational system, which fails students around the world. Instead of teaching 21st-century skills, we bog our young people down in teaching and learning methods created in the 19th century. And another dysfunctional element that comes to mind is the government, which uses outdated methods.

But let us not be discouraged. There are good examples to be emulated. In Olympia, the capital of Washington state, the last two governors have adopted what we call lean government. Governor Jay Inslee, created five points that can be found in any campaign platform: 1. a “state-of-the-art” education system, from pre-school through college; 2. a “thriving economy”; 3. making Washington a national leader in sustainable energy and clean environment; 4. healthy and safe communities; 5. efficient, effective, and accountable government.

Washington State’s chief information technology officer is responsible not only for the technology that is purchased but also for how it is produced. The department consists of 20 people whose job is to make sure that huge IT failures, which can cost tens of millions of dollars, do not occur.

To do this, the department uses Scrum. The employees have organized themselves in the form of Scrum teams. Michael D’Angelo, the deputy director of IT, says that every week the team tries to deliver policies to the state departments that can be put into practice: “We are updating the process of how our agencies submit investment plans. We set a goal of changing one thing a week. Our approach is progressive. Every week we have a potentially usable product that can be tried out by the agencies. They get something tangible.

Scrum in schools in the Netherlands. In the Netherlands, an increasing number of teachers use Scrum to teach high school classes. They see an almost immediate improvement of more than 10% in test scores. And they are engaging all kinds of students, from those who want to pursue a simpler profession to the gifted. eduScrum, as Professor Willy Wijnands calls his approach, is introduced to students on the first day of school. Their first task is to choose teams, which need to be cross-functional. The students evaluate them in various categories, such as bravery, enjoyment of mathematics, concern for the feelings of others, and “focus on goals.” They are then guided to form cross-functional groups that have all the skills needed to learn the subject.

Grameen Foundation in Uganda. The Grameen Foundation was created by Nobel Prize winner Muhammad Yunus’ Grameen bank. The foundation focuses on helping to lift people all over the world out of poverty. In Uganda, the institution decided to try to do just that: by giving the poor the ability to share and produce knowledge. Scrum has collaborated to do this.

Eric Kamara leads the technology group in the Grameen Foundation’s Kinshasa office. His group uses Scrum to develop its applications, which are mainly dedicated to sharing agricultural techniques and marketing facilities. He says that every time someone asks for a set of features, his team rates the request on a scale of 1 to 7. Before Scrum, people asked for everything at once. With the limited resources of a non-profit organization, it was impossible to do everything. Scrum helped scale the functionality, transparently.