Having your product team double hat as an application support team is great as far as resource utilization is concerned and for setting accountability, i.e., “what you broke, you fix’. But, is that really the ideal scenario? Let’s consider these points:
Diversion does not help productivity
The product team is allocated to developing new features and delivering changes to the product, according to a defined and committed roadmap. To expect them to shift their focus in fixing support issues is diverting that focus from the roadmap items. Both productivity and commitments are likely to suffer. For example, we often see Scrum teams reserving up to 30% of their time for unplanned activities, when they are also involved with production support. Isn’t that a colossal waste of time if no issues come their way during that sprint? What if the time to fix issues exceeds the allocated 30%? (Remember, these are unplanned activities and may occur at any time of the day)
Well, for one, your velocity graph starts jumping up and down. Once a Scrum team gets used to this mindset, they will never have the inclination to achieve the optimal cadence that is the hallmark of Agile and Scrum.
Secondly, the criticality of the support issues and the committed SLAs are likely to create a pressure situation for turning around things quickly. The result? Exhausted and burnt-out teams. Moreover, the quick fix habits that might become necessary during a production support issue are then carried over to the planned activities.
The production team’s dedicated focus on application development could result in delayed issue resolution. Needless to say, this will create a loop of dissatisfied customers, who don’t receive fixes or features that they requested, on time.
Bringing in balance
No product team is like the other, so there is no single workaround that can be applied to all. Our experience has taught us that the way to minimize the load on the product team is to gradually transition out to a support team until the latter becomes empowered to handle all the issues on their own. How?
Planned transition
Since the team works day in out to develop new features, plan releases as well as improve the application, the product team will be well-versed with the application issues. Hence, when a dedicated support team is formed, there should be a plan that allows a smooth transition. It can start off with an 80:20 ratio where 80% of the time, the product team handles the application issues, and the support team handles 20% of the issues. Over a period of 90 days, support will be transitioned out to the support team handling 100% of the issues, with the product team called in only for rare cases to support.
Arm with support tools
During the transition phase, the developers who are part of the product team have to dedicate some of their time to building utility tools for the support team to use. The support team is not required to have the same set of skills as a development team. The self-help tools for support teams should include the ability to find and store information about bugs and feature requests, track, plan, and chart out the road map for new features and offer the ability to communicate with the development team should any issue arise that they are unable to solve.
Mentoring
They say we never stop learning. This applies to application development and support too. It’s important that the product team spends ample time sharing knowledge about the application, the innovative features being planned and rolled out. The support team, on the other hand, must share knowledge of new and improved fixes that they found for difficult issues. In this way, the development and support teams must work collaboratively even after the transition is complete.
Curious about how we planned the transition to a full-fledged product support team? Please write to us at itservices@healthasyst.com