By: Laszlo Szalvay President, Danube Technologies

When an organization embarks on a Scrum transformation, it does so knowing that the implementation effort will be disruptive, challenging its employees to leave well-worn habits behind for a new set of practices and principles. Of course, they endure that disruption and uncertainty for the particular benefits Scrum enables. As discussed in Part One, Scrum’s iterative, incremental approach to development offers teams a period of stability to complete work, while also providing regular opportunities to evaluate the overall direction of the project. Moreover, Scrum’s emphasis on frequent communication and close collaboration leads teams to come together to create products that win the loyalty and confidence of customers.

But many organizations lose sight of the fact that Scrum enables these benefits when all of its few rules are observed. Too often, when companies begin to realize how far-reaching and radical the changes Scrum requires are, they start to cut corners, bend rules, and do whatever they can to minimize the shock and pain of implementing organization-wide change. What they don’t realize is that, while such measures may reduce short-term disruption, they also sabotage Scrum’s potential. Quite simply, Scrum has no optional or redundant rules and, it follows, only observing some of them dramatically reduces Scrum’s ability to affect positive change. In fact, when one aspect of the system is modified, it creates an unintended consequence within the framework, such as an erosion of values, a disruption of Scrum’s checks-and-balances system, and an obscuring of organizational dysfunction. To illustrate how this happens, I’d like to discuss a few common examples of how organizations alter the framework and detail the consequences these modifications yield.

Erosion of Values
In the Scrum framework, work is negotiated between the Product Owner and the development team at the beginning of each sprint. Once the team has committed to complete the assigned work, its workload is set and no new Product Backlog Items (PBIs) can be added until the next sprint. As such, the team is free to choose the order in which it will tackle the PBIs. In Scrum, this freedom for the team to determine how and when it completes its work is known as “self-organization.” From the standpoint of the team, self-organization is valuable because it prevents the Product Owner from micromanaging their work. Without interference from a micromanaging Product Owner, the team is left alone to create its own plan for how to accomplish its sprint goals. And when a team takes ownership over its work, its engagement with the work, motivation to excel, and morale tend to increase. While granting the team so much autonomy might make traditional project managers nervous, relinquishing control to the team benefits Product Owners as well. No longer bound to micromanage the team’s every activity, the Product Owner can begin to focus on big picture issues, such as managing customers, listening to customer requirements, release planning, analyzing market competition, and grooming the Product Backlog.

But what happens, for example, when a Product Owner ignores Scrum’s mandate for self-organizing teams? To be succinct, the result is that all of the above benefits are undone. When a Product Owner micromanages the team and raids their sprint (i.e. continues to add work during the sprint), he or she undermines the team’s ability to think for itself and dictate its own course for achieving sprint goals. Not only does it prevent the Product Owner from investing attention in broad strategic planning, but it also teaches the team to merely take orders, rather than proactively lead itself toward actionable solutions. In short, when the Product Owner denies the team its autonomy, he or she reduces a team of creative collaborators to automatons.

Disruption of Checks and Balances
As discussed in Part One, the Scrum framework is divided into three roles: The Product Owner, the ScrumMaster, and the development team. Because each role entails specific responsibilities, modifying the roles can create redundancies or, worse, impediments that prohibit a team from realizing its potential. For example, Scrum specifically states that a Product Owner is not a part of the development team. Based on the nature of the Product Owner role and its authority within the framework, it makes sense that this role would be excluded from the team. After all, when there’s a clear leader to defer to, the team is much less inclined to organize itself; they’ll just take orders. Moreover, in Scrum, this division of roles and responsibilities is akin to a separation of church and state, in which the party that decides what is to be done (the Product Owner) cannot also dictate how to do it or how long it “should” take.

With that mind, consider the effects of a Product Owner acting as part of the team during the estimation process, when a team approximates the relative difficulty of its stories in the Product Backlog. Normally, this process takes place between the team and the ScrumMaster to ensure that teams estimate honestly. When a Product Owner participates in this process, it’s likely that team members will feel pressure to downplay the effort required to complete particular stories so that more work can be added to the sprint. When this occurs, not only is the team not self-organizing, but it’s actually misrepresenting its abilities: More often than not, when the team agrees to more work than it can handle, it leads to an overall slide in quality.

Here’s another scenario: What happens when a Product Owner attends the team’s daily standup? Typically, his or her presence would undermine the leadership and accountability that arises naturally when a team self-organizes. Rather than report to one another in an environment where they can safely discuss progress and impediments with candor, the team simply reports to the Product Owner. It’s a situation which breeds competitiveness among team members, not a shared commitment to excellence.

Obscuring Organizational Dysfunction
One of the most valuable aspects of the Scrum framework is its ability to surface dysfunction within an organization. But when the framework is modified, it not only prevents Scrum from exposing those problems, but actually ensures they stay hidden. Given that Scrum is designed to facilitate communication and collaboration, tweaking its processes breaks that chain of communication.

For example, consider a team that historically under-commits at the sprint planning meeting. By inflating its estimates, the team takes on much less work than it can accomplish within the sprint. However, because the team has always exaggerated the effort of its work (often called “sandbagging”), it appears to be operating at its established velocity. As a consequence, the Product Owner never knows the true potential of the team and, though he or she assumes the team is giving its best effort, only receives a fraction of the work the team could produce. Not only does this abuse the trust between team and Product Owner, but it also postpones release dates and wastes money.

Here’s another scenario. Scrum asks that each team have its own dedicated Product Owner. The rationale for this is simple: Because the Product Owner interfaces with the client and truly understands the product it needs, he or she relays that direction to the team. When a Product Owner is split between multiple teams, disengaged and inaccessible, or simply not translating what the customer wants, teams are left to make their best guesses. And, unless they’ve learned how to read their Product Owner’s mind, that scenario usually results in the team building the product they believed the customer wanted—which may have little or nothing at all to do with what the customer actually requested. Here, the customer does not receive the product it expected to be delivered and the team must begin again—hopefully, with the assistance of a committed Product Owner.

Conclusion
As you can see, a modification of the Scrum framework leads to an unintended consequence in another area of the framework. However, that doesn’t necessarily mean that the Scrum framework can never be tailored to fit a particular team or organization. On the contrary, it can, but only by an experienced Scrum practitioner with a deep understanding of Scrum’s processes and the benefits they enable. Once an individual develops a mastery of Scrum, he or she can make changes to the framework that remain consistent with Scrum’s values and do not create the kind of impediments described above. In Part Three, I’ll discuss how and why Scrum experts can tweak the system—without breaking it in the process.

Next up: The Scrum Framework Part Three: All Parts Included

About Laszlo Szalvay
In August 2000, Laszlo Szalvay, along with his brother Victor, co- founded Danube Technologies, Inc. in Seattle. Although Danube originally was created to manage outsourced software projects, the company’s focus soon shifted to helping organizations transform to Scrum software development management practices. Danube first developed an internal tool to improve its own processes and then offered it for free to the market. It became such a success with clients that, two years later, Danube developed and introduced its flagship product, ScrumWorks® Pro. In 2005, Danube extended its offering by developing a new services division, ScrumCORE™, which provides Scrum coaching to clients through public and private courses as well as onsite engagements.

Currently, Szalvay serves as president of Danube Technologies, Inc. In this role, he helps develop and define the company’s vision and creates initiatives that influence every aspect of the organization. In 2004, the Small Business Administration recognized his leadership by naming him the Young Entrepreneur of the Year.

Related Links
Get a broad introduction to Agile methodologies in this paper by Kent McDonald. If you aren't sure Agile is a good fit for your projects, we have a checklist you can use to dip your toes in on a single project. What makes a project "agile"? Alan Koch has some thoughts.