For those of my PMP friends and colleagues who are firmly immersed in the waterfall way of doing things but who are hearing more and more about agile and scrum and wondering what all the fuss is about, I thought it might be a good idea to write a series of articles comparing and contrasting the two approaches. I’d like to start by stating that I am very much a fan of agile and scrum and believe that the traditional PMI methodology, when practiced in a sensible manner and the agile scrum approach have more in common than you would think. At the end of the day the purpose of both is the same – to get work done well. Smart practices are smart practices regardless of what you call them.
I first became interested in agile when I was leading technology teams and consistently struggled with the standard waterfall challenge of getting accurate, complete, well understand and well documented business requirements for long software development application projects. Once we felt like we finally got things “nailed down” and began design and development work, requirements would change before we could deliver the first release. The agile methodology is a natural solution for this. I began my own course of self study, networking and training, and eventually acquired a scrum master certification.
To understand the principles of any of the flavors of agile methodology (and there are several), you need to first understand the agile manifesto, developed by the original set of agile founders:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Scrum happens to be one of the most popular types of agile and derives its name from a daily standup meeting called the scrum meeting, involving the team and the facilitator who is called the scrum master. Below is a discussion which breaks down some of the important roles used in scrum and compares them to their analogous counterpart in a waterfall methodology.
Roles – there are only 3 officially recognized roles on an agile scrum team:
· Product Owner – The product owner is a member of the scrum team and is responsible for what the team builds and for optimizing the value of it. He/she owns decisions and risks regarding what business stakeholders want. He/she defines the features to be produced and decides on release date and content, and determines feature priorities. He/she can change features and priority between sprints. He/she negotiates acceptance criteria for work results with rest of team
· Scrum Master – facilitates process and keeps things moving. He/she manages the internal dynamics of the team including the relationship of the product owner with the rest of the team. He/she enforces the scrum framework. He/she ensures full team involvement in all meetings and keeps everything visible, including “radiating” information to the larger organization. He/she shields the team from external interference. He/she advocates improved practices. Very important: He/she facilitates, but does not manage. The scrum master has no official authority over the team. He/she cannot assign work to the team.
· Team – This is a small (7 +-2 member) cross functional group who are responsible for the work they agree to take on during the work period called a sprint. They are a self organizing unit – meaning they assign sprint work tasks to themselves. They negotiate the work of the sprint with the product owner. Along with the product owner, they demo the work results to the stakeholders.
The product owner is analogous to a business analyst, product manager or sponsor in a waterfall methodology, and the team is similar to any team anywhere, with the exception of the self organizing part. That’s a little loose-y goose-y for a lot of management teams to get used to. Frankly, what I’ve seen in a lot of companies I’ve networked with is a gradual approach to this, because as much as this sounds like a great goal, in companies that have been highly command and control, teams have to get as used to it as the managers themselves do. The scrum master could be similar to a technical team lead or a technical project manager in some organizations. What is strikingly missing in this model is the overall project manager him/herself. The traditional, all controlling, project manager doesn’t really have a direct correlation. To find a home in an agile practicing organization the PMI style project manager has to make some decisions. For individuals with a more product oriented, business slant, the product owner might be a great role to assume. For the more technically minded, the scrum master role might be a better fit.
One of the most intriguing differences between agile and waterfall and what in my mind makes agile so compelling is in the area of scope control. In the waterfall methodology we go to great lengths to define the scope of the project in as much detail as we can all up front, and then protect that scope. We define a rigid scope change process which acts as a deterrent to anyone who wants to introduce changes to the work that we already have a complex tangle of design plans around, because of the cost and pain of implementation when you work on everything all at once. With agile the notion of scope control is virtually non-existent, except within the context of the short periods of work, called sprints. This is by design. This is to allow and even encourage the product owner to be flexible and change their mind in between sprints as the business sees the results of work and reacts to it; and as events in the business change.
In a nutshell, product features and all other work are maintained in a document called the product backlog, in single threaded priority by the product owner. The team determines “chunks” of that work off the top that they can perform in time boxed periods of work called sprints (usually 30 days). Once a sprint starts, the scrum master insures that the scope of the sprint does not change. At the end of the sprint the team and the product owner jointly demo the work that has been completed to the business stakeholders. The product backlog is reprioritized if necessary by the product owner and another sprint is started. Sprints are repeated until enough work is completed to comprise a release. Sounds simple huh? Well there’s a little more to it than that.
In my next article I will discuss the small set of artifacts, meetings and processes involved and discuss what they compare to in a waterfall context.
See more tips on Improving Project Management Problem Solving Skills at The Project Coach Blog: