There’s a wonderful story told (I believe) in Bruce Catton’s “Never Call Retreat” and other Civil War histories. An ex-slave with the Union armies happens upon his former master, now a prisoner of war toiling away at some task. “Hey, master,” the ex-slave says, “Bottom rail on top this time.”
I was reminded of this story when I reviewed my latest copy of Sloan Management Review. In it, there’s an excellent article by Keith McFarland about his consulting firm’s application of software-development techniques – particularly agile programming – to a company’s process of strategy formulation.
Today’s software development philosophy has in some cases moved from an inflexible “waterfall” process of developing software, often with attendant highly formalized governance, to a “spiral” process emphasizing frequent, flexible, incremental changes narrowing in on a solution, and involving both developers and “end users.” Keith’s insight has been that the same approach can be used to improve other processes, such as strategy formulation and modification. His experience has been that this approach leads to benefits to the company similar to those of agile development to the development organization: faster time-to-value, greater buy-in by users/the company as a whole, and easier, more frequent modification of strategies in response to new opportunities and challenges.
Now, all this sounds like another example of cross-fertilization from one area of the business to another, all part of the current mantra “innovation is great.” But as a long-time programmer and then observer of the business development scene, I can tell you that I can’t recall ever seeing an idea come from development to business strategy. Quite the reverse, in fact.
To put it another way, much of the history of development methodologies and philosophies is one of strained analogies with something else. There was the time in the 1970s when it was assumed that development was something vaguely like writing, and therefore anyone with a background in English or history could do it. More recently, and up to the present day, programmers were supposed to be like engineers, with a cookbook of mathematical kludges to apply to any situation (remember Computer-Aided Software Engineering?). As someone who worked with electrical engineers at my first job, I have always thought this was a pernicious misunderstanding of programming skills, leading to “software and the software process would be simple if they were just engineered properly.” And then there’s “development is like manufacturing,”, leading to Cusumano’s hailing Japanese software factories as the wave of the future and Brad Cox hoping that developers would simply build software like Lego blocks, not to mention the hope that Indian outsourcers with a set of requirements as their supply chain could handle all new-application development tasks.
It is only in the 2000s that we have finally seen some significant flow from software ideas to the rest of the business. In particular, today’s cross-project management tools (folks are realizing) are well ahead of legacy New Product Development and Product Portfolio Management software and techniques, and therefore you can do better if you’re Schlumberger by using PPM to enhance your product development tools. And companies are paying lots more attention to software development, too, because for more and more businesses, from investment banking to gaming to Google, continuing development of competitive-advantage software is key to company success.
But applying agile development to business strategy development is a step further. Agile development, remember, is one of the first “home-grown” development philosophies, done by developers with full appreciation for the drawbacks of previous analogies and aiming to leverage the very characteristics that make the developer unique: mastery of massive amounts of detail, mathematical and creative skills, usefulness of the individual and of self-generated “hacking” (in the old, good sense) as well as rapid prototyping. This is a process that first took off in software development, not anywhere else.
So the real story of this article is that maybe development is beginning to be not a millstone around management’s neck (as in, “why can’t I get the support for the business I need out of IT?”), nor a mysterious cabal within the organization, with its own language and norms, but a pattern of getting things done that can serve as an example elsewhere, or a harbinger of successful organizational practices to come. Why can’t the budgeting/planning/forecasting process be more flexible? How about the event-driven organization, ready to react semi-automatically to certain events on the outside? Could we open-source performance reviews? All right, maybe the last one was a little over the top.
Software development, done right, as a model for the organization! Bottom rail on top this time, indeed.
No comments:
Post a Comment