Is Satyam a passing phase?

The early 80s were full of articles in the trade press on the potential of Indian IT. Their key advantage in the number of engineering and mathematics graduates produced per annum was invariably cited as the propulsion engine to future greatness. The liberalisation of markets and the mantra of globalization in early 90s turned a company like Infosys, a poster-child if Indian IT, from a turnover of $5M in 1990 to $1B in 2004. The expected revenue growth of 30% per annum became the norm in Offshore IT companies. The new confident Indian operations like TCS, Wipro, Infosys etc easily met this heady growth target. There was excitement around everywhere on impending Asian century. China and India were seeing double digit growth in their economy. USA was increasingly becoming a debtor of China and people like Premji , Wipro’s Chairman, pointed towards the skills-shortages in USA market. He pointed out that Wipro is not losing its employees to its Indian competitors in American market but to the local employers who could not meet their skill requirements. People from the IT industry like Bill Gates, Eric Schmidt etc also expressed their concern on shortages of skills and they were joined in this chorus by reputable Harvard academics like Michael Porter, renowned for assessing international competitiveness. The Indian juggernaut was unstoppable. These outsources even boasted of moving up the value chain, having proved their credentials on many projects. Then Satyam happened.

Outsourcing to India’s fourth largest IT company was suppose to provide advantages of speed, agility, flexibility and focus but suddenly it has become the main preoccupation and a major distraction. The retailers like Tesco and Boots and manufacturers like Unilever and Nestle, and not to mention a host of financial institutions, are all concentrating on the finer details of their contracts and building tactical responses to mitigate risk. The Indian government is busy trying to safeguard the reputation of India Inc in the aftermath of Satyam saga, whilst the competitors like Wipro and Infosys are in over-drive to project this fiasco as an isolated event. Satyam’s $2B turnover is 4% share of the $50B market but the perceptual damage vis-à-vis governance standards is very significant indeed. When one compares it to Madoff’s $50B ponzi scheme, the scandal is relatively minor. However, the Indian prime minister has rightly recognised it as a stain on India’s corporate reputation. The confidence of IT outsourcing industry has been dented. It remains to be seen whether all the current nervousness passes eventually with minor adjustments or it proves to be a game-changing event.

Essence of eXtreme Programming

An agile development process like eXtreme Programming is a complete antithesis to the practices of waterfall model. Downplaying the importance of following plans, processes and tools, documentation whilst demanding constant receptivness to customer-induced changes comes as a culture shock. To capture the essence of the eXtreme Programming methodology I look at the four key aspects of requirements, process, architecture and risk from its perspective.

Requirements - Customer written user stories, each around three sentences, substitute formal requirement document and are used for implementation estimate during release planning meeting (Wells,2006). The actual detailed requirement is captured face-to-face with the customer during story implementation but analysis documentation is deemed unnecessary (Bennett et al, 2006,p171). It facilitates dynamically changing requirements.

Process - The adaptive, collaborative, agile and lightweight process is antithesis of traditional lifecycle methodologies (Bennett et al, 2006,p61; Wells,2006). The process is user stories driven, customer-focused, iterative and incremental where feedback is continuous. Fixing a failing process is allowed and encouraged (Sorensen,2001). The teams are small and developers work 40-hours week. Test harness has to be created prior to any coding. The code is owned collectively and all team members can change it (Bennett et al,2006,p619), The developers have to adhere to standards, design simply, have the courage to discard solutions. Constant refactoring to simplify and remove redundancy is absolutely essential. A user is a full-time team member. No specialist roles exist. There is no emphasis on using modeling tools. The code itself is deemed design documentation. Pair programming is the norm.

Architecture -  ‘you aren’t going to need it’ (YAGNI ) characterizes architecture too. Emphasis is on coding fast and relying on refactoring to fix design (Fowler,2004). The notion that we should keep things simple and not implement something till it is needed works against the idea of architecture. XP system metaphor is analogous to architecture (Herbsleb et al,2003 ). The metaphor, an evocative description, helps the team understand how the system hangs together (Herbsleb et al,2003). Simple design is emphasized and there is no upfront design (Stephens,2003). Architectural spikes or prototypes are used for testing design ideas (Sorensen,2002)

Risk - The paired programming, automated testing, continuous integration, accommodation of changing requirements, iterative development, customer involvement, improved communication, constant refactoring, coding standards, spike solutions etc are all geared towards minimizing risk (Brewer,2001;Wells,2006). The whole reason for subverting traditional practices is that XP significantly reduces risk in dynamically changing environment and these practices are at the heart of XP.

References

Bennett S., McRobb S. and Farmer R. (2006) Object-Oriented System Analysis And Design Using UML, Berkshire, McGraw-Hills

Brewer J (2001) Extreme Programming FAQ [online] Available from http://www.jera.com/techinfo/xpfaq.html 

 Fowler M. (2004) Is Design Dead? [online] Available from http://martinfowler.com/articles/designDead.html#id21325 

 Herbsleb J., Root D., and Tomayko J. (2003) The eXtreme Programming (XP) Metaphor and Software Architecture [online] Available from http://reports-archive.adm.cs.cmu.edu/anon/isri/CMU-ISRI-03-103.pdf 

 Sorensen C. F (2001) XP – eXtreme Programming: A Brief Introduction [online] Available from www.idi.ntnu.no/~carlfrs/Presentations/ExtremeProgramming.ppt 

 Stephens M. (2003) The Case Against Extreme Programming [online] Available from http://www.softwarereality.com/lifecycle/xp/safety_net.jsp 

Wells, D. (2006) Extreme Programming: A gentle introduction [online] Available from http://www.extremeprogramming.org/rules/userstories.html