Recently I’ve been working with a team responsible for triage. Though initially a medical terms, it explains quite well with what the team was doing – reviewing requests coming from customers and identifying whether issues reported are expected behavior, bugs or feature requests and how important they are
Bright individuals were working in this team, great developers and testers. But let’s be honest, triage can be boring, especially, for prolonged periods of time. It’s not that we don’t care about our customers’ requests, it’s just we’d love to work on something more engaging and challenging.
At the same time we can’t abandon triage completely – customers will be customers with requests. But how do we keep triage going fast and give everyone on the team an opportunity to shine?Initial setup
The team from the start was a big team and was supposed to grow (above regular Agile team standards). This allowed us to have a couple of people available to work on something else than triage.
In our work we used Kanban approach with agreed upon SLAs from our side. We’ve also been trying to limit the Work in Progress items per each team member to keep the flow, well, flowing.
Each person on the team would take new tickets as they came in and followed them thru to the end until they got resolved or turned into a bug. So once a team member picked up the ticket he/she is fully responsible for it
Getting ready to work on new features
As I mentioned before, our main goal was to accomodate feature work and keep on top of our SLAs for triage.
In an effort to introduce some feature work for the team, we work with our Product Owner (who we “borrowed” from a regular Scrum framework) to define a backlog of stories we can take.
Any limitations? Yes, we’re in a unique scenario here. We agree to work on a single story at a time and we do not fully commit to a certain delivery date. We will provide an ETA for our own tracking purposes, but we cannot guarantee anything, because you never know when the team might need to revert to an escalated issue from a high-profile client.
What does it mean for the Product Owner? He should choose user stories and bugs to fix that are not time sensitive and are not customer commitments.
Creating a sub-team
At the beginning we tried assigning various tasks from the feature stories to different team members to give everyone a chance to work on something new. But we quickly realized that we were losing focus on both sides: triage and feature work. Our user story would drag forever and customer requests would pile up. The main reason was, of course, frequent switch of focus.
We were looking at different solutions we could implement to solve the issue:
- Time box the work on the user story to 2 days, then switch to customer requests for 2 days, rinse and repeat. That way we can make sure we follow our SLAs. But it would still create a frequent focus switch that slows us down.
- TIme box the work by 1 working week. That way we can have enough time to focus on the feature work, but we will be missing SLAs on requests that were already worked on by certain team members previously.
- Dedicate a small team to work on the feature for each sprint.
The last idea seemed like the best solution we could implement.
Why? It allowed 2-3 people to work on the feature together as a team (much like a Scrum team) for a whole sprint without interruptions (much like how actual Scrum works). It means better focus on the work at hand and quicker results.
At the same time we would be able to work on customer requests and support the SLAs with team members fully dedicated to this work.
An important addition to that is rotation: everyone on the team would have a chance to work on a feature, generally every 3 sprints.
As for the dedicated feature team, it was gaining all the benefits of the self-sustaining, self-organising team with great commitment to deliver the feature as soon as possible in ihigh quality.
The only edge case here would be emergencies and excalations. It was agreed by the team that if some customer request of very high priority comes up that requires someone from the dedicated feature team to step in, we would need to put the feature work on hold. But once again, it would be a rare case that would disrupt our work anyway.
At the end of the day, we developed a process based on our commitments to our customers as well as desires of our team. Though it might not be ideal on a global scale of the organisation as a whole, but it was definitely a solution that was there to resolve an important concern without creating new ones.
Have you faced a similar problem with one of your teams? What was your solution to introduce more engaging work in an operational work environment?