2 Geographies, 3 Development Centers, 85 Engineers and One Common Goal

Global Agile Delivery: 2 Geographies, 3 Development Centers, 85 Engineers and One Common Goal

Kartik Matmari, SPM, MFGD - Microsoft Account, Seattle USA

 

I manage a services delivery program for arguably the largest software manufacturer in the world where we have 85 Engineers and managers, 3 different development centers spread across India and the United States. We use a perfect AGILE engineering model to deliver critical business functionality for the platform that is responsible for 95% of the client’s revenue.

 

CIOs and IT Decision makers at global corporations continue to express their skepticism on the efficacy of an Agile engineering model involving multiple geographies, multiple time zones, different set of people from different cultures, multiple development centers etc.

 

I have been often approached by my colleagues from different accounts in Infosys to discuss the details of my program, how’s it’s different from theirs and how we can adopt best-practices if any. I also got the opportunity to discuss the success of global agile delivery with the directors of a large US Retail giant who were skeptic about outsourcing work to Indian locations because they believed that Agile engineering model would not work in an Onsite-Offshore setup. My discussion with them was very positive and most of their myths were busted and also influenced their IT decision in favor of a global delivery.

 

The most common arguments by CIOs/Directors/IT Decision makers against a global agile delivery model are:

 

·         “All members should be at the same location for Scrum to be successful”

·         “Different locations means lack of involvement of team members”

·         “X-Geo Scrum is not truly agile”

·         “Onsite Teams more productive than offshore teams”

 

I am sharing some of the most common points of dicussion about global agile through some images and diagrammatical represetnation

 

The Need for a X-Geo Delivery

 

Why X-Geo Delivery? •       Huge Cost Savings and Time Advantages (Follow-the-Sun) were the key drivers for adopting a X-Geo delivery by the customer. •       High attrition and resource availability and loyalty at onsite location was a big challenge. •       Customer did not prefer subcontractors due to various issues (Loyalty / NDAs / IP Issues / Accountability / Governance etc) •       Customer wanted to effectively leverage their own offshore captive development center in India. •       Customer wanted a need-based ramp-up and ramp-down of resources via a strategic partner (Infosys) •       Customer wanted to reap the benefits of having a resources available with cross-functional skills (Different Applications, Dev, Test, Build Engineering, Performance Testing)

 

 

How infosys did it?

 

Program Snapshot •       Engineering team consists close to 82 Developers and Testers •       Team spread in 3 locations - US, Customer Location India, Infosys India •       Customer and Infosys formed several development scrum teams a.k.a “crews”. •       Large Releases targeting strategic initiatives [POR] 2 times in a year and several releases over a year for minor enhancements, bug fixes and hot fixes. Key Drivers for Agile Adoption •       Requirements of client driven by industry demands and partner needs. •       Cannot have requirements sign-off in one go. •       Most of the times requirements delivered by Engineering would be rendered obsolete due to market dynamics and changing needs during the project release schedule. •       Wanted a model which is AGILE and can adapt to ever changing business needs. •       Wanted higher velocity and throughput from teams. Higher ROI. •       Early risk identification and mitigation.

 

Challenges in SCRUM Adoption

 

Some of the key challenges faced during Scrum adoption in the program and how the challenges were met.

 

1.        Skepticism about SCRUM success among teams.	Senior management commitment and belief in Scrum methodology. 100% buy-in from all program managers. Education and Workshops on Scrum methodology. Success stories.
2.        Cultural Shift from Legacy Waterfall Model to Agile.	Project Managers owned the responsibility of bringing about the Scrum culture. Brown Bags, Offsite Events, Town-Halls planned to educate about Scrum and its benefits
3.        Teams guided by misconception about Agility	Invited speakers from all sections – PM, Dev, Test to talk about success in Scrum.  Myth buster sessions, Group Discussion, Blogs etc.
4.        Work-Life Balance	Initially there were WLB issues but with program maturity WLB was no more an issue.
5.        Efficient Task Allocation & Effort Tracking	100% Tool Usage for Program Management. Total dependency on Tool for User Story creation, allocation, progress tracking, release etc.
6.        Communication	Disciplined meeting and communication cadence.  Scrum-of-Scrums Model.
7.        Motivation	Rewards and Recognition, Team events etc.
8.        Governance and Reporting	Effort Burn Down Chars, Steering Committee Check point meetings, Task Force Audits, Engineering Excellence Meetings.

 

 

 

 

 

 

 

 

 

 

 

 

Team Structure

 

 

The Scrum-of-Scrums (SoS)

 

A bi-weekly syncup of all scrum masters of various crews led by the release management team.

 

 

 

Communcation Cadence

 

 

