It's week two of our 30-Day Blitz in India and agile concepts are taking hold with the development team. Agility has been a challenge for some team members, and for others, these concepts have come more easily. This is much the same as the experience I’ve had with IT teams in the United States.

Groups of developers in the States have been talking, debating and blogging about agility for several years and I wondered if the relative newness of these ideas and cultural norms here would make it harder for developers in India to embrace these concepts. What I see though, is that it’s unfair to say Indians can’t be agile just as it's unfair to say that white guys can’t dance (being a white guy myself, I’m very sensitive to that particular generalization…).

Here are some of the observations and experiences in the last week that lead me to this conclusion. To begin with, agility requires constraints because without constraints there is simply no need to be agile (that’s why a 30-Day Blitz is 30 days and not 31 days). Agility is a response to an urgent necessity, not just something that people decide to do because it seems like it might be a good idea. And the idea that constraints are necessary to foster agility is, at first, hard for people to accept regardless of what culture they may come from.

In the first two days of intensive interaction between business and technical people there is often an initial can-do attitude in the team and a high level conceptual system design is agreed upon. That then gives way to second thoughts as people move into the design phase and probe deeper into the details of creating a production system from that conceptual design in the short time available. There is some reluctance to commit on the part of the IT development team; negotiating and attempts to cut scope then ensue which is usually resisted by the business people. This happens in the United States all the time so the fact that it happened here in India simply means that this behavior also transcends cultures.

Then, as design details continue to be worked out, a small group of developers on the blitz team go off on their own and starts putting together the hardware and software components that were called for in the conceptual design. As people start to see that these components actually do work as envisioned, and as they realize that they might just be able to deliver on the conceptual design in the time allotted, there is renewed commitment to the project. I’ve seen this often in the States and I saw it in India.

At this point a spirit of commitment and creative problem solving emerges in both the business and the IT people on the blitz team. Where earlier there was reluctance and bargaining, it is replaced by renewed cooperation and exploration of options. Agreement is reached on a system design that everyone feels will give the business people most (if not all) of what they want and at the same time can actually be built in 30 days or less. This is the agile spirit manifesting itself in the blitz team. Again I saw this happen here as it happens in the States.

Agility is a group phenomenon; it depends on the combination of the skills and insights of the whole team, not just a single person or a small subset of the team. And this phenomenon is made

You do not have flash or javascript support.

Average (3 votes)

Reply