Sometimes a self-inflicted pain is necessary to ensure success
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.