Agile/Scrum Implemented in Large-Scale Distributed Program


Published on

Learn how our client in the insurance industry overcame requirements and analyses hurdles by changing their program to an Agile/Scrum approach.

Published in: Technology

Agile/Scrum Implemented in Large-Scale Distributed Program

  1. 1. • Cognizant 20-20 InsightsAgile/Scrum Implemented inLarge-Scale Distributed Program Executive Summary teams decided to go with four-week sprints as we still had some open requirement clarifications It was early July 2010 when problems were which would need to be solved in the Sprint or detected while running a large program at one of moved out to the support team. The goal was to our clients in the insurance industry. The program resolve all clarifications within the Sprint teams, appeared to be going in circles and was conspicu- as speed was required. ously stuck in requirements and analyses. It was not until late July when it was decided to move the program to an Agile/Scrum approach; the Original Sprint Teams plan was to get the program back on track for a delivery in May 2012. As expected, numerous On-site Offshore questions were raised. Among them: How long Sprint Lead Lead/ Proxy Sprint Lead should the Sprints be? How do we put a backlog Scrum Master together quickly? How do we get the teams to be Business Analyst Business Analyst productive as soon as possible? Do we include testing within the Sprint teams? How do we finish Lead Tester Tester the analyses of the outstanding requirements? UI Architect Service Architect Etc., etc., etc. Not Applicable Five Developers Time was of the essence. Therefore, the immediate Figure 1 focus was placed on productivity rather than trying to answer all questions up front — which During the first retrospective, it became apparent would have not been feasible in the first place. that having the on-site support resources tied Nevertheless, the leadership team in the next two directly to the Sprint team was not working. weeks tried to answer as many of the outstand- These resources were moving across both teams, ing questions as possible before the first Sprint the idea being to help remove blockers and issues kicked off. This white paper describes how we met that the teams were running into. But since the challenge. this was not working these support resources, The Two-Week Planning including the offshore support resources, were moved into a new team called the support team. Upon further discussion, we decided to have two This team spent 50% of its time working for the distributed teams between offshore and on-site. current Sprint and 50% working on the outstand- The Sprints would be four weeks in duration. The cognizant 20-20 insights | december 2011
  2. 2. ing analyses items present at the beginning. This delivery lead were taken from on-site to offshoreproved to be a successful move. for four weeks. There were three parts to the first Sprint; the two Sprint teams minus the architectsSupport Team worked on a very small feature set. This allowed the delivery lead (Agile/Scrum coach) and architects On-site Offshore to train the Sprint teams. Furthermore, it allowed both the architects and business analysts to work Sprint Lead/ Not Applicable the product backlog confirming the user stories Scrum Master were the right size to be completed in one Sprint Business Analyst Business Analyst and that all issues were logged for the support resources to work. UI Architect Service Architect Service Architect UI Architect After the second Sprint, a support team was created and decided that it would need its ownFigure 2 product backlog. Two reasons lead to that decision:Efforts were made to cut down on the idle time togain efficiency. To achieve this, business analysts • The team’s workload would be managed more efficiently and effectively.and architects offshore were put in place tospeed up the program and were placed close to • The Sprint team’s velocity would not bethe Sprint teams performing the work. The goal impacted should the support team’s tasks bewas to resolve 75% to 90% of all team-raised created under the feature in the Sprint team’sissues before the issues came to be on-site. This backlog.approach produced better results and velocity Sprintswith the Sprint teams. During the planning phase, it was decided to goTesting with four-week Sprints, which allowed time toUpon looking at the testing, the following issues complete design, unit testing, user story test casewere carefully reviewed: design and test case execution. What was found in every retrospective for the first six Sprints• What would be required to complete the was that the Sprints seemed to operate as mini application and roll the application out to waterfalls. production? Testing would require everything to be perfect• Could we develop user stories in sequence? in the environment before executing the test > If we could complete the user stories is se- cases. It took a little bit of work and training to quence, we could execute integration test- get testing away from this approach. However, ing during or in the next Sprint. another issue arose. Once completed, develop- ment was not always releasing the feature/userBased on the answers to these issues, we decided story; they had begun to wait until everything wasthat both the unit testing and feature testing ready. Communication became critical to makewould be part of the Sprints. System integra- things work more efficiently in the Sprint. Thistion and user accepted testing would occur when successfully ensured that developers were tellingthe program is completed and will follow the testing when a feature/user story was ready, thusclient’s current process for applications to go into guaranteeing the right focus on test case design.production. ScopingProduct Backlog Two days were allocated at the beginning of eachThe creation of the product backlog became an Sprint for the teams to decide what was in scopeeasy answer, or so we thought, as the program and the reviewing of the earlier estimates. Inwas already in progress and all the work items these two days, the teams reviewed the feature,were broken out into features. We decided to make ensuring there were no issues/blockers thatthese features the work items or user stories for would hold up the Sprint. Should any issues/the Sprint teams. blockers be found, the feature would be markedThe first Sprint kicked off in early August. At that as blocked and a new feature would be placed onmoment the architects, program sponsor and the the support team’s backlog to be worked. Next, the team would break out the feature into tasks cognizant 20-20 insights 2
  3. 3. that needed to be completed during the Sprint No demo was done until we had completed fourand estimate these tasks accordingly. The feature Sprints. This allowed us to get enough substancethen would be allocated to the team and the tasks to the product before showing it to the executivewould be added to rally for tracking. team.Scrum of Scrum The program had such visibility at the executiveDuring Sprints one and two, the team’s stand-up level that requests for demos were pouring inmeeting would include the program’s leadership almost daily. A line had to be drawn on theseon the phone posing three questions to the team requests, as they were having a dramatic impactmembers: on the QA environment — especially given that the integration and production environments• What did you work on yesterday? were not ready yet.• What will you work on today? Next Steps• Do you have any issues/blockers keeping you from completing your work? Planning for day 2 began in late April 2011, addressing some of the big issues that aroseAlthough it was great to hear all the members during day 1. This was the main objective of thisgive their status, this process proved to be very phase. We decided to address three items atineffective. Furthermore, it was costing the team this time: scoping was taking too long for eachvaluable time as the stand-up would go for more Sprint; demos should be done by the developerthan 30 minutes every day. This approach was who coded the feature/user story instead of thesoon changed, after the second Sprint, allowing lead BA; and the retrospective was taking toothe team to hold their stand-up each day without much time and making it hard for us to hear fromleadership present. After the meeting, the Sprint everyone.lead/Scrum master would send out a statusreport outline and current status of the Sprint. Backlog GroomingEach day the leadership would have a Scrum of The implementation of the backlog grooming wasScrum1 meeting where the Sprint leads/Scrum set to fix the scoping issue. The first step was tomasters would review the current status and raise get a product owner — or at least a proxy productany blockers their teams were having. At the end owner — who could efficiently set businessof this meeting, the on-site delivery lead would priorities. Although we were not successfulpublish a combined status for the Sprint and getting a product owner, we did get a proxyaction plans for the blockers that were raised in product owner named.the Scrum of Scrum meeting. To kick this off, we started having a groomingRetrospective session prior to the completion of day 1 andAt the beginning, we decided that all members the start of day 2. In these sessions both thefrom all teams would participate in one retrospec- support team and the product owner weretive. At first, with only two teams, this worked fine. directly reviewing and ensuring the backlog logsHowever, it was a challenge to complete this in an user stories were the right length and the Sprinthour. And hearing from everyone was increasing- teams could accordingly code from them. Whenly difficult as two more Sprint teams were added any issue was identified, it was immediately sentand the velocity was picking up. In the mean time, to the business analysts to be fixed prior to theother issues were arising in the retrospective of beginning of day 2. Moreover, we had the proxyhigher importance (or at least they seemed to be product owner establish the initial businessof higher importance). Thus, the issue of hearing priority for the user stories and review it witheveryone did not get addressed until we moved the business analysts, thus making sure we knewinto day 2 of the program. To make things more what their priority was once day 2 began.efficient and effective, the “retrospective of ret- Furthermore, we decided that during the firstrospective” was created; this is elaborated on in couple of Sprints of day 2, twice-weekly meetingsthe next steps section. were going to be held with a limit of one hour perDemo meeting.Many eyes were on this program from the Demosget-go. Consequently, we decided to have the Day 2 was much smaller than day 1: Five Sprintslead business analyst perform the demos to the running four weeks in length compared with 15leadership team instead of the teams themselves. cognizant 20-20 insights 3
  4. 4. Sprints for day 1. Therefore, the team demos for following Agile principles with Scrum. The teamsthe proxy product owner were implemented and will be organized in three areas: concept team,no demos for the leadership team were allowed delivery team and the system integration testuntil the fourth Sprint was completed. Now that team. The concept team is responsible for thewe had implemented day 1 to production, the story production/generation, the delivery teamexecutive team and the leadership team were will consume the stories and the system integra-willing to step back some and wait for their tion test team will validate the stories.demos. When one compares the approach we implement-Retrospective of Retrospective ed at this client to the Daikibo framework, threeA lot of wasted time was experienced in the ret- differences are clear. First, there is no integrationrospective meeting during day 1, as all team Sprint following the first development Sprint. Themembers involved were trying to give their input. reason for this, as noted above, is that features/This in turn made it impossible for everyone to be user stories were not developed in sequence.heard in the allotted time given for the meeting. Second, given how the process was handledTo correct the problem, we decided to have the during the requirements and analyses phase priorSprint leads/Scrum master run their team retro- to the move to Agile/Scrum, we had no need forspective. Notes were made on things that worked a formal Sprint 0. Third, we had a support teamwell and did not work. instead of a concept team. This team was distrib- uted between on-site and offshore in an attemptDemos were held at 7:30 a.m. on the last day of to clear issues/blockers as quickly as possible.the Sprint on-site and the retrospective of retro- Daikibo is merely a framework, and therefore willspective at 8:30 a.m. The retrospective meeting not work for every program as outlined.was changed to a similar format as the Scrum ofScrum. In this new format, the Sprint leads would Conclusionrepresent their teams and only the leadership would The program was delivered one sprint (or fourbe there. This new, effective format was called weeks) later than originally planned. The secondthe Retrospective of Retrospective. It allowed us phase of the program has been now running forto focus on what truly worked and what did not. 12 weeks and it is currently ahead of schedule andFurthermore, we came out from the meeting with expected to deliver early. This approach openedan action plan for the top five items. up communication at all levels; program sponsors knew weekly if we were on schedule or not. TheDiakibo Validated teams were able to raise issues/blockers andDaikibo is our large-scale Agile/Scrum framework. know that they would be either removed quicklyDaikibo states that we should separate cross- or the feature would be moved to another Sprint.functional teams and bifurcated responsibili- If the program and organization can be agile withties (a producer/consumer model) operating a little “a” then I would say the program will bein an incremental/iterative pipeline approach, successful.Footnote1 the AuthorDwayne Gifford is an Associate Director in Cognizant’s Advanced Solutions Group and has 20-plusyears of software development experience. He is an experienced Agile practitioner who has led some ofCognizant’s largest distributed deliveries using Agile. He is working on his masters in computer science atTroy University. He can be reached at cognizant 20-20 insights 4
  5. 5. About CognizantCognizant (NASDAQ: CTSH) is a leading provider of information technology, consulting, and business process out-sourcing services, dedicated to helping the world’s leading companies build stronger businesses. Headquartered inTeaneck, New Jersey (U.S.), Cognizant combines a passion for client satisfaction, technology innovation, deep industryand business process expertise, and a global, collaborative workforce that embodies the future of work. With over 50delivery centers worldwide and approximately 130,000 employees as of September 30, 2011, Cognizant is a member ofthe NASDAQ-100, the S&P 500, the Forbes Global 2000, and the Fortune 500 and is ranked among the top performingand fastest growing companies in the world. Visit us online at or follow us on Twitter: Cognizant. World Headquarters European Headquarters India Operations Headquarters 500 Frank W. Burr Blvd. 1 Kingdom Street #5/535, Old Mahabalipuram Road Teaneck, NJ 07666 USA Paddington Central Okkiyam Pettai, Thoraipakkam Phone: +1 201 801 0233 London W2 6BD Chennai, 600 096 India Fax: +1 201 801 0243 Phone: +44 (0) 20 7297 7600 Phone: +91 (0) 44 4209 6000 Toll Free: +1 888 937 3277 Fax: +44 (0) 20 7121 0102 Fax: +91 (0) 44 4209 6060 Email: Email: Email:© Copyright 2011, Cognizant. All rights reserved. No part of this document may be reproduced, stored in a retrieval system, transmitted in any form or by anymeans, electronic, mechanical, photocopying, recording, or otherwise, without the express written permission from Cognizant. The information contained herein issubject to change without notice. All other trademarks mentioned herein are the property of their respective owners.