Project Practitioners > The Scrum Framework Part Three: All Parts Included

The Scrum Framework Part Three: All Parts Included

By Guest Contributor

By: Laszlo Szalvay President, Danube Technologies

As discussed in part one, the past decade has seen agile software development—and Scrum, its most popular subset—reshape how businesses manage projects. Because Scrum asks teams to organize work into consistent and repeatable cadences, known as sprints, its approach to development is iterative and incremental. That is, unlike waterfall development, in which a project is completed in a linear, sequential manner, Scrum allows teams to work in ‘chunks.’ That’s a simplistic take on how Scrum departs from traditional waterfall, but the key difference of an organization’s ability to respond quickly to conditions as they arise is what constitutes agility. From a business standpoint, this is very valuable. When a company can react quickly to a customer’s sudden feature request or a rival product that goes to market first, it is designed for survival. Given the current global economic crisis has many executives wondering how to ensure their businesses’ longevity, Scrum’s competitive edge is a very attractive path to developing the products customers want, while enduring the recession in the process.

However, as discussed in part two, Scrum’s benefits—from reduced cycle time and lowered development costs—are compromised when its few rules are modified or only partially observed. Put another way, the Scrum framework is like a very basic machine: Each part exists for a very specific purpose and enables the other parts to function properly. When a piece of the machinery is removed, the entire framework breaks down and quits working. Thus, it is critical the organizations uphold Scrum’s principles and processes—or else they risk sacrificing the business value Scrum can generate.

Perhaps you’re thinking it’s a lot to ask organizations to follow Scrum’s tenets so rigorously. After all, enterprise-sized companies often contain rigidly defined departmental structures and organizational requisites that make practicing pure, by-the-book Scrum a considerable challenge.  My first response would be Scrum is often called a “management wrapper”—a flexible set of roles, artifacts, and processes that can be draped over existing infrastructure. However, there are some instances when tailoring Scrum to the specific needs of an organization is unavoidable. But only individuals with a deep understanding of the framework’s components—and what they enable—should attempt to customize Scrum.

Jeff Sutherland, one of Scrum’s inventors and a signatory of the Agile Manifesto, has likened agile to martial arts. That is, just as Scrum is a subset of agile, many disciplines are included under the umbrella of martial arts, from karate and taekwondo to jiu-jitsu and judo. Similarly, one must first become a master of those disciplines before synthesizing their moves and creating a new, signature style. The same can be said of Scrum practitioners: Only those who possess a mastery over Scrum should even consider altering the framework. In part two, I discussed how making uninformed adjustments to the framework essentially undoes its potential—by eroding values, disrupting checks and balances, and obscuring organizational dysfunction.

So what does it look like when an organization modifies the framework in a way that preserves Scrum’s benefits? My company, Danube, works with organizations to help them transition to Scrum, so we see companies alter the framework every day. Most teams recognize early that to truly apply by-the-book Scrum would force them to confront organizational dysfunction and, in general, retrain themselves to follow a new set of working behaviors. Most often, that point is a fork in the road. Some teams focus on the big picture and cling to Scrum’s practices, trusting that whatever discomfort it causes in the short-term will be justified by where it will lead them. Others nip discomfort in the bud, immediately modifying the framework to eliminate whatever challenge Scrum surfaces. What such teams don’t realize is, in that moment, they’ve unwittingly eliminated Scrum’s potential for improved processes, project transparency, and heightened productivity. Perhaps it goes without saying: Those teams who practice Scrum without compromising its core values stand to maximize its benefits.

One company we’ve seen navigate a Scrum transformation better than most is Intel. In 2006, its Oregon and Pacific (OAP) Product Development Engineering (PDE) team—a group of approximately 50 developers—decided to implement by-the-book Scrum to assess how it would work at Intel. Given the company’s long history of manufacturing and fabrication at the company (i.e. an assembly line approach analogous to waterfall development), it could be assumed that iterative, incremental development would require a considerable shift in the developers’ thinking. After three months of “pure” Scrum, the OAP PDE, led by principal engineer Pat Elwer, determined some adjustments needed to be made to accommodate certain organizational requirements.

