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.