Off-shoring and Moving from Waterfall to Agile


For quiet some time I have been a proponent of agile methodologies. It has been a fascinating experience trying to persuade people to move from waterfall to agile. Right now the industry is in an overdrive towards adoption of agile methodologies and the doubters are taking a back seat. We seem to be moving towards the peak of inflated expectationand and a bout of disillusionment may be just across the corner. So I will try to stay away from the hype and take a more pragmatic and look at what are the roadblocks for moving from waterfall to agile. It is difficult to distinguish if they are real or perceived. In either case they need to be addressed.

One of the most important points that has to be taken into account is the impact of off-shoring, especially to off-shoring to India. Any large scale agile adoption plan which does not take India into account is obviously doomed for failure. Indian software companies have made heavy investment in SEI-CMM certification and have created internal processes which are primarily based on waterfall methodology. With increasing adoption of agile methodologies across all enterprises, off-shore vendors can not stay away from this issue. Even SEI has released a white paper outlining how both agile and CMM can coexist.

However, at the heart of the problem lies the ETVX model. One of the primary implication of this model is the assumption that software design can not start until requirement is frozen and coding can not start until design is complete. People trained in waterfall methodology have been drilled to think on these lines. Therefore, the necessity to freeze requirement before design and development can start is taken as sacrosanct. Those of us who live in the real world know that requirement can never be frozen. It is especially true now that software has become an integral part of every product or service offering. Keeping aside the requirement change caused by miscommunication and improper understanding, requirement will change because of the sheer market dynamics. That is the basic assumption on which agile methodologies have been designed – that requirements will change.

To resolve this contradiction, not only is it necessary to revamp the documented processes, but also requires a change in mind-set of people. Irrespective of agile experts say, this transition is not going to be easy. Most Indian IT companies perceive this as a risky transition. If the project management is handled completely by the customer and the project is done in a time and material basis then implementing agile practice is perceived as less risky option. The real challenge for an offshore vendor is to manage the projects governed by fixed price and follow agile methodology. Today it is perceived as high risk strategy and it is generally avoided. Many questions and doubts are raise which will require an answer. Here is a set which I have compiled for which I do not have very clear answer or explanation. The questions and doubts are grouped from the perspective of different stakeholders.

From the perspective of the business head of the of the organization handling the off-shoring

  • How do you determine project completion? Requirements can be ever changing!
  • How do you handle scope creep? It is like handing over a blank cheque!
  • How do you manage the impact of attrition? With no mechanism of formal documentation the knowledge will just be lost!
  • When there is a dispute, how do you establish who is right? We should not remove the term called traceability from dictionary!

From the perspective of the project manager

  • How do you handle the problem of geographically distributed team? Stand-up meeting … time zone … face to face!
  • How to induct new member into the team midway through the project? This may be more problematic than team member leaving!
  • How do you do the release testing? There may be a large audience … even one bug may be costly!

From the perspective of the architect / designer

  • How and when do you design? Expert say that agile does not advocate that “you do not need design”, but it is not clear how design will happen!
  • What will be the role of an architect? Maybe there are not needed!
  • How does specialist role dovetailed into the project? It may have to happen informally!

From the perspective of the process owner

  • How to audit an agile project? Documented evidence and primarily oral communication do not go hand in hand!
  • How is backlog list different from task breakdown? To the non-initiated, they look suspiciously similar!
  • How is traceability needs addressed? Maybe you cannot audit and agile project!

Do you have answers to any of these questions? Have I overlooked anything relevant? Feel free to express your opinion and add a comment.

Udayan Banerjee on Google+

Related Posts

About these ads
Comments
13 Responses to “Off-shoring and Moving from Waterfall to Agile”
  1. Andy Dent says:

    I agree with you about the danger of insufficient documentation. The Agile Manifesto does NOT say “no documentation” but too many cowboy teams choose to interpret it that way.

    I developed my Diary-Driven Development approach about fifteen years ago to capture the essential aspects of design thinking, for solo developers and small teams.

    Adittya, thanks very much for the link to A List Apart – I was particularly impressed by their point “Lack of coherent vision is a common weakness of Agile projects” and the reasons behind it, which resonate with my experience.

  2. Tador says:

    Well written, but I believe your mixing metaphors, the fundamental value of Agile is the ability to put the right people together in a common environment and drive down the requirements through the burn down process, this is about delivering value at an accelerated pace without losing quality.

    You appear to be wrapped around the economics of off shoring and fixed versus variable price. Let’s assume for a minute that there was not a labor rate difference between domestic and offshore development, the real key is how to you create a virtual team that works with the business people on the team in their time frame (and time zone), that understands their business needs, and drive out real business value from a prioritized requirements list in a very short amount of time. When you figure that out then you can think about the economics.

    Right now Agile or XP delivers an 8 fold improvement from traditional SEI/CMM methods of development (documented) in term of product and cost. No amount of labor rate variance is going to make up this difference.

    • Udayan Banerjee says:

      I have no disagreement with you.

      However, I look at things “From the other side”. If you keep that point in mind …

  3. Mike says:

    Thanks for this useful entry and for your comment on my Linkedin Discussion.

  4. Good Questions. Most of the good books on Agile has answers to these. I agree that Agile is a paradigm shift from traditional thinking on Software Engineering. But hopefully over time clients will understand the benefits and start adopting Agile. As clients start adopting Agile the expectations from the Software Vendors should change accordingly.

    No more hiding behind processes and documentations! Agile will bring a change in traditional roles and responsibilities.

  5. Mahadevan says:

    Hope you would have gone through,

    http://agilemanifesto.org

    Some of your points are addressed by the statement in this manifesto, may not be direct.
    like
    1.”Working software over comprehensive documentation”.
    So with short delivery cycles,some documnetation and a working software, there should not be a problem for
    “How do you manage the impact of attrition? With no mechanism of formal documentation the knowledge will just be lost!”
    2.When there is a dispute, how do you establish who is right? We should not remove the term called traceability from dictionary!
    “Customer collaboration over contract negotiation”

    I think this is is addressing the risk at the source.

    Though the Customer and the Vendor should understand what Agile is- Which is what is going to be tough?

  6. Aditya says:

    A List Apart has published an interesting post on Agile development: http://www.alistapart.com/articles/gettingrealaboutagiledesign

Trackbacks
Check out what others are saying...
  1. [...] Off-shoring and Moving from Waterfall to Agile Share this:LinkedInTwitterFacebookStumbleUponPinterestEmailLike this:LikeBe the first to like this. [...]

  2. [...] Off-shoring and Moving from Waterfall to Agile [...]

  3. [...] Off-shoring and Moving from Waterfall to Agile Share this:LinkedInTwitterFacebookStumbleUponPinterestEmailLike this:LikeBe the first to like this. [...]

  4. [...] Off-shoring and Moving from Waterfall to Agile Share this:LinkedInTwitterFacebookStumbleUponPinterestEmailLike this:LikeBe the first to like this. [...]

  5. [...] 10. Off-Shoring and Moving From Waterfall to Agile [...]



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 996 other followers

%d bloggers like this: