End the Scrum Revolution, Begin the Scrum Evolution

An organization is a network of complex dependencies. Because of this complexity, any change in any direction will face some resistance. The major difference between a waterfall project and a Scrum project is that the latter encourages and even welcomes change. How do you introduce Scrum to a non-agile organization without facing major resistance?

Unfortunately, in their efforts to apply Scrum, companies often take the head-first approach, seeking a revolution. They look at the ideal world of how a fully agile company is run, take parts of it and stick them on their own organization. This is like putting wings on a dog and shouting at it:

“Now fly!”

And, lo and behold, the dog will just sit there and look bewildered. Consequently, Scrum gets the blame and the chapter of agility is either closed or “adapted,” with the company running Scrum in name only.

How can you teach your organization to “fly”?

Managing Your Employees vs. Providing a Vision

Change can be taught by one of two methods:

You demand that the student follow your exact instructions. It will hurt, and it will cause muscle ache, frustration and exhaustion. Yet, sooner or later, the student will learn the right technique and will favor it over other techniques, feeling the difference. This method is often used in sports, especially because the wrong moves can cause serious injuries. You start with what the student already does and offer a path of small improvements. This method is preferred if the student simply cannot perform the optimal technique at that time. Singing is a prime example: if you demand perfection, the student will never finish his or her first song; the learning curve is simply too steep.

Having played chess for many years, I prefer the second method and tend to approach problems as I would approach a game. When looking at a company’s agile transformation, I see the current situation as the starting position and the agile ideal as an approach to “win.”

Many preparatory moves are required to get to the finishing move, which in this case would be the implementation of the solutions that Scrum offers. It is like walking through a labyrinth where you are sometimes moving away from your actual goal, having to take one step back to move two steps forward.

Encouraging your organization to “fly” is not necessarily a bad idea. But this should be done by providing a vision and leading your coworkers through the process of change. In this way, they can deal with the actual implementation through evolutionary change instead of having management trying to give exact instructions or ignoring the knowledge and abilities within the teams.

How Should You Navigate the Maze of Agile Transformation?

When I first read about introducing Scrum in a company, I found it excessive, or maybe a type of “showing off” that the literature proposes to have the team executing the transformation use agile themselves as their project management methodology. It sounded like a salesperson proclaiming that their product can be used anytime, anywhere. Yet, after some experience in the industry, my view on this has changed.

The point is that the significant challenge of the agile transformation is that the requirements are not fully defined. Every single organization is different, so there is no standard way of introducing Scrum to a company. This makes it a perfect candidate for evolutionary change--- navigating through these unknowns in small but steady steps.

The First Rule of Teaching Scrum Is to Not Talk About Scrum

The first thing I tell people I coach about Scrum is to forget everything they have previously heard about Scrum. I am in no position to know better than they do what their problems are, or to think that “my” methodology would help them. Scrum is not a magical cure. Management gets too quickly enamored with the idea that there is a method that, once it’s been introduced, will solve their problems. Since this simply isn’t the case, the question remains, how can organizations achieve real change?

In my opinion, change can be achieved only by means of mutual trade. You can win over the other side if you offer an advantage. The simplest way to connect your team with the idea of Scrum is to give them a helping hand. Do nothing else but have them start by writing down impediments, and set up regular meetings where you offer solutions to their problems.

If your team is not yet very experienced with recognizing impediments, you can lead them cautiously by asking direct questions and engaging them in discussions about why some work shows no progress. The more impediments you gather, even small ones, the easier your job will be in the next step. This list of impediments will become the golden key you need to---step by step---warm the team up to the idea of agile thinking.

Next, conduct interviews in the company to evaluate its current status in terms of agile maturity. There are many checklists available online; personally, I find the 50 points from Atlassian very helpful.

After this initial evaluation, categorize the gathered impediments according to the list. If needed, add additional categories for the remaining impediments that do not fit. For example, you might also want to evaluate the agile maturity of external suppliers which need to be integrated into your process.

