Outsourcing Production Support
How to Engage a Remote Team with Minimum Risk
You’re slammed. The list of projects and requests keeps growing. You’re responsible for a complicated ecosystem of applications that support every part of the business. You and your team are overloaded and while you need more help, you’re wary of outsourcing support of live production applications to a remote team. What if it takes too long for a remote team to learn enough to be efficient? What if they are never efficient and you spend more time trying to manage them than it’s worth?
Here’s one proven way to engage a remote team with little risk to uptimes and quality.
The Solution: Tech-to-Tech
By linking a technical person from your team with a competent technical lead from the remote team, it’s possible to efficiently ramp up a team in a different location and time zone to support an application. We call this solution “Tech-to-Tech.”
The technical person from your internal team must have broad domain knowledge and access to stakeholders. This person’s technical background makes it easier to communicate and understand priorities and timelines.
Let’s refer to this person as the Backlog Owner, the only person with the authority to add, change, prioritize, and remove work items. As a result of having deep domain knowledge, the Backlog Owner is able to clearly document and explain requirements as well as make sound decisions to prioritize the team.
A team of full stack developers (at least somewhat familiar with each layer) and testers is led by a Technical Project Lead. Due to the changing needs in supporting a production application, full stack developers are more efficient because they pick up a wider range of work items. When you have a team of specialists and only one person has a specific skill set, that team member becomes a bottleneck. Using full stack developers and best practices like code reviews and knowledge transfer sessions, the team shares both technical skills and domain expertise. When team members can back up each other, you’ll see greater efficiencies throughout the iteration.
We also require software quality engineers (testers) who can cover the full testing lifecycle. Most importantly, we include as much test automation as possible. Depending on the application we are supporting, we may opt to require all developers to split the work of writing test scripts and testing their own work. In some cases, depending on the application, we do not need testers on the team.
Ideally the team structure is between 5-7 (sometimes 7-9) people. With a team of more than 7 (or 9), we may experience communication overhead. With a team of fewer than 5, we may be missing some skills, suffer from lower velocity, and assume risk during the inevitable sick days and time off periods.
Once you’ve assigned a Backlog Owner, you might wonder how to most efficiently manage or groom the backlog. We recommend the following strategies:
1. Break down the backlog according to fixability. Each work item is either a bug or enhancement/new feature.
2. The Backlog Owner and the team work together to classify and estimate backlog items.
3. Typically bugs and issues take higher priority by default. In the simplest form of categorization, each product item will be designated as new, work in progress, or complete.
And now folks, for the biggest challenge we face in supporting a production system: priorities change daily depending on business needs. How do you combat this challenge?
Make the work in progress as small as possible. When priorities continuously shift, quickly completing smaller work items makes the team nimble. The overarching idea is to ensure you don’t overcommit yourself to larger work tasks. Even if an iteration cannot be completed, a team member can easily wrap up a task and shift to something new. This approach is great for keeping the team feeling accomplished and successful and ensuring you have happy project stakeholders.
Maintain your backlog on a daily basis. Daily review and grooming may be tedious, but it’s necessary for optimal team efficiency. The Backlog Owner adds new backlog items based on stakeholder requests, shifts priorities as needed, and reviews completed items. And remember Tactic #1! Large work items are complicated and often require too much “back and forth” to ensure the item is built, tested, and released on time.
Branch your code. Get your team in the good habit of code branching. This way, if anything is in progress, it will not impact the main or production branch. When you pick up an item to work on it, you create a new branch and only merge it back when it’s ready to be delivered. If there is an urgent request in the middle of the week, we start from the production branch, create a new branch, make the changes, and merge it back in without impacting the production branch or the work-in-progress items.
To keep your team efficient and ensure the business/client sees a short- and long-term return on its investment, create a category in your backlog called “Technical Debt.” When the backlog contracts, the development team will switch gears to focus on reducing the technical debt every system accumulates. It’s definitely good practice to go back and refactor, maintain, write more test scripts, etc., when you have the capacity.
With production support, it’s all about continuous delivery. With this in mind, we suggest you maintain weekly releases.
Start by measuring the strength of the team and its velocity. Using this as a basis, create an achievable weekly release schedule. By sticking with weekly releases in addition to smaller work tasks, you will be able to better control changing priorities and adjust quickly.
More Benefits of Weekly Releases
• Happier stakeholders and internal clients. They’ll feel the positive impact of frequent releases.
• Structured for efficiency. Weekly releases encourage teams to implement test automation
because manual integration tests are time-consuming and tough to fit into a weekly cycle.
• Better measurements of workload. By consistently measuring the cycle time or amount of time it takes for a task to move from start to release, the team will forecast the time it will take to complete future work with greater efficacy.
Ideally, you’re using a robust tool like Team Foundation Server, but you can also track a backlog in something as simple as Excel. If TFS is too large an investment for you, start a smaller team with TFS Online. It’s free and should be sufficient to get a team going. When you see the value and you’re ready for advanced features or need to support larger or multiple teams, you can always upgrade. TFS also comes with templates that support methodologies that are a good fit for production support teams like Kanban.