Solution Apptroach and Advantages

 

	Solution Approach   1.        Disciplined communication Mechanism 2.        Rotational  Overlap in US and India timings 3.        “To-the-Point” discussions 4.         2 Week Sprints 5.        Daily stand-up meetings 6.        User Stories, Story Points, Planning Poker 7.        Strong Usage of Tools – VSTF 2010 8.        Scrum of Scrum (SOS) Meetings 9.        Sprint Retrospectives  and Review Meetings		Advantages   1.        Reduction in scope intrusions, scope overlaps, Code version conflicts 2.        Higher velocity, wider throughput, agility and scope creep mitigation. 3.        Ability to react faster to business changes. Requirement tradeoffs due to urgency. 4.        Transparency to Business teams about what Engineering teams are working on. Sense of inclusivity for all stake holders. 5.        Opportunity to monitor and see what is going to be released to production very early in Engineering cycle 6.        Clear visibility on Effort spent by the teams 7.        Due to short sprints and constant feedback, easier to cope with the requirement changes 8.        Issues identified well in advance through the daily meetings and can be quickly resolved
Kartik Matmari
Senior Project Manager, MFG- ADM, Microsoft Account, Seattle
		Kartik manages services delivery for hi-tech customers and ISVs.  Currently he is responsible for Application Services delivery for the Sales and Marketing IT group of Microsoft Corp. Redmond, USA.   He is also involved in mega-pursuits and transformation engagements for Infosys. He has worked with global customers in Retail and Banking for program implementation using AGILE methodologies. He is an avid quizzer and a voracious reader.      Kartik will be blogging on Application Services, Agile Challenges and Solutions, Cross Geography Global Agile Models and Digital Transformation.

 

 

A Self-Inflicted Pain

A Self-Inflicted Pain - why we need 2 week sprints

 

Kartik Matmari, SPM, MFGD - Microsoft Account, Seattle USA

 

I was part of a large team at Infosys Hyderabad working for an application development program for a global customer. One of the good things of the program was a customer visit to Infosys offshore locations every six months after a large program release.  This regular customer visit was an integral part of the relationship as these “release celebrations” created a great sense of inclusivity and instilled a sense of importance and responsibility for everyone involved both at offshore and onsite locations. During these “release celebrations”, star performers would be rewarded and recognized, key contributions appreciated and future projects and roadmaps discussed.

 

The customer team consisted of Senior Delivery Managers, Engineering leads and the Scrum coach. Project Managers and Leads from Infosys always had an opportunity to discuss the strategies defined by the customer and we at Infosys always looked forward for these meetings to bombard the customers with our questions.

 

Death of Work-Life Balance

 

On one such particular occasion, all of us at Infosys were highly concerned about a new decision that the customer had taken. Customer had reduced a Scrum Sprint from 4 weeks (20 days) to 2 weeks (10 days).

In this program a Sprint end indicated a feature complete, and a 2 week sprint made it extremely difficult for the engineering team to ship features. This decision did not go well with Infosys teams and also with the customer’s development teams that worked from their India IT center.

 

I took the initiative to lead the discussion with the customer to understand why a decision as outlandish as this one has been taken.  We at Infosys faced morale issues from the team members as everyone felt scared and de-moralized by this decision because it was a sure Work-Life Balance Killer! 

 

A Self-Inflicted Pain

 

I started the conversation with Steve W, the Customer delivery manager. It was apparent that the customers anticipated this question because I came to know later that this was the main topic of discussion with their development teams back at their India IT Center as well. I started describing the disturbance this decision has created among the teams and how this will mean long work hours and near impossible targets etc. After I finished my “tale of woe”, Steve said, “Kartik, we understand every point that you made, but this is a self-inflicted pain that we have introduced in our engineering model”

We wanted him to elaborate what he meant by - a self-inflicted pain.

 

By shortening the sprints the customer was encouraging “early failures” in development rather than late failures. Finding and fixing critical problems in the early stages of a 6 month project schedule was the key benefit of this decision. A critical integration issue introduced as a late breaking bug after 4 months of the schedule would jeopardize a release.

 

Steve also mentioned that “Sprint failure is OK!” Until that point all of us believed that when a Scrum team commits to a sprint scope, then the team has to deliver that scope, come what may. And this was the main reason for the teams to think that a short sprint was a WLB killer. Steve explained that it’s OK to fail in early sprints and that was the main intention of shortening the sprint. Early failures help in uncovering critical issues and clear the path as we progress into the schedule. It’s important that the leadership team ensures that critical requirements are scoped into the early sprints so that the roadblocks to deliver the most critical scope are unearthed and fixed early in the schedule.

 

Good news should travel fast, bad news faster.

 

What I heard made perfect sense and the teams’ apprehensions were laid to rest. The new model gave an opportunity to find and fix critical problems very early in the lifecycle. It made the work more exciting and also the “freedom to fail” warded off the fear among the developers and testers. It was accepted positively and very soon we started seeing the benefits of the self-inflicted pain.

