Everybody wants to be Agile these days. And what’s the alternative? Being hidebound? Unresponsive? Inflexible? On Synonym.com they even list “stupid” as an antonym of “agile”. All of the opposites of “Agile” sure sound like words I don’t want associated with my software development process Agil
.
When I first heard about Agile software development, it didn’t sound all that revolutionary to me. While you still find pockets of waterfall software development processes out there, I think most forward-looking people recognized a few years ago that waterfall processes exhibit a poor reaction time to market feedback, and that these processes have a fundamental assumption that is demonstrably false: that you can know with certainty the requirements for a project at the very start, and that those requirements won’t change over time.
Most of the techniques used in Agile development have been gaining ground for the past several years–incremental development based on a backlog of requirements, doing frequent releases of a web software product, being hard-nosed about the scope of a release since there is always another release coming soon afterwards (so new requirements can be accommodated then), and, crucially, trying to better connect developers with “the business” (for some reason this use of the term “the business” always bothered me, so I feel obligated to put it in quotes. I guess my issue was that it wasn’t always obvious who “the business” was, and I often wondered why the business wouldn’t answer the phone and give me answers on how to prioritize projects. It reminds me of Henry Kissinger’s quote about Europe: “Who do I call if I want to speak to Europe?”).
But I have to give the guys who coined the name “Agile” some credit for packaging up some good ideas that had gained currency, and creating a kind of rallying flag that developers, product managers and “the business” could rally around, and say, “we need to be Agile.” So now you have a whole Agile industry: Agile books, Agile training ( Agile Academy has some videos that serve as a nice intro to the Agile concepts), Scrum Master certification courses, and job descriptions that say candidates need Agile experience. And of course there are Agile conferences and all of the associated conference schwag ( check out AgileEE in Kiev! ).
In the offshore development world, it seems that Agile has really caught on. I had a chance to visit some South American offshore software development companies recently, and the CEO of one service provider really nailed what’s driving this. He said that “wherever possible, we’ve moved to an Agile process with our clients. This is how young people want to work these days and using Agile allows us to attract developers.” So he wasn’t merely listening to his customers, who wanted to use an Agile process. He was pushing an Agile process on his customers because his developers wanted to work that way. Developers don’t like working on features that don’t get used, and it drives them crazy working on a large project that’s completely off the mark due to poor initial requirements definition. So an Agile process offers developers some hope that their hard work will actually hit the mark.
Using an Agile process with your offshore software developers requires a few adjustments. You can’t do an in-person scrum meeting each day, of course. But Skype or teleconferences can be used. While I’m not of the view that each and every offshore developer needs to speak perfect English, your team leads will need to speak good English to allow this daily communication between the various project team members. One tenet of Agile that isn’t always followed religiously when using offshore development is holding a demo for the business at the end of a sprint. When I asked my various Agile hosts in South America whether they really got the business to watch such a demo, the answer was often “no, but we do the demo anyway, for ourselves,” and sometimes for a Product Manager located onshore who acts as a proxy for the business. So connecting with the business is still the weak link in these processes, and it’s even more challenging when you are using an Agile process offshore.