Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Managing the Process
Once we had the right people in the room, the next step was to figure out how we were all going to work together, finding a way to balance the client-facing issues and the core platform issues. The first thing we did was work to get consistency across project databases. We needed all the projects to use the same workflows, track releases in the same way, and use automated "top ten" lists that populated from different projects. Those top-ten lists became the primary view of relative priority across projects. For example, we created a client top-ten and a platform top-ten. The client top-ten looked across all the client-facing projects, and the platform top-ten looked across all the technical-facing projects that might affect internal operations or multiple clients.
With the lists set up, the next step was to clear out the work in the developers' personal queues. Because a developer might have a number of tickets currently assigned without regard to relative priority, we asked everyone to pool any tickets not actively being worked. Then, when each developer was ready for the next ticket, he or she would simply pull from a top-ten list, regardless of which individual project would normally get his or her focus.
Once a ticket is in a top-ten list, you have to think about where it goes next. The same team that populated the top-ten lists also planned for how those tickets got out to production. One technique we found helpful was to tie the priority of a ticket to the release schedule. We started with some simple heuristics: A blocker issue equated to a hotfix, a critical issue would go in the next scheduled release, and everything else (major, minor, trivial, etc.) would be worked and slated for release as resources allowed.
The team that reviewed the tickets on a regular basis was also the team that managed any issues resulting from investigation. They coordinated getting work done across teams. They also determined which tickets qualified for rejection or were returned for more information. By escalating issues as needed, this group helped resolve blocking issues for the people who were working the tickets.