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.