Why isn't agile "winning"? (part 1)

Over the weekend I received a comment from John Rusk (www.agilekiwi.com) about one of my "Ahas" from 10 Years Agile. He thought that my musing about whether Agile really matters or not was more of a reflection on how companies do business as a whole as opposed to a question about Agile.

His comment (which I do agree with in principle) caused me to realize that I hadn't quite captured the essence of the thought that led to that "Aha". Since I believe that this is one of the key issues facing the ongoing adoption of Agile both inside and outside of software development, I think it's worthy of its own posting. Well, that plus this is my blog, so the voting on topics is a bit skewed...

Let's start with some ground rule assumptions:

1. "It's a Dog Eat Dog World" - The capitalistic economic model creates an evolutionary "survival of the fittest" environment for companies.
2. "Show Me The Money" - The measurement of success for companies operating in this environment is money (revenue / profitability).
3. "Keeping Up With The (Dow) Joneses" - Business practices that have a positive impact on money tend to become adopted by other companies (akin to how beneficial genetic mutations spread through a population).
4. "Blink And You Missed It" - The rate of propagation of these "mutations" can be exceedingly rapid (days and weeks versus years) so it is good business to pay attention to what others are doing.

Assuming all of the above is true, you have an environment that is highly tuned to detect, adopt and innovate business practices that directly influence the bottom line. A couple of examples for your amusement:

• The Web - Say what you will about the insanity of the dot-com bubble, there was a solid business "mutation" at the root of it - the realization that the web provided a unique new channel to customers for companies. Two business behemoths of today trace their birth back to the heady days of the dot-com era - Amazon and Google.
• Lean Manufacturing - Most discussions of the origins of Lean credit Toyota for taking earlier concepts espoused by Henry Ford and others and adapted them to the dynamic challenges of the modern manufacturing industry. Today you would be hard-pressed to find any manufacturer that does not use Lean practices to some degree. This practice has been so successful that it has actually "mutated" into the Agile movement.

Interestingly enough, both of these examples of business practice "mutations" also contain an important cautionary lesson that may inhibit adoption of Agile outside of software development. Consider the following:

Dot-bombs. For every success story coming out of the dot-com frenzy, there are hundreds of failures. In most cases the failures were entirely predictable in that they failed to "Show Me The Money". What would possibly motivate otherwise sane business minds to deviate from focusing on money as a measure of success?

Henry Ford's Lean - According to Taachi Ohno (Credited with developing TPS - principal progenitor to Lean), he "learned it all from Henry Ford's book". If that were truly the case, why did the company that Henry Ford founded fail to "Keep Up With The (Dow) Joneses"? You'd think somebody at Ford would have at least one copy of Henry's book around, right?


In both cases the underlying cause seems to be a lack of understanding of the complexity of the business "mutation" that they were either pursuing or ignoring. 


In the case of the Dot Com bubble, a few extremely high profile IPO's (theGlobe.com) and company sales (Hotmail) demonstrated to the market that there was a vast new frontier of business opportunity on the internet. Unfortunately for the market as a whole, there was a lack of realization that the valuations of these high profile deals were based on a speculative model (% of market share) and not a traditional valuation formula (revenue times X). Establishing the value of a company based on market share alone is quintessential "betting on the come". This is not to say that it does not have it's place. In the case of Microsoft buying Hotmail this was a classic example of where this sort of valuation makes sense. 


But the larger business community simply saw that the valuation of internet companies was shooting through the roof and rather than taking the time to understand the complexity of this new frontier, companies settled for mimicking the outward appearance of moving to the internet. We all know how that played out.


With Ford and Toyota, the complexity comes from a different angle. Henry Ford was definitely on to something with his fledgling "Lean" practices. What Henry (and Ford as a company) failed to grasp is that the challenges facing manufacturers are not just static (waste in manufacturing processes) but also dynamic (supplier is late in delivering critical parts). Unfortunately for Ford and other US manufacturers, the next several decades would not provide them with the sort of environment that would force them to innovate to improve quality and productivity. This wasn't the case in Japan, where a weak post-war economy forced manufacturers away from reliance on mass-production economies of scale to remain in business.


When Japanese autos did show up on US soil, the US auto manufacturers initially failed to understand the different practices that Japanese manufacturers were following. By remaining at a low price point and steadily improving quality, the Japanese manufacturers stayed in the market when by US manufacturer standards they should have been out of business. US manufacturers like Ford failed the "Keeping Up With The (Dow) Joneses" principle, which set them up for being hit square by "Blink And You Missed It". By the time they realized that something was up, Japanese manufacturers had surpassed them in quality and were taking away significant market share - a state of affairs that persists to this day.

