Offshore Management Framework: The key to managing outsourced IT projects across time, distance and cultures.

« March 2007 | Main | May 2007 »

April 9, 2007

Defining Agile strategy: Case in point

I was working with a client (shall go unnamed) recently, helping the IT Director define a strategy and roadmap that his (and our) team could take forward. His vision and mandate was crisp and refreshing. Having recently taken over a portfolio of applications, he was looking to make incremental changes to the underlying systems, architecture and framework components in an ˜agile” fashion. This was the tactical part. His strategy was to get business sponsor the ‘low hanging fruit’ (more functionality) while he would also overhaul the underlying architecture.

Given this scenario, consultants would typically take a boilerplate and start calling out the ˜steps” [a.k.a. a typical IT strategy /roadmap definition exercise]:

  • Analyze Current State: What does the application portfolio look like? (business functionality, technology landscape, SLAs etc etc)
  • Define End-State: Would the portfolio look like (after the re-architecture)
  • Define the steps to take, processes to follow etc

And herein lay the challenge: we have discussed agile development paradigm, and even agile development using global teams. [Further to my earlier blog, CIO magazine also ran an interesting feature: ABC: An Introduction to Agile Programming] However, the question that came up: we all talk about agile programming/development: What about defining and executing an “agile strategy”? Which is what Mr. Director was working towards.

The ˜agile” challenge here, was that Mr. Director, who himself was highly technical, had mapped out the end-state at a “20 thousand foot” level and was willing to proceed with the steps to get there, betting that with a ˜few mistakes” along the way, one would get there.
What made this engagement interesting?
a) The need to call out the “steps” that would lead to the end state at least at a high level
b) Need to develop and actionizing a plan for quick-win projects that our team to could immediately take forward and execute, while the roadmap [big-picture] was evolving.
c) Change management: buy-in from the globally distributed team (including getting the internal Infosys team on board)

I will blog about this experience further but I would also like to hear from the gurus in the field: how would you approach this scenario?

Subscribe to this blog's feed

Infosys on Twitter