Busting Five Scrum Myths

Organizations adopt an agile approach for many reasons. Some hope for greater productivity and a reduced time-to-market. Others for more successful products. Still others adopt Scrum to increase collaboration between developers and businesspeople, to improve quality, or to increase team member job satisfaction.
 
And, of course, many organizations adopt Scrum in the hope of achieving some combination of these benefits.
 
But, for as many benefits as there can be to Scrum, there seem to be just as many fallacies. In this article, I’d like to bust five myths about Scrum.

 
Myth #1: Is It True That Managers Have No Role in Scrum?

I think this myth persists because too many managers spend a lot of time doing things they shouldn’t be doing, regardless of being agile or not.
 
For example, managers often work down at the level of assigning tasks to individuals. When they learn this isn’t something they should do in Scrum, they feel like part of their job has been taken away.
 
No - part of the job has not been taken away. Things like assigning tasks should never have been part of the job in the first place.
 
Managers should be focused on creating the environment and culture a team needs to thrive. Their time should not be consumed with minutiae like who will work on which task.
 
Peter Drucker was one of the leading management theorists of the 20th century. He is perhaps best known for the idea of management by objectives and creating the acronym SMART for goal setting in which goals are Specific, Measurable, Acceptable, Realistic and Time-bound. Drucker said managers have five jobs:

• Set objectives
• Organize people and work
• Motivate and communicate
• Measure
• Develop people

Sure, in some organizations, some of these responsibilities may be diminished. But others--such as developing people--become more important.

In all the years I’ve worked with Scrum and agile organizations, not one has decided to fire all managers. Yes, some managers have moved into the more focused roles of ScrumMaster or product owner, but there is still a role for management in Scrum.

 
Myth #2: Can’t Stakeholders Introduce Change Whenever They Want?

Not surprisingly, the myth that stakeholders can introduce change any time they want is most commonly believed by stakeholders themselves.
 
Development team members understand that introducing change at the wrong time comes with a cost.
 
Consider ordering a meal at a restaurant. You tell the waiter you’d like the chicken. Then instantly say, “No, make that the salmon instead.”
 
There is no cost to this change.
 
There is, however, a cost if you change your mind later. If you tell the waiter to change your meal from chicken to salmon after the kitchen has begun cooking the chicken, there is the cost of wasted food (which the restaurant may well charge you for).
 
The cost is more obvious if you eat half of the chicken before telling the waiter you’d like to switch to the salmon.
 
A stakeholder introducing change into an iteration is like the diner changing from chicken to salmon. If the change is introduced at the right time, there may be little or no cost. Introduced at the wrong time, though, and there is a cost.
 
Being agile cannot eliminate all costs of stakeholders introducing change. However, good Scrum teams can reduce the cost of change regardless of when the change is introduced. Common ways of doing this are:

• Short iterations
• Small product backlog items
• Finishing each product backlog item as quickly as possible, usually by minimizing the number of items being worked on concurrently

None of this is to say that teams shouldn’t welcome appropriate changes. Some stakeholder-requested changes can be very important. But, the benefit of making each change needs to be assessed against the cost of changing and that cost is not always zero.

 
Myth #3: Doesn’t Everyone Need to Be a Generalist on a Scrum Team?

For some reason, a popular myth about Scrum is that every team member needs to be able to do everything.
 
This myth implies that if you have hired the world’s greatest Oracle database administrator that you want that DBA to also be an amazing JavaScript developer. And your amazing JavaScripter should be fully proficient at security testing in case there isn’t much JavaScript needed one iteration.
 
This is entirely false.
 
Scrum teams don’t need everyone to have every skill. Instead, what Scrum teams need is to value any individuals who do possess skills in multiple disciplines.
 
To understand the falseness of this myth, consider a well-run fancy restaurant. From watching too many TV cooking shows, I’ve learned such a restaurant may have a pastry chef. The pastry chef is skilled in making pastries, desserts, bread and other baked goods.
 
This sounds like a highly skilled but specialized role. Another specialized role in the kitchen could be the saucier, who prepares sauces, stews, and other similar items.

In a well-run kitchen, it would be nice if the pastry chef could help the saucier, perhaps by slicing some onions during a sudden onion shortage emergency. But neither the pastry chef nor the saucier would be expected to be fully capable of doing the job of the other.
 
In today’s world of complex technologies, it is unrealistic to expect team members to be fully proficient in all the skills of the team. Instead, good Scrum teams learn to value multi-skilled team members.
 
Having a few team members with multiple skills helps manage the balance of types of work. That is, sometimes the team needs more testing capacity. Having a team member or two who can shift into doing helps incredibly.
 
But this can be accomplished on most teams even if a few team members are truly specialists and adept at only one discipline.

Myth #4: I’ve Heard that Scrum Teams Don’t (or Can’t) Plan.

Most good Scrum teams do plan. But that planning is often less visible than on traditional projects because Scrum teams don’t have an upfront planning phase.
 
Instead, good Scrum teams conduct planning as a series of smaller, recurring activities that ensure their plans always reflect the realities of the current situation.
 
In this way, teams develop plans the same way they develop products: by inspecting and adapting.
 
For any Scrum team, its plan should project no further into the future than absolutely necessary for making important decisions. But most organizations and teams have a plan to approximate at some level what is coming next and when it’s coming.
 
In fact, despite this myth, Scrum teams have an easier time creating reliable plans because Scrum teams get earlier insight into how quickly they are producing software.

Consider a traditional team with analysis, design, coding and testing phases. If lucky, that team may delay committing to a plan until the end of the design phase. But at that point, this team has no idea how fast they are at coding and testing--they haven’t done any of those activities yet.
 
In contrast, a Scrum team turns the crank of the entire development process every iteration. Each iteration includes a little analysis, design, coding, and testing. This gives the Scrum team more and earlier insight into how quickly it can turn ideas into new features.

Myth #5: Don’t Scrum Teams Create Products with No Architectural Plan?

It’s time to bust our final myth: the myth that Scrum teams don’t architect or design their products.
 
Scrum teams definitely design their products. But, in the same way they plan incrementally, Scrum teams architect and design incrementally. This allows them to inspect and adapt their architectures and designs so they become the best possible.
 
This means there is no upfront phase during which all architectural decisions are made. Instead, the architecture of a product emerges over time.
 
This occurs by technical team members focusing first on any aspects of a product they consider risky. For example, if delivering a product with the needed throughput will be challenging, the team and product owner would elect to work on functionality early on that reduces that risk.
 
In this way, the emergent architecture of a Scrum product is also intentional. The architecture doesn’t just show up one day. It emerges gradually and guided by the intent of the technical team members.
 
This means that products built using Scrum do possess an underlying architecture. But decisions about that architecture are made as needed through the course of the project rather than being made entirely upfront at the start of the project.

 
You’ll Encounter More Myths Than These

As you work to introduce or optimize Scrum in your organization, you’ll undoubtedly encounter other myths or mistaken beliefs people have about Scrum. Hopefully the myths I’ve busted here give you a head start in overcoming myths about Scrum in your organization.
 
 

Mike Cohn is a co-founder of the Scrum Alliance and is the author of three popular books on agile and Scrum. He can be reached through www.mountaingoatsoftware.com.