At Agile 2009, Mike Cottmeyer presented Agile PMP. Mike starts out by defining traditional project management from a PMPs perspective as managing the 9 knowledge areas of the PMBOK. He defines agile as a combination of engineering best practices, a leadership framework, and project management techniques. The PMBOK and Agile are not exactly the same. But the skills of a PMP are still valuable in an Agile project.
In traditional project management, we are trying to remove uncertainty. We are trying to learn enough up front so we can plan. In Agile we do not to take uncertainty out of the equation. We want to embrace it and manage it.
Next Mike reviews the Agile Manifesto and discuss how we still value the stuff on the right, but we value the stuff on the left even more:
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
Then Mike describes how agile inverts the iron triangle and says cost and time are our primary constraints. We need to figure out how much are we willing to spend and how long are we willing to give it and then figure out what we can deliver within those constraints.
Mike describes time management as breaking the project into releases and breaking the releases into iterations. Iterations are fixed in duration and do not overlap. The milestones are defined 1st, and for each milestone we define how much scope we can fit in it.
In software cost management in generally based on the amount of people on the team. Cost is the amount you are paying people times the time you are giving them.
Scope management is done by rolling wave planning or progressive elaboration, Epics (high level needs and goals) are defined at the project planning level (18- 24 months), features are developed during release planning (3 – 6 months), and stories are detailed during iteration planning (2 -4 weeks). We let details emerge as we learn more and more about the software we are building. At the iteration level is when we make the hard commitment.
Risk management is managing both business risk and technical risk. What are the kinds of things that can cause us not to realize the business value? What are the technical hurdles, unknowns, and assumptions that might put the project at risk from technical perspective? Prioritize for business value and counter balance by reducing technical risk as we go. Documentations is building a series of assumptions that are not validated until they are put into working software. By building software in increments we are mitigating risk. Some use a risk burn down chart.
Resource management is aligned with our goal as an organization to have that team able to deliver at the end of every iteration an incremental work of software. There is shared accountability of deliverable. We need to stop tracking individuals and track teams. One of the biggest impediments for adopting agile is cross functional and also specializing generalist. Focus on team utilization instead of individual utilization.
To measure progress, we skip Gantt charts, % complete, established baselines, and earned value, and instead use burn down charts at project, release, iteration level. With each done feature, we get a linear burn down of requirements. We can look at trends in burn down to asses project health. Traditionally earned value is done against activity applied. Those are not deliverables. If we look at earned value in terms of actual deliverables we get close to what velocity shows us. It becomes real earned value. If organization not ready for agile metrics, we can transform them into something they can understand.
Change management is done by minimizing the cost of change. We inspect and adapt, embrace uncertainty and plan for it.
Next mike covers the 9 knowledge areas:
Time management is about tracking deliverable (working software) and not activities in a plan. We need to reduce dependencies rather than managing dependencies. It is a different way at looking at requirements, system design, and organizational design. There are resource, technical, and requirements dependencies. We need to focus on minimizing dependencies in our plan. The focus is on prioritization over sequencing. When they happen is not as important as that they happen 1st. And we are always focused on delivering on time.
Cost management is based on the team size times the duration. We track ROI as we build. We focus on investing and getting a product back.
Scope management is planning in rolling waves. We make trade offs, allow room for negotiation, and frequently interact with the customer.
Risk management is built in and provides continuous visibility for both business and technical risk
Quality management is built in by using Test Driven Development, unit testing, and continuous integration.
Communication management is built in by the daily stand up meeting, story boards, planning meeting, and release planning meetings.
Human resource management is about having the right people on the team with the right tools and having a plan to keep people together. Stop building teams around project and build projects around teams.
Mike then talks about skills a PMP will need to transition to agile. He mentions facilitation, team building, and servant leader. He feels that there isn’t a one to one correspondence between scrum master and PM. He feels a PM is more aligned with a product owner. PM role might be a better fit if they are assigned to multiple teams, and manage context across the team like managing stakeholders.
This presentation is available on InfoQ at http://www.infoq.com/presentations/agile-pmp
