4 Agile project management techniques and why they sometimes fail
There are many techniques associated with what we call today Agile project management. I singled out 4 of those techniques that seem to be used in most projects, namely:
- Dynamic planning, also referred to as "rolling wave planning" 
- Timeboxing 
- Scrum 
- Deliverables evolution curves, usually known as "burndown or burnup charts", "velocity charts" or "percent of promises completed curves", "PPC curves" for short 
The purpose here is not to explain the exact mechanics of those techniques, but rather relate the way those techniques are usually applied with respect to the 8 principles of Agile covered in Part 2. For more information on each of those techniques, you can read the documents referred to in the footnotes.
Table 1, above, is a summary of my own observations on how many organizations use those 4 techniques. The techniques are often used quite blindly like “recipes”, often with very rigid parameters to respect. I was amazed to have an argument on very specific parameters with the person responsible for the implementation of Agile (for this person, meaning implementing “Timeboxing” and “Scrum”) in a very large organisation where most projects are IT related. I was preparing a conference for them on Agile project management; I intended to give some examples for “Timeboxing” periods and for the duration of a “Scrum”. I was asked to send my presentation material beforehand for validation; I was then told that according to their guidelines a “Timebox” should not be longer than 15 days and that a “Scrum” had to last 10 minutes… and asked to modify my presentation accordingly. I understood then that their implementation of those techniques had nothing to do with the 8 principles of Agile, but rather, sadly, with the search for a universal recipe to solve their need for organizational agility. Best practices promoted by recipes are the antithesis of agility.
The observations summarized in Table 1 need to be scientifically challenged by proper surveys. I believe, however, that they are representative of many implementations of Agile techniques. Many organizations try to perpetuate a work environment valuing “control” (for most the status quo) rather than to adapt to a very turbulent and changing work environment through new values like “collaboration”, “team work” and “collective accountability”. By doing so, they defeat the purpose of the Agile approach they are trying to implement. They fight to keep the status quo, while Agile tells them to accept change and manage it.
The “Theory of Constraints” and the rationale for integrating the missing Agile Principles to current implementations of Agile methodologies
“Timeboxing” and “Scrum”, at least as named, are Agile techniques that originate from the world of Software development. “Dynamic planning” and “Tracking deliverables/tangible promises” with “PPC curves” are associated to both the software development world and the world of Lean Construction Management, as promoted by the Lean Construction Institute. However, making sure those promises are done by the individuals delivering them is linked to the “Last Planner”™ principle , a principle not generally espoused and presented by software development specialists writing books on Agile. Lean construction project management also promotes, as a must, “integrated project teams” .
The 8 principles of Agile I promote are a mix between principles applied in Agile software development projects and those applied in Lean construction projects. Beside the “Last Planner” and the “Integrated Team” principles, there is another element we can find in Lean construction management books and articles, that is not often discussed in Agile software development literature. This element explains:
- why the “Last Planner” and the “Integrated Team” principles are essential; and
- why we need to include 2 more principles to succeed in our projects, the “Capability” and the “Desirability” principles.
I am talking here about integrating Goldratt’s “Theory of Constraints” in managing projects. Lean construction proposes managing around the constraint and elevating it as required .
In my series “Velocity” , I proposed that all projects are about making change. I proposed that the constraint, in any endeavour involving change, had to do with human resources, not with material or economic resources. I identified this constraint as the “capacity and will” to change, which justifies the need to include all stakeholders and ensure that they can and want to implement change. In this context, Goldratt’s “Theory of Constraints” is the approach that calls for the application of the 4 principles often missing in Agile techniques implemented in most software development projects. There is no doubt that, by adhering to Goldratt’s constraint management approach, software development projects will become really agile and get better results. I believe that, by applying the 8 principles of Agile, projects in any venue will be more satisfying for all stakeholders concerned and thus more successful.
Those 8 principles are congruent with a whole set of beliefs and values, that we could call an “Agile philosophy”. Part 4 of this series, my next blog entry, will present the 4 values and 6 beliefs that are the foundations of this “Agile philosophy”, values and beliefs that call for all of the 8 principles of Agile to make projects really work.
Don't forget to leave your comments below.
 For an discussion of "integrated project teams" see my blog entry at http://www.projecttimes.com/claude-emond/the-rules-of-lean-project-management-part-3.html
 A presentation of the Theory of Constraints is included in my blog entry http://www.projecttimes.com/claude-emond/velocity-part-3-five-basic-steps-to-effective-constraint-management.html and its references
 You will find more information on what is "Rolling wave planning" and how it works in my blog entry http://www.projecttimes.com/claude-emond/the-rules-of-lean-project-management-part-5.html and its references
 You will find more information on what are «Deliverables evolution curves» and how they work in my blog entry http://www.projecttimes.com/claude-emond/the-rules-of-lean-project-management-part-2.html , its references as well as in the following article: http://strategicppm.wordpress.com/2010/11/25/the-value-of-burndown-charts/