Hopefully by this point we have established that:

1. The business community as a whole is quick to recognize and adopt practices that have a clear impact on "success", namely money.
2. The business community as a whole is not so great at recognizing when a practice that has a clear impact on money is complex. As a result the tendency is to mimic the appearance of the practice as opposed to adopt the actual practice.

So what does that have to do with Agile? Good question. If you haven't already worked out where this is going, you'll have to wait until the next posting when I actually try to answer the question of "Why isn't Agile 'winning'?".

My "Ahas" from 10 Years Agile

The Salt Lake Agile Roundtable discussion group (Yahoo Discussion Group) has a little tradition that I've become quite fond of over the years - at the end of the meeting everyone in attendance has to provide at least one "Aha" moment (something during the discussion that stuck with you) from the discussion. Not only does it reinforce important concepts by repetition, once you know that you need to communicate these to others you start to pay more attention to the conversation. Which in turn gives you more "Ahas" and so on.

Once I discovered that I somehow connived myself onto the invitation list for the recently completed "10 Years Agile" conference (#10yrsagile for twitter fans), it was inevitable that there'd be some forthcoming "Aha" moments from the conference that I'd want to be sharing with whoever would listen.

At this point it's probably worth mentioning that my particular style of Agile is the Crystal family of methodologies developed by Dr. Alistair Cockburn. I became a fan of Alistair back in 2002 when we were speaking at the same local conference on software development, and over time that relationship has developed to the point where I consider him both my mentor, and one of my closest friends.

I do have a real point to my blatant name-dropping. Alistair had asked me to publish my "Ahas" somewhere so he could do whatever it is that he wants to do with them. So with that in mind, here are my "Ahas" from 10 Years Agile.

1) Leadership and Vision - There was a lot of discussion around the concept of "leadership" in the Agile community. Makes sense, but it seems to me that discussing leadership without a parallel conversation about vision isn't going to make a lot of sense. If anything perhaps we should focus first on defining what our shared vision is, and then address the issue of leadership. Since it's clear that we've already got leadership in play (see "elephants" below) I am not so sure that more or different leadership is going to make as much a difference as we'd like.

2) Defining and realizing "Value" - One of the most prevalent issues was value - defining it, quantifying it, increasing it, you name it. Value was definitely one of the more pervasive issues in the discussion. The specific "Aha" that occurred to me was that we may be over-simplifying our discussion of value in relation to an Agile organization. The value of Agile means different things when you move between individual <=> team <=>organization. The ways that you measure value for each are going to vary greatly. Job satisfaction as a value measurement means a lot to an individual, but not much to the organization. Return on investment is a key value for the organization, but how important is that to the individual?

3) Practices and Tools outside of development - One of the more interesting frustrations I had during the course of the conference was the seemingly pervasive attitude of "Agile is for software". At one point in the discussion a participant claimed that a team isn't Agile unless they have followed specific software testing practices. Later in the conference there was a heated debate about whether the term "engineering" should show up in one of the outputs of the conference. I am not debating the need for specific practices that will improve work products. What irks me is if we expect Agile to become a tool for the organization as a whole, don't we think that the tools and practices of the CEO, or the Marketing team have the same importance?

4) Elephants in the room - Of course we're talking about the prevalence of the "certification" entities as the most visible public face of Agile to the world. It was clear that there wasn't a lot of love in the room for the value of certifications as they exist today in the Agile world. What didn't seem to be so clear to others (or maybe I just didn't have the right conversations) was the fact that there isn't much we can do about them other than work with them or put out a better product. Take an organization like the Scrum Alliance. Are they going to change their business practices based on outcry from the rest of the Agile community? Not a chance. By the best definition of success we have in a capitalist system, they are successful because they are making money. If we don't like what they are doing, there's a proven formula for dealing with this. Compete with them and force them to change by way of a superior offering.

5) From Certification to Evaluation - The real problem that I see with #4 above is the fact that the business community is accepting certifications as if they somehow predict job performance or improve the chances of successful adoption. Unless you can show me what your failure rate is for people attempting to certify as whatever title you're giving, I'm not the least bit interested in that certification. What amazes me is that the certification bodies themselves aren't more concerned about this. Without critical evaluation of the knowledge and skills that are being trained how does the certification organization know how effective its educational effort is?

