The Rapid Response Team
Have you noticed how fast a team goes when they’re just getting started, but that once the product is live and there are customers and users, that the velocity of the team can slow down to a crawl? It’s an all too common problem, and it causes frustration all the way around. Once you have real customers and/or an active sales team, there are always bugs to be fixed and changes urgently needed. So the development team no longer has a clear focus because they’re now being pressured to fix and change the prior versions at the same time they’re being pushed to create significant new things.
Generally in this situation, nobody is happy - customers feel like it takes way too long to get problems fixed, management feels like the team is working in slow motion, developers feel like they’re pulled in ten different directions and can’t focus on anything, product managers feel like they can’t move the product forward.
Moving to dedicated teams addresses a part of this problem. Portfolio Grooming addresses another part of this problem.
However, fundamentally when the same team of developers is trying to both move the product forward, yet also respond to urgent fixes and special requests, the result is that both the new product work, and the maintenance work, often slow way down.
If velocity and customer responsiveness were not an issue, then having developers support their own code makes total sense, and it’s a principle that I advocate. However, for many teams, the cost of following this principle is simply too much for the business to bear.
In these cases, a practice that I have seen make dramatic improvements along both dimensions is to create at least one special dedicated team that we often call the “Rapid Response Team.” This is a dedicated team comprised of a product manager (or at least a part of a product manager), and mainly developers and QA. Usually these teams are not large (2-4 developers is common). This team has the following responsibilities:
• fix any critical issues that arise for products in the sustaining mode (i.e. products that don’t have their own dedicated team because you’re not investing in them other than to keep it running).
• implement minor enhancements and special requests that are high-value yet would significantly disrupt the dedicated team that would normally cover these items.
• fix any critical, time-sensitive issues that would normally be covered by the dedicated team, but again would cause a major disruption.
This last two cases are a bit tricky to explain. Normally if there is a dedicated team, they would fix their own problems and do their own enhancements, and most of the time they still will. But sometimes they will be in the midst of some major work, and for them to stop and make some fixes and test them and get them out can cost much more in terms of time and momentum than just the time to fix the bug. In this case, the Rapid Response Team might cover it. However, when they do, they still need to discuss and review the change with the developers on the dedicated team.
In large part, this type of rapid response team provides a form of relief valve for the organization. Rather than be put in the position of either always saying “no” and being perceived as unresponsive, or else always saying “yes” and then dramatically slowing down the velocity of the new product work, the organization can now respond to customer issues and minor items in a timely fashion, yet still get fast progress on new product work. I promise you that your executives and critical customers will be so happy to be able to get at least many of their hot button issues addressed quickly, and this relieves a good deal of pressure on the organization.
The main objection to creating a rapid response team is that it can be hard to convince developers to work on this team, because it’s perceived as a bug fix team. That’s fair, but I find that there are some techniques to mitigate this. First, when a new developer (especially a college hire) is hired into a team, this is a perfect place to start as he or she can get the chance to learn the code base and get the holistic view. Second, one of the responsibilities of your senior developers is to teach the new developers, and if a senior developer is paired with one or more new developers, he can review and mentor the new developers. Third, being on this team is not a life sentence. After 6 months or so it’s typical that the developers will rotate out and onto a different team.
The velocity of software teams is a funny thing. The math doesn’t really add up the way you’d think it would. A small team that can focus on something can make amazing progress. Interrupt them frequently and things slow to a crawl. What I have consistently found is that if the development organization pulls out 2-4 developers from other teams, and has them focus on Rapid Response, then the original (but now somewhat smaller) teams makes faster progress, and the customer responsiveness to critical issues gets dramatically better.
If you think this might work for you but you’re not completely convinced, you can try it on just a subset of your development organization and compare the results.