Standing By My Agile Claims

I recently posted a presentation, Agile Foundations and Agile Myths, at My goal in the presentation is to juxtapose destructive behaviors arising from a predictive approach and destructive behaviors from an agile approach. This is a deliberately provocative presentation – finding flaws with the common interpretation of both sides of the discussion. Glen Alleman over at Herding Cats responded to my presentation in his post More Agile Claims. He took offense to my “strawman” arguments against the predictive approach.

Predictive Approach to Improving Software Development

What I am calling the Predictive Approach addresses the “mental scaffolding” or underlying assumptions I see everyday in companies practicing what they believe they are guided to do in the PMBOK®, OPM3®, CMMI and DoD . The Predictive Approach describes the practices that arise from the overzealous and misguided belief that the following approach is the best way to improve software delivery.

  • Standardize processes
  • Optimize resource utilization
  • Perform rigorous up-front design
  • Produce comprehensive documentation
  • Get up front commitment to a definitive Scope, Cost and Schedule
  • Enforce strict adherence to the detailed plan

This is where Glen takes offense. He points out that nowhere in the PMBOK®, OPM3®, CMMI or DoD literature are we instructed to apply these in the value destroying way that I discuss. In fact, he charges that I am just “making it up.” But, Glen misses the point. I am not arguing about the literature – I agree with Glen’s interpretation. And I am not making it up. Every day I go into companies that are applying this approach in value destroying ways. In the last year I have been in multiple companies whose documented methodologies prescribe:

  • linear-document driven "over the wall" process thinking
  • assigning resources to multiple projects
  • comprehensive upfront design with detailed documentation
  • commitment to definitive scope, cost, and schedule, and
  • strict adherence to precise start and stop dates for individual tasks

I am not debating the literature – it is an issue of practice. Glen suggests in our discussion in the comments to his post that even the government sometimes exhibits this value destroying behavior.  My points aren’t straw man arguments against the literature – they are attacking a common set of misguided underlying beliefs that the value destroying practices arise from.

In fact, the Agile Manifesto itself arose as a response to common practice – not as a set of new practices. As of the writing of the Agile Manifesto, the writers (and many others including Glen Alleman and myself) had been practicing software development in an “agile” way for a decade or longer. Read the agile manifesto as a response to value destroying practice that is trying to bring attention back to what is necessary to successfully deliver software projects.

The Agile Manifesto

  • Individuals and interactions over process 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.

Agile Approach to Improving Software Development

And now, … the rest of the story.

The Agile literature rails against too much planning, non-value added documentation, misguided change control, de-humanizing linear process, and layers of bureaucracy.  There is clear recognition in this faction that these are value destroying. But the overzealous and misguided application of these beliefs lead to the other common set of value destroying practices I frequently run into.

  • No Planning
  • No Documentation
  • No Estimating or Commitments
  • No Process
  • No PM, BA or QA

Again, I don’t see the core agile literature advising these practices either. Alistair Cockburn, Jim Highsmith, Mike Cohn, Jeff Sutherland and Kent Beck all prescribe effective practices that support appropriate and progressively elaborated planning, documentation, commitment, and process. They all support the roles of project management, business analysis, and quality assurance when they aid in managing complex products. So the second part of my presentation addresses these misguided practices and presents finding a responsible and situation specific approach to delivering software that focuses on responding to change, enhancing flow and delivering value to the customer.

The Core Discussion

Glen’s response highlights an interesting challenge. My suggestion that current project management practices are value destroying brought out a strong response against agile. I have had the same response from the agile community when I suggest that agile beliefs result in value destroying behavior. Businesses need to be able to make informed business decisions – so we need predictability and planning (Check out Glen’s immutable principles). At the same time we need to manage the work in a way that protects and optimizes value. What is missing in many organization’s is a way to have the responsible discussion exploring underlying assumptions. Companies need to finding ways to make the situation specific changes necessary to balance predictive planning and agile execution.

Tags: , , , , ,

2 Responses to “Standing By My Agile Claims”

  1. Jim Highsmith says on :

    Dennis, great post. You are pointing out the difference between what I call Agile 101 and sustainable agility. Agile 101 is rule-based, do this, don’t do that. It usually takes the form of extreme cases, particularly for the protagonists. XP, for example, showed us what some of the extreme cases might be, but didn’t advocate that everyone should go there. While Agile 101 is necessary as a learning process, the sustainability process moves towards “both/and” thinking rather than “either/or” thinking. It’s not no documentation or stifling documentation, but minimal acceptable documentation (within context).

    My concern is that there is too much teeth gnashing at the 101 level (sort of like Republicans & Democrats), and not enough discussion of the context that leads to rich implementation of a balanced practices.


  2. Glen B Alleman says on :


    The suggestion I made was that the destructive behaviors you speak of are simply “bad” project management. Agile software development certainly has it’s place in the spectrum of product development.

    But to start with “bad” practices, without first indicating that they are “bad,” and providing corrections for them first, before moving to improvements seem a bit manipulative to me.

    In our large DoD/NASA programs much of the software is developed in an “agile” manner. We’re presenting a paper at the Feb NDIA (National Defense Industry Association) PMSC (Program Management Steering Committee) on incorporating agile development in Earned Value Management based systems (Validated systems).

    To follow Jim, the implementation of ANY development method within a business management process (EV is essentially a business management process) requires answering the 5 Immutable principles first, then deciding how the method will be applied – within a domain and a context inside that domain. The over generalization that agile is “the” answer causes many who need a better way to reject the suggestion. DoD is just starting to understand this on the 100’s of billions of $’s of software development they own.

    Using “bad” PM as a stalking horse does not improve the situation in our domain, when we’re spending the public’s money – yours may be different.

Leave a Reply