6) Does Agile really make a difference? - Not so much a question that showed up at the conference, but one that kept running around in my head, kicking over garbage cans and spray-painting the cat. As mentioned in #4 above, a capitalistic society provides some very clear measures of success, and is as Darwinian an environment as you can get for principles and practices that affect the bottom line. It's clear we've made excellent progress over the past 10 years, but it's still not so clear to me why businesses aren't beating down the door to really adopt Agile throughout the enterprise and not just be buzzword compliant. If we expect Agile to move from the dev team out to the larger organization we're going to have to be much clearer about defining and proving the real value of Agile as a better means of doing business.

"Agile Sadist". Really? REALLY?!?

Yes, really.

No, I don't show up at work decked out in a full leather jumpsuit, whip in hand, impatiently waiting for the first hapless developer to come scuttling by. If my professional colleagues and co-workers can be believed, I'm actually not that bad to work with on a daily basis, at least as long as there isn't any Dilbert-esque sort of shenanigans going on in the organization.

Before I dive into why I'm risking guilt by association with one of the more "colorful" genres of adult entertainment, let's clarify something about what Agile means, at least to me. Around 4 or 5 years ago I was sitting with Jeff Patton, discussing whatever it was at the time that was interesting to us, when an "aha" showed up in our conversation. It seemed important enough at the time to warrant writing down, so we did:

It says: "Agile adoption isn't process adoption - it's culture adoption"

Culture is defined as "the behaviors and beliefs characteristic of a particular social,ethnic, or age group". Practices that do not align with underlying cultural principles are at best ineffective. Take the example of the stand-up meeting. How well does the stand-up give early warning of trouble if there isn't sufficient personal safety within the culture to allow someone to bring bad news to the attention of the group?

But I digress. Back to the point.

The "Sadist" term was chosen (very carefully, I might add) for two reasons. The first, and most important, was a realization that individual and organizational behavioral change isn't just influenced through positive means. Whether we like it or not, humans have evolved more mechanisms for changing behavior based on negative stimuli than we have for positive behavior. It doesn't take a three day certification seminar to teach you that fire isn't something that should be handled with bare skin.

Before you jump to conclusions here, understand that I am not advocating that your team be used for practice by novice hibachi chefs if they fail to deliver a release on time. But understand that pain and discomfort, whether it be physical, emotional or intellectual, is an effective tool for changing behavior.

Not exactly a happy thought, is it? Rest assured that unless the organization that you're trying to effect change in is the military or some sort of terrorist group, physical pain isn't on the menu. To be honest, even the term "pain" isn't on the menu. When I talk about using "pain" as a means of effecting cultural adoption, what I really mean is "discomfort".

Here's an example. Once upon a time there was a small company that has more than one stakeholder for a specific software product in the same office as the development team. Each time a stakeholder needed something in the software, they'd go to an individual on the team and demand that it be done now, regardless of what was being worked on. It suffices to say that there was a fair bit of thrashing going on.

To change this "back-channel feature request" behavior, I decided to make sure that the discomfort of shifting priorities was felt directly by the stakeholders and not just the development team. The stage was set by getting the stakeholders to agree to discuss any changes with the rest of the stakeholders before they could go into the current iteration. As each stakeholder had been bitten by changes before, they readily agreed to the change. I think it was a day later that a stakeholder came in with a request. Their argument of "it'll just take a minute" didn't dissuade the team from calling a stakeholder discussion on the spot. Not only did the stakeholders deny the change, they admonished the originating stakeholder for disrupting the team.

It didn't take many of these negotiations to change the behavior of the stakeholders.

The second reason for choosing "Sadist" is a bit more personal. More than once in my life I have been accused of unnecessary hyperbole to get a point across. Guilty as charged. What I've learned though is that hyperbole is a good tool for generating interesting discussions. If I had fashioned myself as an "Agile Organizational Discomfort Enhancer", I'd probably lose interest in what I had to say before I'd even finished forming my response. But as a self-professed "Agile Sadist", I can honestly say that there has been no lack of interesting discussions to be found in the Agile community.

Oh, and another interesting thing about hyperbole - it's a sort of a hybrid intelligence/awareness test. Most people don't look past the hyperbole to see what is really there. For the few that do, it's nice to have them announce themselves by saying:

 "That's interesting. What do you really mean by that?".