Agile in big companies
Tim Bray writes on enterprise computing vs web startups, and there’s not much secret which side he favors. Obviously, I favor that side too:
Here’s a thought experiment: Suppose you asked one of the blue-suit solution providers to quote you on building Ravelry or Twitter or Basecamp. What would the costs be like? And how much confidence would you have in a good result? Consider the same questions for a new mobile-network billing system.
The point is that that kind of thing simply cannot be built if you start with large formal specifications and fixed-price contracts and change-control procedures and so on. So if your enterprise wants the sort of outcomes we’re seeing on the Web (and a lot more should), you’re going to have to adopt some of the cultures and technologies that got them built.
My two cents is that Tim’s right, but there are some non-trivial complications that are worth adding. First is that from the point of view of product requirements I’d imagine that most enterprise computing has complexities that most web startups don’t have to think of right off the blocks. When they were starting out, the terribly smart guys who built Twitter didn’t have to worry that much about decade-old legacy systems, regulatory compliance, or an installed user base of three hundred stressed-out employees who know the old thing just fine. This makes the process of reducing requirements into small sensible iterations harder. Not impossible, but I bet there aren’t many people who are great at it in that context.
Another question is of core competencies. There’s no question that a company like Facebook is a web technology company, so its web technology better be completely awesome, period. Its management will pay more for programmers because 1) it believes it’s important to get good programmers and 2) it believes in its own ability to tell good programmers from bad. But that’s not the case for every company that employs programmers. If you’re in the IT shop of a large pharmaceutical corporation, you’re not the core competency, the medical researchers are. You’re just part of the back office, and most likely, somebody above you occasionally has a conversation about whether they could get more bang for the buck by sending your work to an outside contractor.
Anyway, that relates because I believe that agile methodologies, as great as they are, are very talent-dependent: A bad technical team will do worse with agile methodologies than with something more top-down and constrained. So there are a number of organizations that are going to think “we can’t pay to have top-notch Web 2.0 coders, so we’ll have a big room of so-so coders and hire one architect to tell them what to do.” It’s about limiting the range of outcomes, which when done well, can reduce the possibility of catastrophic failure—as well as reducing the possibility of an astounding breakthrough.
And, yes, if you’re working at a place like this, and you love writing great code, and want to be treated well for writing great code, then it’s probably time to send your resume a few places. I talked about this at RubyConf in my Conversations vs. Laws talk, btw.
One last issue is of culture. Even if you can deliver highly iterative, high-quality code, your enterprise clients might not be able to think iteratively. And let’s be fair: Agile can be tough for a client to get used to. It’s genuinely hard to think about small iterations in terms of interaction design, or organizational workflow, and it can involve a lot of careful planning. More than once I’ve found myself saying things like “they’ve got the old steps 1 through 5 already, this week we’ll be deploying the new step 1 which flows into the old step 2, make sure to let these ten people know that as of Tuesday morning those screens will look different.” Getting these transitional steps right, and communicating to everybody who needs to know, and getting feedback from everyone involved, can be time-consuming.
But it can be done, at least within limits. One funny issue I’ve seen is of credibility and iterations. I worked for a client that was used to seeing new code every few months or so. So you can tell someone like that, “hey we’re the new guys and we’re awesome, we’re going to do a release every week”, and they might smile and say they’re looking forward to it, but they probably don’t believe you deep down inside. They’ve been lied to before.
So this makes weekly iterations actually harder, because a big part of small iterations is having the freedom to say that a given feature isn’t ready, but if they don’t believe there’s another release coming soon, they’ll want to hold up this release for that feature. They want to pile everything on this train that’s about to leave the station, because who knows when another train’s coming?
In the case of this client we actually reduced iterations to every three weeks at first, waited to see if they were comfortable, and then reduced to two weeks, then down to one week. We augmented this with feature development branches and alternate deployments. Over time they got completely hooked on it.