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.

Would the process capability levels fit an Agile Environment?

In CMMI, the scale to measure a process capability is divided into 5 levels: performed, managed, defined, quantitatively managed and optimizing. Do these levels make sense inside the Agile world? Would this be the improvement path that an Agile organization should follow to improve its processes? Is the scale compatible?

Let’s look at the 5 levels:

Performed Process

“A performed process accomplishes the work necessary to produce work products”. The first level falls outside any approach, so it’s pointless to analyze it.

Managed Process

A managed process “is planned and executed according to policy; employs skilled people who have adequate resources to produce controlled outputs; involves relevant stakeholders; is monitored, controlled, and reviewed; and is evaluated for adherence to its process description.”. The key difference with respect to a performed process is that the managed process is planned and then measured, having the possibility of taking corrective action “when the actual results and performance deviate significantly from the plan.”

What would it be a managed process inside an Agile environment? Well, basically I believe there are no managed processes, at least not in the way suggested here which distills a command and control project management mentality where management means “monitor, control and take corrective action”. This type of management is in the heart of CMMI (Prof. Judson Neff says “the only way to manage complex operations is to manage, to detailed and precise plans”). Agile, on the other side, relies on another type of management. One that sets the limits and get the resources, but that allows the team to self-organize to accomplish the work. It relies on a management that uses leadership to manage. Well, probably it’s just my view because nowhere does it says that a project manager is the one that monitors, controls and take corrective action (does it?). It is important nonetheless to stress that the process should be managed by the team, which should be the one that plans, monitors and take corrective action if necessary.

Defined Process

“A defined process is a managed process that is tailored from the organization’s set of standard processes according to the organization’s tailoring guidelines; has a maintained process description; and contributes work products, measures, and other process improvement information to the organizational process assets”. This level is where standarization/institutionalization comes in. Projects learned from the organization standards, and the organization learns from the projects as knowledge goes both ways.

I believe that besides having defined processes, an organization would benefit from having a defined set of values. For example, I think that an organization may have a process to gather requirements from customers. As important as the process itself is that everyone believes that having constant communication and collaboration throughout the project is vital to success. Another example that I can think is that of technical excellence. I believe that more important than having a defined process for developing is having the mentality of a software craftsman and understand why technical excellence is so important (why doing automated tests, clean code, etc.).

Agile was described for the first time as a set of values, and it is this set of values what guides agilists. Having these values defined and clear inside the organization is probably of more value than having the exact process definitions. I know it does sound unrealistic, as having a repository of values probably doesn’t make a lot of sense. Probably values live more on the tacit knowledge of the organization and they are more like a human asset. Well, Agile is more about people than about processes after all...

Quantitatively Managed Process

“A quantitatively managed process is a defined process that is controlled
using statistical and other quantitative techniques. The product quality,
service quality, and process-performance attributes are measurable and
controlled throughout the project.” Measuring and statistically analysing allows to identify the special causes of variation and prevent its recurrence.

There are 2 things that I am afraid to, when measuring the processes. First, something that stayed firmly in my mind after reading Highsmith’s book: Value over constraints. It’s far more important to measure, or at least to understand, how  much value a certain process provides than to measure and optimize for the constraints. A team worried by meeting objectives related to constraints is at great risk of generating dysfunctional behaviours which decrease the value that the team is able to generate. The second thing that I am afraid of is relying only or too much on numbers and measures. I know from an organization perspective (broad perspective) understanding what works and what doesn’t in terms of numbers is perhaps the only way to know what’s working and what isn’t but my experience in development teams says that common sense and team feeling are also important, not measurable and equally important. I guess I am reluctant to believe that everything in a human intensive task such as developing software can be quantifiable.

Optimizing Process

“An optimizing process is a quantitatively managed process that is changed and adapted to meet relevant current and projected business objectives. An optimizing process focuses on continually improving process performance through both  incremental and innovative technological improvements.                              Process improvements that address common causes of process variation, root causes of defects, and other problems; and those that would measurably improve the organization’s
processes are identified, evaluated, and deployed as appropriate.”

A couple of thoughts came to my mind after reading the CMMI optimizing process level: First, it seems to me that the definition is geared towards a production environment, not a development one. Variable results are good in development, when knowledge is formed and not good in production. Second, it is weird to me that the idea of optimizing comes only in the last level coming from the Agile world, where introspection and improvement are performed since the very beginning (at a very intuitive level). On one side, it makes sense because to be able to optimize, you need to have a managed process and be able to measure/quantify what needs to be improve. On the other, leaving the optimize mentality until the last level could be harming (in my opinion). Finally, nowhere does it say that the optimization is to be able to produce more value for the process, which I think should be the first objective. Probably, in other engineerings or in manufacturing, optimization is performed to decrease variation or find root causes for defects. In software development, where variability creates knowledge, this is not entirely true.

Conclusions

I believe that intuitively, the capability levels are compatible. The first improvement from not doing anything is that the process is managed, i.e plan and monitor to take corrective action. Doing it in an Agile way, it should be managed by the team. Then, there is institutionalization. I believe that the institutionalization of the Agile values is equally important than institutionalizing the processes. Then, there is understanding how good or how bad the process is working and optimizing it. The most important, but probably most difficult thing to quantify is how much value the process provides. Also, something to keep in mind is that software development is very different than doing manufacturing.