Emerging Tech

Get an overview of the Scrum agile project approach

Scrum is a structured agile methodology that is gaining a lot of traction. Rick Freedman discusses Scrum's fundamental concepts and key roles.

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.

ScrumMaster

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!

About

Rick Freedman is the author of three books on IT consulting, including "The IT Consultant." Rick is an independent consultant and trainer, working, through his company Consulting Strategies Inc., to help agile teams and organizations understand agile...

13 comments
Victor_Simson
Victor_Simson

Scrum Master certification is a hot cake these days since 80% of IT companies are using Scrum. Moreover, Scrum Master certification training help you to improve your project management skills. But keep in mind that you need to choose the right training. Below mentioned link has an analysis of various training providers. http://www.scrum-master.info/SCRUM-AGILE-Providers.asp

pferg
pferg

This sounds like the "old" term of prototyping. What is different?

D2KK
D2KK

Where/how does the QA team fit into the scrum model?

george.walker
george.walker

I read the definition of a ScrumMaster and that is basically my expectations of a good project manager. You lead the team, you work with your client and you coach. What am I missing??? Yes there is the Agile methodology but the key is leading the team to be sucessful.

rohini.kumar
rohini.kumar

Agreed; as the author mentions Agile is most suitable for exploratory projects. I however take issue with referring to SDLC project managers as "bureaucracy"- there are advantages/disadvantages to each method and the key is knowing which method to apply for which projects.

abhijeetshinde84
abhijeetshinde84

D2KK, The QA is part of the development team as the 'Team' in Scrum is a cross-functional group of people working together...

RickFreedman
RickFreedman

I agree that there's a lot of similarity between a good project manager and a scrummaster - the key word being "good". I've met many PMs who struggle with the ability to discern which elements of process are essential to delivery, and which are done whether they add value to this particular project or not because they're part of some prescribed SDLC. I also think the facilitation, coaching, and scrum leadership skills required are unique and rare. It may seem a small distinction, but the team leads itself - the scrummaster enables that self-direction.

RickFreedman
RickFreedman

Quality management in an agile project is baked in from the beginning - as features or stories are developed the confirmation of those stories is also captured in initial conversations with the client. As the project progresses quality issues are raised in daily stand-ups, and deliverables are constantly reviewed and refined in review meetings and retrospectives. Most agile methods enforce quality in deliverables through concepts like refactoring and pair programming, and by exposing interim deliverables to the client for review. Obviously technical QA requires different skills than simple customer approval, and so most agile teams I've worked with include a formal QA role, but the key idea is that testing and QA is not an after-the-fact add-on - it's an integral element of the development effort.

D2KK
D2KK

This is helpful. Thank you!

RickFreedman
RickFreedman

I'm not sure what the "official" agile or Scrum response to this would be, but my experience is that most organizations that do SW development have a separate QA function, and when my team works with those orgs we don't try to upend the existing org but focus on integrating the QA folks into our daily meetings, work sessions, client interactions etc. The biggest problem I've observed is the tendency in "traditional" PM cultures to view QA as a separate, after the fact activity, such as a "testing " block at the end of a waterfall approach. If you think about the "card, conversation, confirmation" idea I outlined in a previous column it becomes clear that QA is integrated into every development activity and nothing moves down the development line without significant testing...remember that we're aiming for a working, releasable product as early as possible so testing must happen, and must be robust, from the get-go.

D2KK
D2KK

Thanks for your reply. Agreed that quality management should happen throughout the project. My question specifically is, if there is a QA team (say Alpha testers) with a different reporting structure than the development team (system testers), how would that fit into an agile approach? Or what is the correct structure, should there be a seperate QA department?