I’ve been reflecting a bit on my Cutter 2010 prediction – “Although Agile adoptions will proliferate, we will see an increase Agile project failures due to misunderstanding, misapplication, and misguided attempts to follow an ‘agile recipe’.” It feels a little pessimistic to me so I wanted to elaborate further and hopefully give readers some ideas about how to avoid experiencing an agile failure. As an agile consultant I get to work with a lot of different companies in various stages of agile transformation; with varying corporate cultures; and experiencing varying challenges and successes. Through these experiences success patterns and anti-patterns emerge.

I’ve begun referring to success patterns as Being Agile and anti-patterns as Doing Agile. Doing Agile refers to organizations who fail to move beyond the simpler trappings of agility: iterations, daily stand up meetings, etc. Being Agile refers to organizations whose inherent values, behaviors, and guiding principles exhibit the essence and spirit of agility: adaptive, evolutionary, value driven, and quality driven development. Organizations that ARE agile also DO agile; but the inverse is not necessarily true. Many organizations are decidedly non-agile while still utilizing many agile practices.

Foremost Agile development is about continuously adapting to change and evolving toward the right solution, not necessarily the planned solution. Adapting and evolving should be celebrated, yet many agile organizations continue to view deviations from the plan as a negative. No doubt, change is disruptive and uncomfortable. It means telling stakeholders that our previous projections were somehow wrong. However, truly agile organizations understand that early projections are based on everyone’s best judgement in spite of loads of uncertainty. They are delighted when the collaborative process unravels this uncertainty early, and the projections are revised in light of newer and better information. Such organizations enable and encourage the kinds of effective collaboration between software creators, users, and planners that help them to refine and revise their projections as early and frequently as possible.

Adapting and evolving requires active engagement with customers and users of the solution. Without customer collaboration the feedback loop is incomplete and there is nothing to which we can adapt. Unfortunately, real customer collaboration is messy and difficult. We might get conflicting demands. We might have to throw away work. It takes time away from development. They might not make the time to truly review features. There are lots of reasons that many agile teams rely too heavily on product managers, product owners, and business analysts and fail to actually spend time with real end users of the system under development. Unfortunately, these roles are a poor substitute for real customer collaboration.