Why Agile Isn't Just for Development
This is my site Written by Alora on April 21, 2009 – 11:41 am

Agile LeaderIt’s been years since the evangelism for Agile development started truly gaining momentum. Super sexy buzzphrases phrases like “reduce time to market,” “improved ROI,” and “lower development costs” have all been invoked to support the case for adopting an Agile methodology over the old-school Waterfall approach.

The fact is, most experienced professionals have lived through enough project pain that they don’t typically need a huge amount of convincing that Waterfall is often inefficient — particularly for longer, larger, more complicated projects. In a fast-moving world, the risk of constantly changing requriements is ubiquitous, and a Waterfall project does very little to insure against that danger while still delivering a valuable product to users.

However, the problem with the “Agile Development” argument is that, in order to work properly, Agile can’t just be for software development. In fact, Agile can’t even just be for your project teams. Your entire business needs to be ready to adopt an Agile methodology.

The trouble is, this conflicts with standard business-model thinking. In his book “Maverick,” Ricardo Semler outlines the critical success criterial for modern business: “To survive in modern times, a company must have an organizational structure that accepts change as its basic premise…” He goes on to discuss the more ‘agile’ approach at his company, Semco, and why: “[W]e take an operation view of six months, because we found that in a conventional one-year plan people will invariably believe that conditions will improve just enough to compensate for the problems they know they’ll have in the first half of the year.”

How many of us have seem Semler’s point in action? In annual budget processes? In project planning? Somehow, some way we convince ourselves that whatever conditions that exist today will be “resolved” and we’ll be able to make up lost ground later. And so our plans are based on figuring that we’ve got a brief rough patch to get past, but once we do that, we’ll have 100% clear sailing. How often does that actually happen?

Of course, just looking out six months isn’t sufficient, either. At Semco, Semler and team have two plans: one with a five-year view to keep an eye on strategic planning, will the six-month view focuses on tactical execution. But isn’t this what we have come to recognize as the definition of “Agile Development”? A long-range goal that we approach in short bursts, one piece at a time.

But if we change “Agile Development” to “Agile Leadership” it not only allows us to approach application development with flexibility and agility, but also the way we look at the bigger picture. Development efforts — whether they are for back office systems, B2C web sites or client engagements — are a means to an end, not an end themselves. We recognize that changes to business conditions are a big part of the reason we get value out of Agile Development, but then we continue to approach management of our actual business as though it were static.

I was recently approached about a “four-year project.” Horrifyingly (yet predictably) enough, this was a Waterfall technical project (for a government agency). In technology terms four years is an eternity. The idea that any team (or group of teams) would be spending four years and tens of millions of dollars on developing and implementing a technical solution for anything is insane, because no matter how good your requirements are this year, by the time the project is complete (assuming it is actually complete in four years) the entire world will have changed. Four years is an ice age when it comes to technology, and it’s at least a lifetime when it comes to business.

