An Introduction to Agile Project Management

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" project management 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 as a framework in 2001 when software developers gathered near Salt Lake City, Utah looking for a better way. They created the Agile Manifesto which states its values as:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan¹

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 or organizational function. There are several variations on Agile, some of which include Lean, Kanban, Extreme Programming (XP), and Scaled Agile (SAFe). 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 Scrum². "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.

At a high-level, the Scrum Alliance outlines the Scrum framework as:

• 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 (during a 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.³

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 friction than in a waterfall environment. The belief is that at the end of a series of sprints, the product owner (and presumably the end-user or customer) 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 or she is less a manager of projects and more of a team facilitator and impediment remover. In fact, the Scrum Master has less control over the sprint and accedes to the will of the somewhat self-governing team.

Some of the impediments the Scrum Master deals with may seem mundane but are nevertheless important to resolve to further the progress of the team. For example, if the meeting room for the daily Scrum is unavailable, it is his or her job to find a new one. And since, as mentioned, the team is self-governing, the Scrum Master must make sure that the team 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 to enhance their credibility in an Agile team environment. There are several certifications available, three of which we'll note here.

The first certification to support your understanding of the Scrum Master role is one that is provided by the Scrum Alliance and does not require any pre-requisite work experience: The Scrum Alliance’s Certified Scrum Master (CSM) certification. For this certification, you must first take a class from a Certified Scrum Trainer (CST) and then pass a 50-question virtual exam in which you must answer 37 questions correctly within a 60-minute time limit. Upon fully engaged participation in a Certified Scrum Master training class, you should be more than prepared to pass the exam. Once you have your CSM certification and at least 12 months of experience as a Scrum Master, you can seek an Advanced-Certified Scrum Master (A-CSM) designation by completing an A-CSM Training course and successfully completing all instructor-designated components of the class, as there is no exam for the A-CSM certification.

The second certification to consider is to support your understanding of the Scrum Product Owner role is one that is provided by the Scrum Alliance and does not require any pre-requisite work experience: The Scrum Alliance’s Certified Scrum Product Owner (CSPO) certification. Topics addressed include techniques for developing a product vision, how to create, maintain and order a product backlog, how to identify user needs and an overview of sizing (estimating) in Scrum. For this certification, you must first take a class from a Certified Scrum Trainer (CST) and successfully complete all instructor-designated components of the class, as there is no exam for the CSPO certification.

The third certification to consider is the PMI Agile Certified Practitioner (PMI-ACP)® credential. A review of the 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 certification is it includes many of the topics covered by Scrum-specific training courses in addition to other popular Agile frameworks. However, you are required to hold several pre-requisites, including 12-months of general project experience in the last five years as well as a minimum of 8-months of agile project experience within the last 3 years. The PMI-ACP training course satisfies the 21 contact hours required to take the PMI-ACP exam. The course includes 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.

Like the PMP exam, the PMI-ACP  exam is administered only at Pearson VUE centers.

Project Management Academy provides PMI-ACP exam prep training via an instructor-led course, available in several convenient formats: Live Classroom, Live Virtual, Private Group Training for 10+ students, and Self-Paced Online Learning.

Regardless of which certification you choose - and you could very well get a combination of the above - 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.

1. The Agile Manifesto, http://agilemanifesto.org/ ^

2. Scrum Alliance website, http://www.scrumalliance.org/ ^

3. Ibid ^