One way Intel modified the framework was to expand Scrum’s roles beyond simply the Product Owner, the ScrumMaster, and the team. While all three of those roles were still used, additional roles with more narrowly defined responsibilities emerged as well. For instance, in addition to the usual Product Owner role, tasked with managing a single functional group, Intel also created a number of specific “ownership” roles to ensure leadership at every level of the organization: Business Owners, Technical Owners, and Story Owners. Here’s how their responsibilities broke down:

  • Business Owners: Senior managers or principal engineers charged with oversight of multiple teams or overarching technical issues for all teams. Business Owners manage release planning and define the desired features for each roadmap milestone.
  • Technical Owners: Technical leads from each of the functional areas who could collaborate on integration, dependency, and architectural issues to ensure congruence between teams and dependent outputs. Technical Owners held ad hoc meetings to break down epics into sprint-able stories.
  • Story Owners: Technical experts with particular knowledge of how to complete a story who can develop tasks and request the participation of certain team members in completing those tasks. The Story Owner is the one person who you could go to and ask, “What’s the status of this story?” and receive the right answer, every time.

Although Intel’s addition of three ownership roles does indeed modify the Scrum framework, what’s important to observe is how these roles do not subvert Scrum’s core principles. In essence, Intel scaled the Product Owner role to provide dedicated leadership at various organizational levels, just as one might create a Scrum-of-Scrums architecture. Elwer points out, though, these Owners still led teams in a manner consistent with Scrum’s values. “Scrum teams still owned sizing and committing to meet the feature milestones based on their velocity,” he said. Even though the scope of the Owners’ oversight grew and these individuals’ titles were changed, their behaviors still aligned with Scrum’s mandate to let teams self-organize.

Similarly, Intel also created a role called “transients.” These individuals possessed highly specialized and in-demand skill sets required by multiple teams for only a sprint or two at a time. Once teams no longer required input from transients, those individuals migrated to the next team at the sprint boundary. Again, Intel created a role not included in the Scrum framework, but did so in a manner that does not undermine its division of labor and authority. In essence, a transient is just a team member with such a critical and unique technical skill set that he or she must be shared among all teams. The transient was not awarded any elevated authority within the team. The transient worked with the team for the duration of the sprint and, once the need for his or her skills no longer exists, he or she simply migrated to the next team. Apart from the name and nomadic nature of the role, there is no real difference between a transient and any other team member—he or she simply floats from team to team, as needed, to add another layer of cross-functionality.

While Intel’s elaboration of the Scrum framework was a success, I’d warn companies from thinking that such moves are easily made. The key to Intel’s success was starting with a solid foundation of Scrum knowledge. When you understand what components make up the framework and the philosophical rationales that make them necessary, customization can occur in a way that does not sacrifice Scrum’s potential. And when an organization can leverage Scrum to address the unique challenges it faces, it’s well on its way to becoming a master in the art of Scrum.

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
Whether or not you call them transients, team members who float between projects may lose time to inefficient ramp-ups. Steve Trautman shared his recommendations for getting new team members up to speed quickly via peer mentoring. (Our interview with him has some other valuable insights.) Get an overview of the Scrum framework in Laszlo's previous articles, here and here.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

I am concerned that Scrum, like most project management methodologies, simply develops a new set of buzz words, meaningless definitions and templates etc., and does not address the primary reasons of why projects are late, over budget and under quality.

I built a team of 22 project managers and 12 IT network designers and, at the start the majority suffered from the common problems of:

a. they wanted to jump in and do not want to start at the start, and that is a clear definition of the customer requirements,

b. very few knew how to build an effective Work Breakdown Structure to describe their project, or how to map the customer requirements to the project.

c. very few knew how to build and maintain a schedule in MS Project (or any other tool) and preferred to use "cunning spreadsheets".

d. all had great difficulty in updating actuals in their schedules so that management could track actual progress - good or bad. The majority stated that it created a big brother atmosphere.

d. most suffered from lack of attention to detail in their project management tasks,

e. there was no feeling of pride in the group,

f. there was little respect for the customer.

I started an improvement program three years ago, and whilst all of the PMs are now Prince2 trained and have a Diploma of PM (customer requirement) the main benefits have come from group meetings and 'lunch and learns' on the basics of PM, such as the customer is king, pay attention to detail, how to build effective WBSs, each PM presenting lessons learned from their last project.

Building a team,with good team ethics, treat each person with respect and paying attention to detail will beat a good scrum anytime.

We are still growing, winning excellent reviews from our customers and we have a great work ethic and environment.

Although, I guess it will not make as much money as selling the scrum concept.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.