For many years, there has been a traditional method of project management based on the idea that the customer can know and define his or her requirements fully up front. While this is occasionally the case, very often customers either don't know precisely what they want or, more often, "will know it when they see it." As pictured to the left, the waterfall model defines a cascading series of phases from requirements through maintenance. (Although the names of the phases may be different, the idea is the same). Agile started to emerge in 2001 when software developers gathered near Salt Lake City, Utah looking for a better way. They created the Agile Manifesto which states its precepts as:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan1
It is this last precept that especially interests us here. Note, that while Agile clearly had its roots in software, it is believed to be applicable across any discipline. There are several variations on Agile, some of which include Lean, Kanban, Extreme Programming, and Crystal. In this article we will focus on one of the more popular methodologies, Scrum.
The word scrum - a method of restarting play - comes from rugby. Its usage here is based on a Harvard Business Review study that compared high-performing cross-functional teams to the formation used by rugby teams. So out of all this work there grew an organization known as the Scrum Alliance whose stated mission is to "encourage and support the widespread adoption and effective practice of Scrum2. "The very idea of Scrum is radically different from traditional or waterfall project management. While in waterfall it is assumed that the plan is all and change is difficult, in Scrum - or indeed in all of Agile - change is expected and is made visible.
On their web page, the Scrum Alliance briefly lists the Scrum framework thusly:
- A product owner creates a prioritized wish list called a product backlog
- During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces
- The team has a certain amount of time - a sprint (usually two to four weeks) - to complete the work, but it meets each day to assess its progress (daily Scrum)
- Along the way, the Scrum Master keeps the team focused on its goal
- At the end of the sprint, the work should be potentially shippable, ready to hand to a customer, put on a store shelf, or show to a stakeholder
- The sprint ends with a sprint review and retrospective
- As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.3
What's key here, and very much understated, is that the product owner can now change his mind about the product on an ongoing basis. The scope of these changes can vary widely, but they can be made more frequently and with less pain than in a waterfall environment. The belief is that at the end of a series of sprints, the product owner will be far more satisfied with the end product. In short, he will get exactly what he wants with no excess requirements.
Since the role of Scrum Master is so different from that of traditional project manager, some notes should be made here about what a Scrum Master does. In this role, he is less a manager of projects and more of a team facilitator and impediment remover. In fact, he has less control over the sprint and accedes to the will of the somewhat self-governing team.
Some of the impediments he deals with may seem mundane but are nevertheless important to resolve. For example, if the meeting room for the daily Scrum is unavailable, it is his job to find a new one. And since, as mentioned, the team is self-governing, he must make sure that it is not only sufficiently focused on its work but is also operating at a very high level. There is not a lot of room on a Scrum team for low-performing members. So there is some crossover with a traditional project manager, but it is not quite the same thing.
As to certifications, it is probably wise for project managers to do their homework on this topic and at least consider getting certified. There are several certifications available, two of which we'll note here.
The first certification is one that is provided by the Scrum Alliance. For this certification, you must first take a class from a Certified Scrum Trainer and then pass a 35-question virtual exam in which you must answer 24 questions correctly. This exam is nowhere near as difficult or intense as either the PMP® or ACP exams. As a result, one could say the PMI-ACP is a more respected and legitimate agile credential to possess. Its purpose is to demonstrate that the candidate has a sufficient level of knowledge to facilitate a Scrum. Other more rigorous certifications such as Certified Scrum Professional are also available. Testing for these is available at an organization similar to Prometric called Castle Worldwide.
Secondly, the Project Management Institute provides an Agile Certified Practitioner (PMI-ACP®) certificate. A cursory review of their Examination Content Outline reveals that the exam is a broad brush across Agile and not tied down to any one methodology. One key benefit to the PMI-ACP is it includes everything that would be covered in SCRUM. Like the PMP exam, the PMI-ACP is a test of one's knowledge and is administered only at Prometric centers.
Project Management Academy provides PMI-ACP training via an instructor-led course, available in 2 convenient formats: Recorded Online and Virtual eLearning. These courses satisfy the 21 contact hours required to take the PMI-ACP exam. They include training aids, online resources, and realistic sample questions as well as web-based video-on-demand access which allow you to learn at your own pace.
Regardless of which certification you choose - and you could very well get both - the well-armed project manager should have a good foundation in traditional plan-driven project management and change-driven Agile to compete in todays' marketplace.
3. Ibid ^