PMI’s PMI-ACP
Many of us have heard the terms Agile and Scrum. If you have a similar background to me then you have heard them largely as a way to build software in a team environment. Established in 2011, PMI’s Agile Certified Practitioner certification looks beyond the confines of specific methodologies and past the boundaries of software projects and shows how they can benefit many types of projects while using any number of tools. I took an online course to prepare for the certification exam. While software development was the target for the majority of the course I took, there was an effort to point out that the methodology, and some specific tools and techniques, could apply to other types of projects.
The ACP certificate has roots in the Manifesto for Agile Software Development. The manifesto was created on 2001 by a diverse and high-profile group of people in technology at the time. They came up with it based on their own experiences with the tools and techniques they had developed and were using. Many of those tools and techniques are called Agile today. The Agile Manifesto consists of a statement of why, four values, and a closing statement as follows:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.
The Agile Manifesto includes twelve principles of Agile Software which are not as large a part of the exam. They are relevant to a deeper understanding of Agile as they helped shape the final wording of the manifesto. I would encourage everyone to look them up at AgileManifesto.Org when they have a chance.
Agile in and of itself is sometimes misunderstood to mean a specific way of working a project. In practice Agile is at a higher level of detail than that. Agile is a way to approach a project including tools and techniques available for Agile implementation. The Manifesto and Principles specifically suggest a mindset for software development over project management but is also applicable more generically. From this mindset we can pick tools and techniques that support Agile while also fitting with our environment.
Another big confusion with Agile is that it lacks in planning. This is often a view held by people who have a lot of experience with classic project planning methods, such as Phase Gate or Waterfall. In many classic planning methodologies the bulk of the planning work is up front. After that change management practices get put in place to help prevent changes. For instance, we have all probably heard of “Scope Creep” at one point or another. In a classic plan this is a big problem. With an Agile plan change is welcomed and manageable. This is due to Agile focusing on delivering the user value, not completing tasks. It acknowledges that what is known as valuable changes over the course of a project. A good quick explanation of this difference is that classic project management is generally plan, plan, plan, work, work, work whereas Agile is generally plan, work, plan, work, plan, work. This speaks directly to the basic Agile work structure which is highly cyclical in nature.
An agile software project will usually have a start where a high level view of the features to be built is set down. These features are ranked from day one in order of importance to the user groups. Minimum functionality is established, and milestones may include specific added functionality. These are generally where the big releases will be. Each release will provide value to the users in the form of completed features. The iterations leading to a release will also include completed value. (A Release is an Iteration, but an Iteration is not necessarily a Release.) Features are broken down to the smallest level possible. They may be known as user stories or backlog items. No matter the name they should contain one specific feature/action that is valuable to the user. From these items tasks are created and estimated, again as small as possible. A difference here from classic project management to Agile is that the product owner is in charge of features and the development team is in charge of tasks. The project plan is continuously revisited with new features added and the rankings re-evaluated. This is because what was initially seen as important for the third release might be pushed back, pulled forward, or dropped entirely by the users as they start to actually use the product. At some point, either time or feature based, the project will close and switch to a maintenance mode.
There are many tools and techniques to help teams make this happen. Scrum and Extreme Programming are two methods with their own tool sets. Burn-Down charts and product backlog lists are tools common to many methods. Kanban uses a daily status board as a primary tool. There is nowhere near enough time to go over the possibilities. Suffice to say that it would be hard to not find some tools and techniques that work for any given team and environment.
On our team specifically we are getting ready to launch a big project. It has not been directly identified as an agile project. That being said, it is shaping up already as a project with an agile flavor. As our team refines our process leading up to and during this project I hope to use what I have learned to help us deliver the most value to our users in the shortest time.
