I have been studying for this exam recently. I’ll be taking it within the next two weeks. Since it is a professional development experience that work is reimbursing for one of the things I can do for work is to share what I’ve learned through the class I took. Obviously I plan to get more involved with project management at work, but my manager wanted something more direct. Since I am also a toastmasters member I decided to write a speech that I would then present to the team. I have since decided that the presentation to the team will likely be more free-form, but the speech helped me frame an outline. I am now sharing the speech here, slightly modified since I delivered it.
PMI-ACP Intro Speech.
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 recently 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. That 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 considered 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 plan
That is, while there is value in the items on the right, we value the items on the left more.
The Agile Manifesto includes twelve principals 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 here 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 specific way to approach a project which has specific tools and techniques available for implementation. The Manifesto and Principles suggest a mindset for software development or project management. From that mindset we can then 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 Waterfall. In many classic planning methodologies the bulk of the planning work is up front, and after that change management practices are put in place to help prevent changes. For instance, as developers 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 it is welcomed and manageable. This is due to Agile focusing on delivering the user value, not completing tasks. It acknowledges that what is known to be 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 in an order of importance to the user. 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 that make up releases may also include completed value. An iteration does not mean there is no release for the user, just that it is not 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 toolsets. 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.
We use some of the tools and techniques in our teams already. We do our work iteratively. We use daily status meetings. We allow the business to constantly provide input to the product. While we do not use any specific tool to its fullest we have, as most software development teams in the last decade, already taken on an Agile look and feel. A transition to full Agile might be less painful here than expected.
On our team specifically we are getting ready to launch a big project to upgrade the shipping application. 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’ve learned to help us deliver the most value to our users in the shortest time. I am also more than happy to share everything I’ve learned with the other teams in our group, working side by side with you if desired.
I know that was high-level and quick. I would like to take a moment to answer any questions anybody might have right now and remind you to feel free to contact any time for more information.
The flakes look soft and fluffy. The evergreen in the parking lot across the street has a picturesque coating of white. I can imagine a quiet stillness outside. Sounds normally close and loud instead seem distant and muffled.