<![if !vml]> <![endif]>    Kartik Matmari
Senior Project Manager, MFG- ADM, Microsoft Account, Seattle
	Kartik manages large services delivery for hi-tech customers and ISVs.  Currently he is responsible for Application Services delivery for the Sales and marketing IT group of Microsoft Corp. Redmond, USA.   He is also involved in mega-pursuits and large transformation engagements for Infosys. He has worked with global customers in Retail and Banking for program implementation using AGILE methodologies. He is an avid quizzer and a voracious reader.      Kartik will be blogging on Application Services, AGILE Challenges and Solutions, Cross Geography Global Agile Models and Digital Transformation.

 

 

Presenting at International AGILE Forum, Nashville, Tenesse

 

 

 

iPad Comparison

Model		iPad (1st generation)	iPad 2	iPad (3rd generation)	iPad (4th generation)	iPad Mini
Status		Discontinued	Available	Discontinued	Available	Available
Announcement date		January 27, 2010[20]	March 2, 2011[44]	March 7, 2012	October 23, 2012	October 23, 2012
Release date		April 3, 2010[3]	March 11, 2011[110]	March 16, 2012	November 2, 2012	November 2, 2012
Discontinued		March 2, 2011[44]	32, 64 GB: March 7, 2012 16 GB: In production	October 23, 2012	In production	In production
Display		9.7 inches (250 mm) multitouch display with LED backlighting and a fingerprint and scratch-resistant coating[6]				7.9 inches (200 mm) multitouch display
		1,024 × 768 pixels at 132 ppi		2,048 × 1,536 pixels at 264 ppi (Retina Display)		1,024 × 768 pixels at 163 ppi
SoC		Apple A4[7]	Apple A5	Apple A5X[111]	Apple A6X	Apple A5
CPU		1 GHz ARM Cortex-A8	1 GHz dual-core ARM Cortex-A9	1 GHz dual-core ARM Cortex-A9	1.4 GHz dual-core Apple Swift	1 GHz dual-core ARM Cortex-A9
GPU		PowerVR SGX535	PowerVR SGX543MP2	PowerVR SGX543MP4	PowerVR SGX554MP4	PowerVR SGX543MP2
Memory		256 MB DDR RAM built into Apple A4 package[8]	512 MB DDR2 (1066 Mbit/s data rate) RAM built into Apple A5 package[9]	1024 MB DDR2[10]	1024 MB DDR2[112]	512 MB DDR2 RAM built into Apple A5 package[113]
Storage		16, 32, or 64 GB[6]
Wireless	Wi-Fi	Wi-Fi (802.11a/b/g/n), Bluetooth 2.1+EDR[6]		Wi-Fi (802.11a/b/g/n), Bluetooth 4.0
	Wi-Fi+3G/4G	In addition to above: 3G cellular HSDPA, 2G cellular EDGE on 3G models[6]		In addition to above and left: 3G transitional LTE on 4G model
Geolocation	Wi-Fi	Wi-Fi,[6] Apple location databases[114]
	Wi-Fi+3G/4G	Assisted GPS, Apple databases,[114] Cellular network[6]		Additionally: GLONASS
Environmental sensors		Accelerometer, ambient light sensor, magnetometer[6]	Additionally: gyroscope
Operating system		iOS 5.1.1	iOS 6.0.1[115]
Battery		Built-in lithium-ion polymer battery; (10 hours (Wi-Fi), 9 hours (3G or LTE) browsing; 10 hours video;[6] 140 hours audio;[116] 1 month standby[117])
Weight		Wi-Fi model: 1.5 lb (680 g) 3G model: 1.6 lb (730 g)	Wi-Fi model: 1.325 lb (601 g) GSM 3G (AT&T) model: 1.351 lb (613 g) CDMA 3G (Verizon) model: 1.338 lb (607 g)	Wi-Fi model: 1.44 lb (650 g) LTE model: 1.46 lb (660 g)		Wi-Fi model: 0.68 lb (310 g) LTE model: 0.69 lb (310 g)
Dimensions		9.56×7.47×0.528 in (243×190×13.4 mm)[6][118]	9.5×7.31×0.346 in (240×186×8.8 mm)[118]	9.5×7.31×0.37 in (240×186×9.4 mm)		7.87×5.3×0.28 in (200×130×7.1 mm)
Mechanical keys		Home, sleep, volume rocker, variable function switch (originally screen rotation lock, mute in iOS 4.2, either in 4.3 and later)[6]
Camera	Back	N/A	720 p HD still and video camera 0.7 MP, 30fps and 5× digital zoom	1080p HD still and video camera 5 MP, 30fps and 5× digital zoom
	Front	N/A	VGA-quality still and videocamera, 0.3 MP		1.2 MP still, 720p video
Greenhouse gas emissions		130 kg CO2e[119]	105 kg CO2e[120]	180 kg CO2e[121]	170 kg CO2e[122]	95 kg CO2e[123]

 

 

Kartik Matmari

Infosys Ltd | 510 759 9535 | v-kartim@microsoft.com | kartik_m@infosys.com

http://www.infosys.com/microsoft/