So what would need to change if we applied “Agile” methodology to an entire business, intead of just the development teams? Consider this:

  • Evaluate the business from end-to-end and examine how much is truly “operational” and how much is “project-based.” Your operating models, staffing, budgetary and expectations are all different for the different sides of the organization. And, in many cases, most people should have a mix of both to keep business moving while also getting new work done and keeping employee engagement as high as possible. But we need to truly stop and look at this, because without first understanding how much time people have to dedicate to project work, we never build realistic project schedules. How many project plans assume each team member spends 8 hours per day on the project? Does that ever really happen?

  • All projects would be time-boxed to ensure that, even at their longest, nothing dragged on for more than six months. This could be done by breaking large-scale projects into multiple smaller projects all organized as a program, or by breaking a single long project down into phases. But no matter what, no one phase should ever last too long. And at the end of every phase, a re-evaluation is done before proceeding to the next. How often have we worked on a project only to realize half way through that the work was really no longer necessary? Aside from being an irresponsible financial sink hole, this is also extremely bad for team morale.

  • Consciously examine the value of ‘domain expertise’ versus ‘fresh blood.’ As a career project professional, I can tell you that most leadership underestimates the value of giving a project team a new project — even if it’s the second or third phase of someone else’s project. The assumption that it is better to keep the “experts” in place rather than to get fresh blood looking at a problem is often assumed instead of explored. And while there can be some value, is the value found simply because the original team didn’t do a good job of documenting their work? Or is it just a simpler resource model. In my decade of project management experience, I’ve seen keeping the same team on a project for a long time do more harm than good. And I’ve seen very little formal evaluation done to ensure the decision was actually being made instead of merely assumed.

  • Strategic initiatives like new product development make an agile approach particularly valuable. Market conditions change rapidly and outside factors can move a low-priority, nice-to-have product from the bottom of the list to the top of the list over-night. If you’re planning too far out in too much detail and with too much rigidity, then you are not leaving your team the ability to react quickly enough to stay ahead of the curve. In fact, even worse, if your planning goes out too far, you end up inadvertently discouraging your people from staying abreast of the latest trends and changes, because they get into a ‘heads-down’ mentality, focusing on the long list of things they know are going to be occupying their time for the next year plus. This is one of the ways that companies lose their edge entirely.

Budgetting may be the biggest one of all, because we have been conditioned by most modern business practices to think in terms of quarters and years. Quarter-by-quarter planning is often too frequent to be efficient, but year-by-year is often too far out to be realistic. And, worse yet, it’s not far enough out to be strategic. It’s a combination of timelines that often work at cross purposes: we scramble like crazy for end-of-quarter numbers, and then we speculate wildly when building out year-long budgets. And in the end, neither is usually very valuable to getting things done.

How many organizations with large expenditures on gasoline and/or natural gas of some kind had to stop what they were doing in the middle of 2008 and completely level-set their budget for the year, because the unprecidented cost of oil had made all of the year’s original numbers (no matter how conservatively planned) entirely meaningless? Trucking companies, airlines, agribusiness, shipping companies, etc. All of them, because at the end of 2007 when planning the 2008 budget, you would have been hard-pressed to find anyone who would have predicted that gasoline would top out near $150/barrel. (Hell, most people thought they were being generous if they budgeted for $100/barrel.)

I have seen two common outcomes to this process: either everyone spends weeks creating their budget for the next year based on wild speculation and generally accepted (often inacurate) assumptions, and then they are held to it kicking and screaming, missing one opportunity for market adaptation after another; or the organization stamps the budget as “FILED,” puts it in a drawer and never looks at it again, rendering the entire exercise valueless.

And while the 2008 oil roller coaster is an extreme example, this type of thing happens on smaller scales all the time. And so we plan optimistically and then make exceptions for all the things our plan didn’t account for. Josh Ross has an interview (ironically, shot the day after the mother of all recent unplanned disasters: the collapse of Lehman Brothers) called We Design For Possibility and Retrofit for Risk. And although he is specifically talking about Web 2.0 and information security, in reality that title applies to business in general.

We plan aggressively, assuming all will go acording to plan, and then we try to put out fires that errupt en route to our goals. Instead of sprinting in shorter bursts that allow less time for disaster to erupt, we take a marathon mentality that gives the world around us time to throw obstacles in our path over and over again.

Like so many other normal, mundane facts of our daily lives, the way we approach business is still largely rooted in Industrial Age thinking — it’s a model for which the Waterfall method makes sense. The time and cost to build something new is so high that you better make damn sure you know what you’re doing before you start. But as we transition from, as Chris Anderson puts it, the ‘economy of atoms to the economy of bytes‘ we trade in more and more investment cost for higher and higher opportunity cost. If we don’t start pushing ourselves to thinking, planning and acting like products of an Information Age, we will continue to pay the price for a lack of innovation and agility. And the more time goes by, the more of our competitors will make the change around us, the more we have to lose by burying our heads in the rubble of the Industrial Age.