Application Services provides a platform for IT Development and Maintenance professionals to discuss and gain insights into best practices, process innovations and emerging technologies that will shape the future of this profession.

« Refreshing User Experience - Different strokes for different folks | Main | 2 Geographies, 3 Development Centers, 85 Engineers and One Common Goal »

Sometimes a self-inflicted pain is necessary to ensure success

self-infliction of pain-03.jpgPosted by Kartik Matmari, Senior Project Manager, Infosys

I was part of a large team at Infosys working for an application development program for a global customer. One of the good things of the program was a customer visit to the 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.

On one such particular occasion, all of us were highly concerned about a new decision that had been taken. The decision was to reduce the Scrum Sprint from 4 weeks (20 days) to 2 weeks (10 days). Given that a Sprint end indicated a feature completion, a 2 week sprint would have made it extremely difficult for the engineering team to ship features. This decision did not go well with my team and me and  also with the customer's development teams that worked from their India IT center.

So, I took the initiative to lead the discussion with the customer and related stakeholders to understand why a decision as outlandish as this one had been taken.  I was sure that this would be a Work-Life Balance Killer and hence feared for my team's morale.  

As I started the conversation with the customer delivery managers, it was apparent that they were anticipating my questions. I started describing the disturbance this decision had created among the teams and how this would mean long work hours and near impossible targets, issues with team morale, work life balance, etc. After I finished my "tale of woe", the customer delivery manager said, "We understand every point that you made, but this is a self-inflicted pain that we have introduced in our engineering model to ensure success". A self-inflicted pain to ensure success! Can you please elaborate I requested?

By shortening the sprints they were 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. They also mentioned that "Sprint failure is OK!", which was like a load off our shoulders, as till then 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.

They further 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.

As I sat back in my chair, I felt relieved. What I heard made perfect sense. The new model gave us 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 this so called self-inflicted pain.

Comments

This thinking behind allowing early failures is very interesting indeed. When did the client take this decision and how has been the short term and long term outcome of it? On delivery aspects as well on team morale?

Hello Abhijit

I dicussed this whole aspect of sprint reduction and early failure with the client delivery manager and this is what he informed me.

Two weeks sprints is a forcing function for the teams to learn at a faster pace. It’s a lot easier to recover from a failed two week sprint than a four. Learning is a key component. Another key aspect is repetition. Just like a muscle, the more we work it out, the better trained and ability to handle increasingly heavy loads.

The same with a team sprinting in shorter iterations. They can learn from prior failure and successes and refine their plan. It also forces the team to decompose stories into much smaller consumable chunks versus larger stories in a 4-week sprint. The larger the story, the more risk and ambiguity that is introduced.

Another good benefit is business value is being delivered in shorter durations, allowing the product owner to make fine course adjustments more frequently (this includes more frequent delivery of value to end-customers). This is especially important on large projects or on web-based projects where “web time” is increasingly getting shorter and time-to-market is a key business differentiator [as an example, companies like Facebook actually deploy to production 2-3 times a day!].

This decsion was taken about an year ago and we have seen the benefits ever since. The quality bar has gone up, teams have become more productive and there have been negligible WLB issues.


Kartik,
I really agree with you with the fact that we initially faced a lot of pressure in terms of delivering but later we started seeing the benefits out of it.
Now I am working for a different project and client(Niether sprint nor scrum) where the deliverables are met at the last day and end up with more defects and spending more hours to fix the defects for GO LIVE.
I feel that the shorter the sprint cycle the better the benefits.
Now Iam also reminded of the childhood quote "No pain ,No Gain."

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.