Once this categorization is done, you can skip all points for which your team has not encountered any impediments. Without empirical evidence to support a certain change in your organization, there is no reason to “improve” the agile maturity in these other categories.

Obviously, the other points impede your team as well. But if there is nothing directly visible for the team, there is nothing you can do about it for now. Remember, you are implementing Scrum to solve actual problems of the team, not to create a PowerPoint presentation for management!

Not only will this give you an invaluable compass in the sea of possibilities of what you can change, but it will also provide you with empirical evidence to support any decision you are making.

We have established our current position by evaluating the status of the agile transformation in your company. We have also established a goal and have identified which of the points we should work on. Now, the real strength of the list comes into place: intermediary stages. Instead of just listing ideal situations, it shows the steps leading there. They represent small stories that can be worked on in individual sprints and thus can serve as a metric for your agile transformation process.

Summary The agile transformation is a complex project itself. The ideal approach to a complex project is agile and evolutionary. Analyzing the current situation and tracking progress with a good metric is key.

How do you navigate through the process of agile transformation? What metrics do you use to track progress? Let me know in the comments below!

Are Your Scrum Sprints Becoming a Backlog in Disguise?

Scrum is complex. We all have an “ideal world” in mind as we approach critical projects, but despite our best intentions, reality seldom follows. We can clearly see that some aspects of our Scrum implementation on our current project are not ideal, despite following all the ceremonies to the letter. It just does not work, and we cannot put a finger on a single cause.

Let us take a look at one common symptom of a malfunctioning Scrum process: a lack of motivation for planning meetings. Your team is smart, and recognizes meetings that are not very useful for them. If the problem is not your team, then what is it? This might sound far-fetched, but perhaps the issue can be found in your definition of a sprint.

What Is the Goal of a Sprint? 

This is one of my favorite questions to ask a client in the first interview, because it reveals so much about a client’s approach to Scrum as well as the relationship between the business and development teams. A common answer is, “The goal is to produce as many story points as possible.”

To me, this indicates that the company is looking for heroes who sacrifice themselves for the project. However, this method is hardly sustainable; it’s a very short-sighted approach to a project that might run for several years. Calling out for a hero means that the team will be inclined to add more stories to the sprint than they expect to finish. In the long-run, fewer sprints will be more successful.

Let’s back up one step and reframe the question:

What Is a Successful Sprint?

If the answer to this question is something along the lines of “Seventy-five percent of the stories are finished,” this means trouble. This approach is even worse than the aforementioned maximization of story points, because the team will stop questioning their approach when they hit that 75 percent mark. As a result, the team will stop learning.

But even if the answer is “One hundred percent,” and even if your team is very good at estimating story points, there is a problem. If you expect the team to hit their average number of story points half of the time (see Figure 1), they might feel pressured to be faster and work overtime (as opposed to producing more value for the customer—which is not necessarily the same thing), or take shortcuts on quality (testing and documentation).

An indicator for this problem is that stories finish late, often just before the end of the sprint.

Even if you safeguard the team, forbid overtime and keep quality standards, it’s likely that the team will miss their expected goal and you will end up with an unfinished sprint.

Figure 1: Bell curve showing the distribution of the time needed to finish all the stories of a sprint. Reducing the sprint size will significantly increase the probability of finishing a sprint within the sprint.

Now, what is so bad about the team just managing to get 50 percent of the sprints done successfully? That sounds like a good percentage, right?

A Slow but Deadly Poison

Unfinished sprints are a slow but deadly poison. They will hamper the planning meetings and ultimately the entire Scrum process in three ways:

With many failed sprints, the team loses their feeling of accomplishment. An unattainable goal is as good as no goal—ultimately, over-ambitious goals will make people ignore sprints and instead focus only on assigned tasks. You have added overhead for additional planning. Stories that are worked on over the course of many sprints become more expensive, as their business value remains unrealized and team members must remember again and again what they were about. They also slow down planning of new tasks and impede the focus of the team when selecting the next story to work on. There is constant pressure from the product owner. If the team decides which tasks to work on and in what order, "uncomfortable" (but maybe valuable) tasks might remain unfinished (there is always something "more important" coming up) and dragged along to future sprints. The product owner then must require team members to conduct work in a specific order, and the concept of a sprint again loses its meaning—becoming more like the backlog—and the team loses its sense of responsibility for the sprint. 100 Percent Workload Is a Traffic Jam

Ultimately, it is "management thinking," the idea that 100 percent workload of the team will maximize the business value of the project, that is the cause of sprints being abandoned in favor of the backlog. In that regard, a production process can be compared to a road. On a road, 100 percent workload is called a traffic jam. You can maximize the efficiency of a road only by using more efficient vehicles: more people per car instead more cars. In that regard, buses could be called the “sprints” of the road.

To profit from the advantages of Scrum, keep a buffer of 10 or 20 percent. If your sprint runs two weeks until Friday, plan sprints so that the team is finished on Thursday and free on Friday. From a management point of view, this idea has a scary outlook: your team has completed its work, now what? Do you send them home? Do you have them start another sprint? Do you add new stories to the completed sprint?

It is important to get away from the idea of 100 percent workload being optimal. That is local optimization for a global problem. When the team is done with the sprint, the team is done! Let the team decide what to do with the remaining time.

People are self-motivated, and they generally like to learn. Give them the opportunity to read books, attend conferences or seminars, research recent technologies or just take a break. Use the time for team building, improving the office atmosphere or generally cleaning up things that have piled up (there is always something!). Encourage them to discuss what projects or program parts could be scrapped.

But, most importantly, let it be the team's time. Set the completion of sprints as the goal and allow the team to celebrate their success.

If you are afraid that, with such a positive outlook, they will aim for less and less each sprint, re-examine your own views and ask yourself: “Why are they not motivated to work on the project?” Asking that question is much more productive than trying to coerce your team into working more, which usually just means having them spend more time in the office staring at their computer screen without any tangible increase in productivity.

Don't Just Ask Why

You might even want to try not just asking “Why?” once, but five times, just as Taiichi Ohno did at Toyota, until you find out the actual reasons for their lack of engagement. The team must lead the project; it is theirs. If you are uncomfortable with that idea, perhaps agile methods are not for you. But, if you want to tap into the power of agile, it is essential that the team feels responsible for the product.

Ultimately, like many elements of Scrum, this approach will reveal the actual problems you have in your company. In other words, existing non-agile business processes are seldom “accidents” that are just waiting to be replaced with Scrum. They are the result of a multitude of related problems which can, with Scrum, be named and discussed objectively.


The team lacks motivation for planning meetings.

Aim for 100 percent sprint completion instead of trying to maximize your story points per sprint. Have the courage to plan for fewer story points than what the team can manage on average. Use extra time to finish outstanding tasks, to refactor or to learn about new technologies.

Have you ever seen or experienced a sprint that was more like a backlog? Do you use other methods to make sprints more efficient? Let me know in the comments section below.

Scrum Does Not Need Heroes

We all know one: the person who rushed in to save the day or rescue the project. We know the people who work late into the night to finish the presentation or fix a problem with the website. Or, perhaps we have been the “heroes” ourselves. I myself was one for a while. At least, until I understood.

It’s easy enough to see how the opportunity arises for a hero to rush in and save the day. Judging from the expectations some of my clients have had, Scrum is (supposedly) about filling up a sprint with stories and then having the team literally sprint to the finish. For various reasons, when this does not work out and the project is in peril, they cry out for a hero to save the day. Who will answer the call?

A Culture of Hero Worship

In fiction, the hero has a lot to live up to. It is as if fiction writers with a conventional concept of a hero know that their heroes ultimately cannot keep up with the idealistic image that people project on them. They do not grow beyond their own sacrifice, leading to many stories ending with the heroic act itself or the death of the hero.

