While continuing to grow, the state of agile adoption seems to be plucked straight out of an Ayn Rand novel, where the acceptance of mediocrity has infected the masses like a plague. Half-hearted adoptions have led to half-hearted results (as in "we suck less") that in turn are leaving these organizations straddling a tipping point from which they more often than not slide backwards, rather than making the push over the top to high performance and exponential growth in ROI.
Jeff Sutherland pointed out in his Agile2008 presentation "Money for Nothing and Your Changes for Free" that 74 percent of Scrum teams he's tested were "Scrum-but" teams. (Actually, Sutherland referred to them as "ScrumButt" teams, but I prefer to use a more/less descriptive phrase, depending on your viewpoint.) He concluded that some teams claim, "We're doing Scrum, but (insert practices we are not doing here)." For example:
- We're doing Scrum, but we don't do burndown charts
- We're doing Scrum, but our sprints (iterations) are eight weeks long
- We're doing Scrum, but we don't deliver working code at the end of the sprint; sometimes we just do analysis or design work and deliver a document
David Douglas and Robin Dymond of Innovel, LLC may have found a reason for this haphazard adoption of agile practices. They discussed their observations in their Agile2008 presentation titled "We Suck Less," in which they shared their experiences hearing how companies are defining success as "We suck less than we did before."
I have seen the same things that Sutherland, Douglas, and Dymond have seen namely that companies move forward with their agile adoptions without a clear understanding of what it means to the rest of the organization and end up adopting a few practices that the engineering department likes, a la Sutherland's Scrum—but teams. And they find that, as a result, they do indeed suck less than before. Because of this immediate success, they often stop after these quick wins, not wanting to attempt to clear the hurdles that would bring extended organizational change.
Indeed, many companies are refusing to view agile as anything other than a set of engineering practices. They have not adopted the value system that is the underlying infrastructure of all agile approaches. As a result, their agile adoptions stall at the "we suck less" level. Douglas and Dymond call this acceptance of minimal improvement the "first little pig syndrome" after the fairy tale "The Three Little Pigs." In other words, organizations are content to build their house out of straw and not worry about the wolves.
It's been my observation as well that the majority of companies are happy with mediocrity and do not move forward to take advantage of Sutherland's cited 400 to 500 percent increases in ROI that can be realized if they adopt the entire suite of agile principles and practices. Only a few companies, such as Nokia and Sutherland's own PatientKeeper, are busy building brick houses that will stand up to the wolves in the marketplace.
And who can blame these first little pigs? Further change is hard work. It would require collaboration beyond their departments, cutting through politics and power plays to try to reach consensus on a new way of doing business. For many this means a sea of change in the corporate culture, and as individuals it is a daunting hill to climb indeed. It's easier, and sometimes safer in terms of short-term job protection, just to adopt a few agile practices, call it a success, collect your bonus, and go home.
While Douglas and Dymond coined a name for the mediocrity acceptance syndrome, they did not define a name for the tipping point I've observed that these organizations ultimately reach. And by tipping point I mean not only the Malcolm Gladwell definition of "the moment of critical mass, the threshold," but also the moment when, upon reaching the threshold, one can tip either forward or backward: the fulcrum or crux.
That tipping point occurs when the division discovers that they've adopted all the practices that were fairly easy to do and must now make some tough decisions regarding whether or not to push forward over the hill by making the more difficult political changes in the organizational structure that would allow the teams to improve productivity. I have been calling this decision point "high-centering." High-centering is a phrase used in four-wheeling to describe what happens when your vehicle climbs over a rock only to end up balancing on its chassis, with none of its wheels able to make any purchase to move either forward or backward.
When an organization high-centers, something has got to give. The idea that organizations can rest on their laurels of "we suck less" without consequences is an exercise in denial. One of three things will happen: They'll slide back down that hill, they'll push forward over the hill, or a strong wind will blow them off that rock making the whole issue of agile adoption moot.