Agile is far from being a purely hype-driven software development phenomenon. In fact, if you think about it, it’s a very natural methodology to embrace for technology vendors.
First, a company that develops its own high-tech product—hardware and software—has to deal with constantly changing requirements. You get new clients (especially new key clients at the dawn of the new product development), and they bring new requirements. You hit the market with a new version, and you get feedback that affects your roadmap. You start developing something only to be met with unforeseen technical obstacles or come up with a new inventive approach that simplifies everything but affects the way your project looks and feels. In short, you never know how your requirements will change in three months from any point in its lifecycle.
Second, by definition, it is hard to make reliable time/effort estimates for new development. Since it’s new, your previous experience and statistics work only to a certain extent. Besides, we always try to utilize the best possible technology (note: I didn’t say the newest or the most buzzed about—there’s nothing wrong with looking for the best tech for the job) available at the time we start a new project, be it a new product, a new major version, or a port to a new platform. With that come regular technology changes, accompanied by the learning curve (or, more appropriately, the mastering curve) trial-and-error periods. So your initial estimates are never on the mark, and you have to work on improving them through the entire project.
And third, even before the well-known “Individuals and interactions over processes and tools” and “Working software over comprehensive documentation” principles of agile were formulated, software development was all about individuals. However you tried, the documentation was never complete or up-to-date, and for the best results, you had to regularly consult with product gurus who’d worked with the software for years and knew all the architectural gotchas and recent changes to the design.
Combined, all that leads to agile being a natural approach for new software development, at least in my opinion. Now, let’s throw in the second popular concept in today’s high-tech/IT world (although it’s not limited to this): outsourcing (parts of) product development to (offshore) providers. Given the inherent “constantly changing requirements” + “no good estimates” + “dependency of individual” characteristics of software development, I guess you wouldn’t be surprised that my own principle for successful outsourcing in this field reads as “Communications over technical skills.” One of my first posts this year was on this exact topic—the importance of communications for software development outsourcing—and I hope you now see another reason why it is so important.
But besides the general philosophical interrelation between communications, flexibility, agile methodologies, and specifics of software development, there is a more practical question: how to combine using agile methodologies with working together with remote teams provided by outsourcing companies. There are two main aspects to that question: finding the right business model and organizing the work of a distributed agile team. I break the rest of this article into two posts devoted to these two aspects:
