1 Page
Agile Adoption : The Importance ofDemonstrated Business ValueNidhi Arora   – Senior Manager, Cairn India Limited
Contents1. Abstract .........................................................................................................
1. AbstractOrganisations where Waterfall is the standard project management practice, find challenges inadoption of Agile ...
3. Literature ReviewNumerous studies have been made on the actual impact of adopting Agile for a specific situation. It is...
The company was listed on the Bombay Stock Exchange in January 2007 and is the fourth-largest oiland gas company in India ...
3. List all constraints upfront and their management strategy.    4. Prepare a project plan.Table 1: Key Result AreasKey R...
Skill Level of the team             The Team decided to put in extra hours to learn the                                   ...
Figure 1: Agiles Inverted Pyramid1The delivery phases were drawn up after discussion with the business team.6. Change Mana...
7. Importance of Demonstrated and Delivered BusinessValue for AdoptionIt was critical to deliver business value as early a...
3. Team members also anticipated developments that will be required by the business in       Phases 2 and 3 of the project...
Day 12:Product released. Phase I and Phase II released together.Including the timelines for Phase II, the time impact is 8...
4. Volunteering, and not assignment of work, was made part of team culture. This changesignificantly increased team owners...
This ensured that the team felt that they were in familiar territory, and were not intimidated by the useof Agile specific...
6. Witold Pedrycz , Barbara Russo , Giancarlo Succi, A model of job satisfaction for      collaborative development proces...
Upcoming SlideShare
Loading in …5
×

ETCA_3

742 views

Published on

Published in: Business
  • Be the first to comment

  • Be the first to like this

ETCA_3

  1. 1. 1 Page
  2. 2. Agile Adoption : The Importance ofDemonstrated Business ValueNidhi Arora – Senior Manager, Cairn India Limited
  3. 3. Contents1. Abstract ........................................................................................................................................... 42. Introduction ..................................................................................................................................... 43. Literature Review ........................................................................................................................... 54. Need for Agile ................................................................................................................................. 55. Approach and Conscious Adoption Strategy ............................................................................. 66. Change Management .................................................................................................................... 97. Importance of Demonstrated and Delivered Business Value for Adoption ......................... 108. Impact of personal ownership .................................................................................................... 109. Project Delivery and Outcomes ................................................................................................. 1110. Further Adoption of Agile .......................................................................................................... 1211. Conclusion – Lessons Learnt and Roadmap ........................................................................ 1312. References ................................................................................................................................. 1413. Author’s Profile: .......................................................................................................................... 153 Page
  4. 4. 1. AbstractOrganisations where Waterfall is the standard project management practice, find challenges inadoption of Agile – Hybrid or otherwise. In this paper, we take the case of one such organisationwhere Agile practices were adopted in a business critical project with strict timeline. In particular, wediscuss :(a) how demonstrated (and delivered) business value aids acceptance of Agile Practices,(b) the impact of Continuous Collaboration on project timelines,(c) the short learning curve of the project team in moving from Waterfall to Agile method of project management,(d) the importance of personal ownership in ensuring project success and(e) the importance of “Retrospectives” in collating and internalizing lessons learnt on the project.We conclude with lessons learnt from this case study on adoption of Agile in waterfalloriented organisations, and a roadmap for Agile to be gradually adopted by more stakeholders with in the organisation.2. IntroductionIn popular perception, Agile is the opposite end of an imaginary spectrum where the other extreme ispopulated by the Waterfall methodology. However, most practitioners would agree that in fact, theopposite is true. Effective Waterfall needs to incorporate some agility and Agile can learn from thestructures of Waterfall.This paper is not about the Waterfall versus Agile debate. This paper delves into the importance ofdemonstrated and delivered business value in Agile adoption.In the case study that this paper presents, the organisation was faced with a critical businessrequirement which necessitated a conscious decision to use Agile to deliver business value in theshortest possible time.The paper analyses the variables that positively impacted the adoption, the management ofstakeholders, and their steep learning curve in the constrained timelines. The situation in the casestudy, had adopted certain innovative practices which would be significantly valuable in other similarsituations.The paper therefore summarizes learning from the case study that can be effectively applied in otherrelevant situations.4 Page
  5. 5. 3. Literature ReviewNumerous studies have been made on the actual impact of adopting Agile for a specific situation. It isclear from the studies that Agile is a flexible framework that involves adoption of innovativetechniques in each situation to actually make it a success.Layman, Williams and Cunnigham [1] have documented a longitudinal case study evaluating theeffects of adopting the Extreme Programming (XP) methodology that was performed at Sabre AirlineSolutions¿. The Sabre team was a characteristically agile team in that they had no need to scale orre-scope XP for their project parameters and organizational environment. The case study comparestwo releases of the same product. One release was completed just prior to the teams adoption of theXP methodology, and the other was completed after approximately two years of XP use.Comparisons of the new release project results to the old release project results show a 50%increase in productivity, a 65% improvement in pre-release quality, and a 35% improvement in post-release quality. These findings suggest that, over time, adopting the XP process can result inincreased productivity and quality.However, it is obvious from the studies that what is needed is the right process for each context whichcan be rigorously verified with objective evidence. Armbrust and Rombach [3] delve into these issuesand come out with contextually relevant processes.There have been other empirical studies done on the impact of Agile and learnings from theinnovative practices adopted to make Agile a success in various situations. Some of the relevantstudies are by Sfetsos, Angelis and Stamelos [4], Peterson and Wohllin [5], Fogelstrom, Gorschek,Svahnberg and Olsson [6], Pedrycz, Russo and Succi [7] and Misra, Kumar and Kumar [8].Kahkonen [9] also explores Agile development practices that respect tacit knowledge, makecommunication more effective, and thus foster the knowledge creation process. He studies three agilemethods developed at Nokia that use facilitated workshops to solve multi-team issues. The paperexplores methods that work in multi-team settings. The paper finds that workshop practices thatamass people from different parts of organizations to perform a specific well-defined task can be usedeffectively to solve issues that span over multiple teams and to build up Communities of Practice.The case study presented in this paper also explores the effectiveness of such communities ofpractice for the success of Agile.This paper adds to this body of knowledge by identifying the innovative methods adopted to makeAgile a success in a situation where, given the business pressures, there was little possibility ofadopting traditional methods such as Waterfall.4. Need for AgileCairn Energy India Limited is an Oil Exploration firm. Cairn operates the largest producing oil field inthe Indian private sector and has pioneered the use of cutting-edge technology to extend productionlife. Today, Cairn India has a world-class resource base, with interests in nine oil and gas blocks inIndia and one in Sri Lanka.5 Page
  6. 6. The company was listed on the Bombay Stock Exchange in January 2007 and is the fourth-largest oiland gas company in India with a market capitalization of more than US$12 billion. In 2011, Cairn Indiabecame part of the Vedanta Group, a globally diversified natural resources group with interests inaluminum, copper, zinc, lead, silver, and iron ore markets.Cairn conducts periodic employee satisfaction surveys. In the survey conducted in the precedingyear, employees clearly indicated a strong preference for a revision of the appraisal process.Accordingly, the organisation decided to devise a new and revamped appraisal form and process.Cairn Energy therefore took the help of HR Leadership, external consultants and the top managementto revamp the appraisal form and process. In the revamp process, the top management of theorganisation was proactively involved. This was an unambiguous demonstration of the importance ofthis revamp.The downside of this exhaustive process was that the final appraisal form and workflow was availableto the development team just 17 calendar days before the annual appraisal was to go live for allemployees. The business team proactively reduced their integration testing requirement to just 3 daysfor end to end testing, training and rollout.(The normal time taken for this activity is 15 days). Thatgave the delivery team 14 calendar days.The new process involved development and fresh configuration. Since this was annual appraisal,significant data migration was also needed from the old template to the new template.A project of this magnitude typically takes about 2 calendar months with a complete techno-functional team.The problem was compounded by the fact that the consulting team had never worked on theperformance management module.From experience, the Project Management team also understood that the design of a solution is verydifferent from its visualization. This implies that on realization, the customer is likely to insist uponsome visual and design element changes. It was surmised that these last minute changes wereinevitable and no one could predict their magnitude.On the morning of March 29, 2012, the project faced the following challenges: 1. Team with no prior experience on the performance management module. 2. 14 calendar days to deliver a project that typically takes about 2 months. 3. Data migration as an additional challenge. 4. Anticipated, but inestimable last minute changes.5. Approach and Conscious Adoption StrategyAt this stage, the project management team considered the best possible way to manage the project.The team adopted the following steps: 1. List all Key Result Areas – critical deliverables that define the success of the project. 2. List risks expressly and manage them proactively.6 Page
  7. 7. 3. List all constraints upfront and their management strategy. 4. Prepare a project plan.Table 1: Key Result AreasKey Result Area Solution/ Management Strategy Success Best Criteria Considered SolutionQuick Turnaround Need Based Documentation to On time AgileTime – Hard Coded ensure optimal use of time during DeliveryRelease Date delivery. Test Driven Development to ensure optimal documentation and crisp requirements. Continuous Interaction with the business team to ensure that the visualization and functionality is tested immediately, to eliminate rework.Delivery of a usable Phased Delivery – Prioritisation Successful Agileproduct of Features and delivering in Delivery of phases on need basis. working softwareData Migration The technical team took the Complete and Agile ownership and automated 2 out of 3 Accurate Data migration items. Migration The business team took the responsibility of migrating the third – and the largest item.Table 2: Risk ManagementRisk Solution/ Management Strategy Best Considered SolutionQuick Turnaround Time – We have to consistently keep delivering modules as AgileHard Coded Release Date they are ready so that at any time, at least a basic level of the product can be deployed.Anticipated, but inestimable Ongoing daily interaction with the business and Agilelast minute changes. review team to ensure immediate changes and NO REWORK.7 Page
  8. 8. Skill Level of the team The Team decided to put in extra hours to learn the product configuration quickly. In addition, the team was linked to a configuration expert (external) who agreed to help on need basis.Lack of Availability of team The team already works on “Shadow” concept where Agilemembers due to unforeseen every team member is shadowed by another teamcircumstances member. This approach will continue during the project. Idea Courtesy : Pair Programming in Agile. The team modified the idea and used it for business continuity.Unforeseen Circumstances March End – April 13 is a relatively quiet time. For unforeseen risks, remote working was enabled for the entire team so that they can work from home if required.Table 3: Constraint ManagementConstraint Solution/ Management Strategy Best Considered SolutionQuick Turnaround Time – Already managed in KRA table. AgileHard Coded Release DateTeam’s Skill Level Already managed in the Risk table. The team will upskill itself and help each other. An expert is available on need basis.Based on the above analysis, the following conclusions were arrived at: Time and Cost are fixed. Scope is largely fixed, but we will phase delivery on need basis, so that the project backlog is delivered to the client just-in-time – just as the client needs it.8 Page
  9. 9. Figure 1: Agiles Inverted Pyramid1The delivery phases were drawn up after discussion with the business team.6. Change ManagementThe project management knew, at this time, that Agile was the only way this project could bedelivered.However, the organisation and the team had always worked on the waterfall model. The team wouldstill insist on “Complete” requirements before starting development and business would expect aformal testing schedule.In addition, there was no time to train the team or the other stakeholders on Agile. There was also notime for Change Management.To sum up, the change management challenges were as under. 1. No awareness of agile 2. Resistance to change 3. No time for change managementThe strategy adopted by project management was to not use the term “Agile” or any other Agilespecific terms during the delivery. Instead, the team would be guided towards Agile inspiredbehavior using neutral or familiar terms.1 Image reference: tusharsomaiya.com9 Page
  10. 10. 7. Importance of Demonstrated and Delivered BusinessValue for AdoptionIt was critical to deliver business value as early as possible in the project. The importance of thedelivery had to be clearly demonstrated.To effect this, the following steps were taken:ActionA daily morning meeting with the business where the business can see, every single day, theprogress of the previous day in terms of delivered software components. This was a modified versionof the daily stand up meeting in Scrum. Here, business and the development team were both allowedto discuss progress.ImpactThis daily intervention allowed business to provide continual feedback. The continual feedbackallowed the development team to do course correction at the earliest possible opportunity.In this way, the team mitigated the risk of anticipated, but inestimable last minute changes.The second impact of this practice was that the confidence of the business team in the ability of theteam to deliver the product as expected, grew with every passing day.ActionOn a daily basis, the project progress was tracked against specific tasks.ImpactThe team could, therefore, conclude that from Day 3 of the project, they were consistently beatingtimelines on tasks.By day 7, the team was reasonably certain that the timeline of 14 calendar days can be bettered.Since the progress was being shared with the business on a daily basis, the business teamanticipated early in the project cycle that they will have to be ready for end to end cycle testing atleast 2 days before the planned date. 8. Impact of personal ownershipThe team members volunteered for their task and took complete ownership of the project.This had the following specific results: 1. Team members improved the functional specifications based on their experience of user behavior. 2. Team members automated 2 out of 3 data migration tasks. This reduced the data migration load by about 40%. This development was not part of the project plan. Yet, the team completed this development after discussion with the business team and delivered them by Day 8 of the project.10 Page
  11. 11. 3. Team members also anticipated developments that will be required by the business in Phases 2 and 3 of the project. 4. The physical absence of the project management team did not impact delivery.9. Project Delivery and OutcomesProject DeliveryThis section is divided into milestones that were accomplished throughout the project. This illustratesdemonstrated and delivered business value.Day 3 of the project:The Technical Consultant delivered the development object needed to automate one of the threeData Migration Items. This was not in the project plan. The technical consultant envisaged thedevelopment, completed and delivered it.Impact: 40 man hours saved.Day 6 of the project:Technical Development scheduled for Phase 2 completed.Task Timeline Impact: Delivered On Day 6 instead of Day 19 of the project.Day 8:Data Migration automated for the second data migration object. This was not in the project plan. Thetechnical consultant envisaged the development, completed and delivered it.Impact: 20 man hours saved.Day 8:The final configured appraisal template released for first end to end test.Impact: This template was released for testing 6 days ahead of schedule in a 14 day project. That isa time saving of 40% on a zero buffer project plan.Day 11:Final round of end to end integration testing completed. Visualisation changes taken from Day 9onwards incorporated. Some final changes accepted for delivery.Iterative end to end testing was not envisaged in the original project plan. The original plancould accommodate only one round of integration testing before release. Iterative testing was madepossible only because of the commitment of the team.11 Page
  12. 12. Day 12:Product released. Phase I and Phase II released together.Including the timelines for Phase II, the time impact is 8 days on a 20 calendar days project. That is atime saving of 40%8.2 OutcomesThis was a landmark internal project.The success of the project was highlighted by the following specific measurable outcomes: 40% time saving (as mentioned above). Zero Escalations after Go Live – The popular perception was that an IT project of this magnitude islikely to see a few post go live escalations with some key features malfunctioning. The performance ofthis application was a pathbreaking experience for business and for the end user.The business impact of this success was: Appreciation by HR Leadership Team at the highest levels – Categorical acknowledgement of thedelivery team’s contribution to the success of the HR organisation. Turning point in inter departmental relations. This project was the harbinger of that change.10. Further Adoption of AgileAfter the successful completion of the project, there was significant interest in the organisation tounderstand how this delivery had been effected.The customer, in particular, wanted to institutionalize some of the practices of this project. The projectteam and the business worked together to effect this.The project management team took this opportunity to further the cause of Agile adoption within theorganisation.The following steps were taken:1. Awareness within the organisation on Agile through Knowledge sessions to project managers.2. Knowledge sessions to the delivery team to enable them to understand the factors that allowedthem to deliver.3. Gradually, Agile practices were adopted as part of normal organizational processes.Retrospectives were made part of process for all projects delivered by the team. The positive impactof this change was visible almost immediately: a. Enhanced communication between business and delivery team. Retrospectives after every project enabled both teams to understand each other’s perspectives, constraints and preferences better. b. Frequent 2 way feedback enabled delivery to improve the delivery mechanism and in project communication. It also enabled the business to improve the requirements communication.12 Page
  13. 13. 4. Volunteering, and not assignment of work, was made part of team culture. This changesignificantly increased team ownership of projects.5. The concept of pair programming was modified to a consulting / configuration set up byintroducing the concept of “shadow” – where consultants work in a pair and assist each other onevery assignment. All tasks had to be shadowed. This enabled the team members to mandatorilyseek a peer review for their proposed solutions. Gradually, the quality of delivery has improved.11. Conclusion – Lessons Learnt and RoadmapAgile adoption in traditional waterfall driven organisations may be a function of business necessity orproactive adoption of change.We conclude with lessons learnt from the case study, and listing the steps that might aid otherorganisations seeking to embark on the change journey: Determine the desired level of changeIt is important for an organisation to determine, consciously, the level of Agile adoption that is beingtargeted. If the objective is clear, it becomes easier to adopt the right practices and select the rightactions for change management. Practices are means to an end. If the end is clear, the selection ofmeans is much more effective. Action before PreceptIn this inverted model of change management, the team was not provided any briefing on Agile or itsmethods. They were simply guided in the direction of action. When the team saw that they had beenable to deliver at a significantly higher level than their norm, their interest in learning what hadenabled them to complete that delivery was high.The interest in the precept of Agile was guaranteed by the action of Agile and its results.This might be a good model for other similar situations to attempt. Demonstrated Business ValueAs this paper has already illustrated, demonstrated business value aided adoption across levels,departments and teams. Agile TerminologyAnother adoption lesson that stands out from the case study is that the use of Agile terminology wascompletely avoided during the first phase of adoption. Even the term “Retrospectives” was graduallyintroduced after the team had started using Retrospectives as a practice. Instead, neutral or familiarterms like “Project Plan” , “Project Review Meeting” et al were used.13 Page
  14. 14. This ensured that the team felt that they were in familiar territory, and were not intimidated by the useof Agile specific terminology, which might have been alien to them. Gradual AdoptionLike all change management, change to Agile should be gradual, giving people time to adapt to smallsteps, preferably one at a time. Where small changes based on the principles of Agile are internalizedby users, we find that adoption of the subsequent practices is significantly easier.Based on the lessons learnt in the case study, we are able to propose a brief roadmap for Agileadoption.Figure 2: Proposed RoadmapWe believe that it is possible to replicate the successful adoption of Agile demonstrated in this casestudy, in other industries and geographies, so long as the common factors and lessons learnt arediligently applied.12. References 1. Lucas Layman, L. Williams and L. Cunnigham, Exploring Extreme Programming in Context: An Industrial Case Study in Proceedings of the Agile Development Conference, ADC’04, pages 32-41, 2004 2. Ove Armbrust , Dieter Rombach, The right process for each context: objective evidence needed, Proceedings of the 2011 International Conference on on Software and Systems Process, May 21-22, 2011, Waikiki, Honolulu, HI, USA 3. Panagiotis Sfetsos , Lefteris Angelis , Ioannis Stamelos, Investigating the extreme programming system-An empirical study, Empirical Software Engineering, v.11 n.2, p.269- 301, June 2006 4. Kai Petersen , Claes Wohlin, The effect of moving from a plan-driven to an incremental software development approach with agile practices, Empirical Software Engineering, v.15 n.6, p.654-693, December 2010 5. Nina Dzamashvili Fogelström , Tony Gorschek , Mikael Svahnberg , Peo Olsson, The impact of agile principles on market-driven software product development, Journal of Software Maintenance and Evolution: Research and Practice, v.22 n.1, p.53-80, January 201014 Page
  15. 15. 6. Witold Pedrycz , Barbara Russo , Giancarlo Succi, A model of job satisfaction for collaborative development processes, Journal of Systems and Software, v.84 n.5, p.739-752, May, 2011 7. Subhas Chandra Misra , Vinod Kumar , Uma Kumar, Identifying some important success factors in adopting agile software development practices, Journal of Systems and Software, v.82 n.11, p.1869-1890, November, 2009 8. Tuoma Kahkonen, Agile methods for large organizations – Building communities of practice, in Proceedings of the Agile Development Conference, p. 2 – 11, 200413. Author’s Profile: Nidhi Arora is Senior Manager, Program Office with Cairn Energy India. She graduated from IIM Calcutta in 2001, with majors in Behavioral sciences and Human Resources. She is a certified PMP, PMI-ACP. Her functional certifications include SAP HCM and SAP Solution Manager. She runs a social initiative – Esha (www.braillecards.org and www.clabil.org) in addition to her work with Cairn.15 Page

×