Is the Project Planning Process Area compatible with Agile?

Introduction

The Project Planning area, a process area at maturity 2, aims at establishing and maintaining plans that define project activities. To construct a plan, the requirements need to be determined and estimated and with this information, a documented plan that stakeholders can commit to should be built.

Below are the specific goals and practices:

SG 1 Establish Estimates

SP 1.1 Estimate the Scope of the Project

SP 1.2 Establish Estimates of Work Product and Task Attributes

SP 1.3 Define Project Lifecycle

SP 1.4 Determine Estimates of Effort and Cost

SG 2 Develop a Project Plan

SP 2.1 Establish the Budget and Schedule

SP 2.2 Identify Project Risks

SP 2.3 Plan for Data Management

SP 2.4 Plan for Project Resources

SP 2.5 Plan for Needed Knowledge and Skills

SP 2.6 Plan Stakeholder Involvement

SP 2.7 Establish the Project Plan

SG 3 Obtain Commitment to the Plan

SP 3.1 Review Plans That Affect the Project

SP 3.2 Reconcile Work and Resource Levels

SP 3.3 Obtain Plan Commitment

Let’s analyze the compatibility of each goal

SG 1 Establish Estimates

This specific goal states that there should be a way of estimating project planning parameters needed to perform the necessary planning, organizing, staffing and budgeting. Factors typically considered are: project requirements, scope, identified tasks, technical approach, etc.

I believe it is very important in Agile as well to be able to provide initial estimates that allow the project to be resources and funded. There are techniques like Story Mapping and planning poker that can be used to provide an initial estimate of the effort needed to complete the project.

There are 3 points that in my opinion should be mentioned in this goal to be more compatible with Agile:

1. Estimations are rough at this point in the life of the project: I believe it is of no value to spend more time trying to refine them. There is a useful concept called the cone of uncertainty that illustrates how estimations become more accurate as the project progresses (i.e. as more is known about what needs to be estimated)


2. Maintain the estimations is really important: Mike Cohn called his book “Agile Estimating and Planning”, because in Agile this is an activity that is performed continually throughout the life of the project. It is of more value to provide rough estimates at the beginning and then update them (and of course re-plan based on the new ones) than trying to be accurate when there is no enough information.
3. Committing to estimations can create dysfunctional behaviours: SG 3 states that the stakeholders will commit to the plan created based on these estimations. If the people in charge of the estimations will be penalized for their estimations, what ends up happening is they tend to buffer their estimations, providing the more pessimistic numbers. I have a personal experience in a CMM5 level organization, where we needed to provide estimates and we were penalized if the estimations differ on -25%/+25%. Of course they never did, because we buffered all the estimations and then worked slowly and with time, as our estimations forced us.

SG 2 Develop a Project Plan

A project plan is a formal, approved document used to manage and control the execution of the project. It is based on project management requirements and estimates. The plan should include the budget and schedule, should identify risks, should plan for needed resources and skills and finally for the stakeholder involvement.

There are 3 points that I believe are worth mentioning with respect to Agile plans:

1. A good plan should prioritize work according to the features that provide more value: This is the best way of minimizing risk and improving the ROI. A project sliced in incremental releases enables customers to receive the features they need the most sooner. This possibility is one of the great advantages of Agile and I believe should be reflected in the way CMMI suggests to build the plan.

2. The plan should be light: Agile embraces change. Adapting to change requires that products artifacts are changeable. The codebase should be easy to change and the coordination artifacts (like the plan) as well.  

3. The plan should not be activity-based: Mike Cohn explain in the 2nd chapter of “Agile Estimating and Planning” that one of the reasons that traditional planning fails is that planning is based on activities rather than on delivery of features. Cohn states that activities-based plans have 3 disadvantages:
- “Customers get no value from the completion of activities”
- “When we review a schedule showing activities we do so looking for forgotten activities rather than for missing features”
- “Further problems occur because activity-based plans often lead to projects that overrun their schedules. When faced with overruning a schedule some teams attempt to save time by inappropriately reducing quality.”

SG 3 Obtain Commitment to the Plan

“To be effective, plans require commitment by those responsible for implementing and supporting the plan.” says CMMI.

I believe this is the most incompatible objective in the area. Commitment to a plan? What if changes are needed? Having to obtain a formal commitment to a plan indicates a lack of trust in the organization. People committed to a plan will probably fail to deliver the best value, as they may be committed to outdated objectives. People need to be committed, but I doubt that obtaining this commitment formally and to a plan is the best way of obtaining commitment.

Conclusion

While it is important in Agile to be able to provide estimations, build a plan and commit to it, I have my concerns that having to fulfill the CMMI objectives forces Agile teams to provide plans that have more information than needed, put more effort on the estimates than what provides value and create dysfunctional behaviours. Planning and plans are important, but they are just a tool in our objective, which is providing the value the customers are looking. Plans built with too much uncertainty don’t have any value and neither forcing people to commit formally to them.