In previous columns, I discussed various concepts regarding the application of agile project management methodologies, from estimating to the discovery of requirements. I’ve mentioned some of the variants of agile methods, such as Extreme Programming and Adaptive development, but I have yet to explore the specifics of any of the agile approaches. So let’s take a more focused look at the agile variant that is gaining a lot of traction: Scrum.

Fundamentals of Scrum

Scrum is an example of a structured agile methodology that, by applying a few simple “rules of the road,” enables teams and their clients to develop complex, innovative products by entrusting them to use their talents and intelligence to devise their own direction.

Like all the agile approaches to software development and project management, Scrum builds on a few fundamental concepts. The concepts are:

  • In experimental or exploratory projects, predictive methods are less likely to be effective than incremental, iterative approaches that present the client with progressive deliverables and then make adjustments and course corrections as the work proceeds.
  • Teams of self-motivated, skilled practitioners are more likely to succeed and to feel rewarded and productive in self-directed teams in which individuals take ownership of specific deliverables and then devise their own methods of achieving them.
  • Constant and close collaboration with the client and sponsors of a development effort is more likely to succeed than projects in which the client participates in a front-loaded requirements process and then disengages until the end product is delivered.

Mary Poppendieck, in her introduction to Ken Schwaber’s book Agile Project Management with Scrum, makes a very apt analogy. She compares traveling by airplane with traveling by car. Air travel, while convenient and appropriate for certain types of trips, such as those in which the origin and destination are well-known and unchanging, prescribes every element of the trip with detailed checklists and procedures and requires a central control agency to direct every decision and procedure. Traveling by car, in contrast, allows the traveler, by following a few simple, well-understood rules, to determine the route as she goes, to make adjustments and decisions on the fly, and to explore byways and detours that may add significant value to the trip and the outcome.

The point of the analogy is that, while predictive and rigidly controlled processes are totally appropriate for trips in which the path is well-known, few new discoveries are expected, and predictable outcomes are essential. For those trips in which discovery and exploration are the goal, independent actions by operators making decisions as they go and applying a few simple “rules of the road” are more likely to deliver satisfying results. “Some might try valiantly to make control systems work by applying more rigor,” Poppendieck notes, “…but the people who prevail are those who figure out how to change to a system of independent agents operating under an appropriate set of rules.”

In action, Scrum is based on a few simple rules, roles, and artifacts. Through the independent, self-directed application of these rules, roles, and tools, talented teams try out their ideas, present them to the sponsor for comment and validation, and, based on the new information generated by that interaction, refine their course until they deliver what the customer wants. This data-driven approach to product development is the foundational idea of Scrum and of all agile methods.

Three key roles in Scrum

The number three plays a central role in Scrum. There are three key roles in a Scrum effort, three key activities or “ceremonies” that participants perform, and three central artifacts or tools that Scrum teams use to organize and track their work. Let’s take a look at the roles first.

The three central roles in a Scrum effort are: the ScrumMaster, the product owner, and the development team.


The ScrumMaster plays the role that a project manager would take in a traditional project, but the responsibilities and approach are quite different. Rather than behaving as a project foreman, supervising the daily tasks of each contributor, or as a project bureaucrat, recording progress in project plan and Gantt chart, the ScrumMaster is a facilitator, collaborating with the product owner to define the project goals and to enable the Scrum team to work toward those goals in the most productive way. The ScrumMaster spends his time as a facilitator, a coach, and a collaborator, sheltering the team from barriers, interference, and external politics and leading them through the Scrum practices and activities toward the successful delivery of the best result.

Like the project manager in a traditional environment, the ScrumMaster must know the status of all the features that the team has uncovered in the requirements or story exercise and must maintain the Burndown chart to reflect the current state of development. The ScrumMaster also must focus on any political, cultural, or personal impediments that might derail or delay the effort. Whether the issue is a client participant who isn’t available as promised for collaboration or a team member whose skills are not as expected, the resolution of problems, conflicts, and barriers is a key element of the ScrumMaster’s role.

Product owner

The second role is that of the product owner, who is responsible for defining the product’s features and functions, for collaborating with the ScrumMaster and the development team to review each iteration and determine the product’s suitability, and for working with the team to adjust, modify, and reprioritize the feature set based on business needs, market conditions, ROI expectations, and technical hurdles that arise. Scrum teams take the idea of “ownership” seriously; the designated product owner is the ultimate authority in deciding if the work results, either interim or final, are acceptable.

Development team

The development team organizes itself and the required effort to deliver the results and collaborates both internally and with the product owner and his colleagues to determine the feature set, to segment it into sprints, and to perform the actual development of the work product. Most importantly, the team decides for itself how to perform the work and deliver the results. Unlike a traditional project, the work is not parsed out into granular tasks for the team; the team and its members determine for themselves who will take responsibility for each feature or story and how they’ll tackle the development activities.

Stay tuned

Next time, we’ll look at the “ceremonies” and the artifacts that Scrum teams apply.

Get weekly PM tips in your inbox
TechRepublic’s IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!