Adopting Agile Methodology in a Large Scale Distributed Development Environment
Much has been written about the exhilarating benefits that Agile methodologies bring to an organization. The latest trends and industry studies too show a steady rise in the adoption of Agile methodologies. Organizations across the globe, irrespective of their size and business, have started dabbling with this new methodology; some embracing it openly while the others adopting a little more cautious approach.
However, even after showing a considerable promise, Agile is still considered the second class citizen in the world of IT processes, which is dominated by the likes of CMMI®, ITIL®, and RUP . What is it that is limiting a wholesome Agile adoption? Why do most organizations still hold on to the procedural methodologies as their core processes? Industry studies have cited various reasons; the most prominent being the non scalability of Agile for large and distributed projects.
So does this mean that Agile is incompatible with large and global distributed development – or is it just our perspective of Agile that creates these potential roadblocks? This white paper talks about some of the author’s practical experiences as a senior Agile Consultant in TCS, including the key challenges of adopting Agile in organizations running large and distributed projects, and the approach recommended to overcome these challenges to achieve a successful Agile adoption and deployment
Introduction
The Rise and Rise of Agile
It’s official. Agile is now a global phenomenon and is rapidly becoming organizations’ most preferred IT process around the world. As a part of the process consulting group in Tata Consultancy Services (TCS), Asia’s leading IT Company working with a diverse customer base from start-up companies to fortune 500 ones, we are seeing the demand changing. Large enterprises which had been a staunch follower of plan driven methodologies have started to add an Agile playbook (or cookbook or handbook) into their organizational process library. The bolder ones have already announced their plans of going agile while the other more cautious ones have started deploying them internally in pockets.
The adoption has been further fuelled by setting in of the recent recession where suddenly, no one is sure of how the business landscape will change in the next few months. Delivering software a year down the line is no more an option; funding that are committed to an important project today, is being cancelled six months down the line. There is a sudden need for projects to add as much value as possible in the shortest time span, and who else but Agile can be the knight in shining armor during the troubled times.
Adoption Challenges
Although adoption of Agile is in full swing, unfortunately the same cannot be said about its ‘organizational success’ - and before I feel the pangs of the acerbic criticism from the ever growing Agile community, let me quickly define as to what I mean by ‘success’ of a process from an organizational perspective. Within the consulting dimension, we know a process is successful when it starts getting adopted at an organizational level and gets followed all the way up to the level of the CEO or MD. So yes, CMMI® is successful since it becomes the de-facto standard for an organization wherever it is deployed; ITIL® is successful since it is the de-facto process for service management wherever it is deployed. Small projects done with Agile will definitely be successful due to the very nature of the process but we are still way behind in getting Agile adopted at an organizational level for large projects. But of course there are exceptions and this paper will talk about some of those exceptions and how they managed to deploy Agile at an organizational level. But right now, let us think of the challenges that are stopping Agile to attain a first citizen status for many organizations.
Size Does Matter
It is no secret. The major challenge of Agile methodology is its scalability. Remember, we are talking about large organizations here with perhaps IT strength of more than a thousand people. There are smaller projects that run within this huge IT team with 8 to 10 people, and these are the pockets where these organizations have tried and succeeded with Agile. However, most of the projects that are built within these IT shops are monstrous. Teams of 200 to 400 people executing projects with highly complex technologies like mainframes at the backend and .Net at the client side coupled together through something like the MQ Series. The skill levels of the team are different, each unit is highly dependent on the other and it takes at least 3 months to build even the first increment of the working software.
Distance Does Not Make the Heart Grow Fonder
If size complexity wasn’t enough, added to that is the mother of all complexity, the ubiquitous “global distributed development” . With parts of project being run out of Los Angeles office, parts of it from Sao Paolo and the rest from Beijing, the vision of using an Agile methodology is the last thing that a CIO would have in her mind. And this is not only about offshoring to an external IT vendor. Multi national companies have development centers at all parts of the globes. Even local firms may have their IT development happening at multiple sites. E.g. a US based firm may have an office in Los Angeles, another in Austin and a third in New York. By far, arguably, the market perception of the biggest roadblock to Agile adoption is distributed development, especially those that have multiple vendors involved. Well, this doesn’t come as a surprise since the very requirements of a distributed development seems to be an antithesis of the Agile manifesto. Consider this:
Agile manifesto says that “Individuals and interactions over processes and tools” . Think of a distributed development. With the individuals sitting virtually on the opposite sites of globes, interaction is the key challenge. Face-to-face interaction on a daily basis is out of question. Mails and forums do work but there is usually a pretty big time lag. With multiple vendors the situation becomes ever more critical since they have their own processes, service level agreements and tools. In such cases if you do not have processes that are well-defined and a state-of-the-art tools landscape, it will be impossible to meet the deadlines with acceptable quality. So the distributed development manifesto would read “Processes and Tools over individuals and interactions” , which is quite the opposite of the Agile spirit.
Similarly, while the Agile manifesto says “Working software over comprehensive documentation” , it is assuming that a single team is responsible for the entire lifecycle from analysis to deployment. In distributed development, often the entire ownership is distributed amongst various vendors and therefore comprehensive documentation becomes the way of life.
The scalability challenge in Agile is not new. The Agile gurus and its most staunch proponents have voiced their concern about going Agile in a distributed model multiple times. They argue that the primary premise of Agile method, which is face to face communication and collaboration, suffers heavy restriction in a multi-site model pulling down the productivity to such an extent that it overshadows the cost benefits received from the distributed environment.
Large sizes and over-complexity of projects are a deterrent even with Agile techniques like Scrum of Scrums. It’s easy to understand 50 people running 5 simultaneous Scrum teams and having a scrum of scrums with 5 scrum masters, but how do you explain 200 people running 20 scrum teams and a scrum of scrum with 20 scrum masters – anarchy?
Download
Download full seminar papers At
http://www.enjineer.com/forum
No comments:
Post a Comment