Think of Frodo from the book series “Lord of the Rings” by J. R. R. Tolkien. After his long and heroic journey to destroy evil once and for all, he does not return happily to his life. Instead, the story ends, with a vague reference of him sailing away to an unnamed country to spend the rest of his life there.

While this can make for intriguing cinema, should we not be allowed to question this cultural concept of a hero when it comes to real life?

In reality, the real work only begins after the “heroic act” has been performed. We must ask ourselves, “How did things go so wrong in the first place? How can we prevent a similar disaster in the future?”

Standing in the Way

Put yourself into the shoes of the lead developer. You are the one who knows the ins and outs of the entire system. If you are working on the issue, it gets done twice as quickly. You are that good.

You fear how the team would perform if you were not available or on vacation, so you tell them you are always available and that they should call you whenever there is a problem, no matter the time. Essentially, you think they are not ready for the world.

But, after a while, it slowly dawns you that your team cannot meet the challenges because you never actually let them try to do so. You are the reason they are standing still.

Men have to have heroes, but no man can ever be as big as the need, and so a legend grows around a grain of truth, like a pearl.

-Peter S. Beagle, “The Last Unicorn”

As a manager, you need to understand why it is crucial not to cry out for a hero. The heroic act does not change the person doing it, and the accolade of those around him or her will eventually end. After the situation has been resolved, the hero usually returns back to ordinary work---disenchanted, since he or she cannot keep working at the same pace on his or her own outside the team.

What these heroes are left with is either pride--which can turn on its head by causing them to become more defensive, less transparent and less of a part of the team--or a sense of abandonment, if they feel their contribution is no longer valued when it’s not urgent.

If you praise heroes by their sacrifice in the face of emergencies, you no longer differentiate tasks by their value, but by their praiseworthiness and visibility. Important but less visible half-finished tasks will be dragged along through several sprints until they cause a fire---with the hero again coming to the rescue, and the vicious cycle repeating itself.

Aim for 100% Completion, Not 100% Exhaustion Rather than demanding heroism and sacrifice by adding more stories to a sprint than the team has pulled from the backlog (or would have, if you had let them!), I recommend setting a goal of sustainability. This helps the team to become more confident in their abilities by removing the need for the “hero” of the team. It might even make the “hero” more productive by having her abilities focused not on putting out fires, but on his or her own strengths. Instead of looking at the hero as a self-sacrificial super-human, I recommend learning to get comfortable with the real hero as someone who can break conventions and who speaks openly instead of purposefully running the project into the ground just to prove a point.

There is no need, in a productive team, for one person to carry the weight of the world on his or her shoulders. We do not have to feel responsible for everything that is happening, only to then complain that we cannot manage it on our own. If the actual result is more important to us than social recognition, we have a simpler option to improve the world without having to sacrifice ourselves: We can focus on our strengths and help others in the team to reach their full potential.

Are Scrum Masters the True Heroes?

Even if you do not have a hero in your team, management might think you do, or that you should. Some clients even see Scrum Masters as a type of “team motivator” whose main task is to whoop the team into shape and reach new levels of productivity. If you do have a “hero” on your team, you might be better off either moving the person into a technical support role outside the Scrum team, or developing that person into a Scrum Master.

But, keep in mind that even the Scrum Master does not fit the image of a traditional hero. His or her main task is to oppose false heroes or paradigms within the company. Sure, the responsibilities of a Scrum Master also include identifying, analyzing and removing impediments, but that does not mean that the Scrum Master takes over tasks the rest of the team could just as easily work on themselves.


The traditional image of heroism does not fit into the Scrum team. A Scrum Master needs to be aware both of a culture of hero worship within a company and individual team members who are engaging in self-sacrificial behavior at the cost of long-term sustainability. 

The real heroes are the ones who break conventions and stand up against false heroes. They will be the ones who contribute to the success of your project and your team.

How do your team members share work among themselves? Do you have specialists, like a “super-programmer”? Have you seen evidence of hero worship in your company’s culture? Please let me know in the comments section below.