I don’t know about you, but I want to organize my day’s work as it suits me. Sure, there are the inescapable meetings, which block part of your day, but the rest of it (hopefully most of it) should be under your own control.
Issue Tracking as Pull System
To enable developers and sysadmins to be able to organize their day, we established a pull system for tasks to be done. We usually do a weekly planning meeting where the team takes on an amount of work, which the team feels comfortable of being able to deliver. Out of this pile of work, which we manage in an issue tracking system, everyone can “pull” a task whenever he likes during the week. This sounds like a pretty optimal process, right? But this is where real life kicks in: During the course of a week a lot of new, urgent things pop up, which need either immediate, or at least short term, attention. Often, these things can’t even wait a week to go into the next planning cycle.
Disturbance costs speed and quality
I’m totally happy with dealing with urgent issues. Very often such issues bring tremendous value to our users and that’s why it’s worth doing them as soon as you find out about them. On the other hand, it can become quickly overwhelming. If you try to stick to your promised weekly goals and new stuff keeps cutting in line through various channels, you lose a lot of focus on the current task at hand. Just getting a new request via email instead of as a new issue in the issue tracking system (not to talk about the more invasive ways), harms you in multiple ways:
Smooth flow maximizes speed and quality
To avoid all the aforementioned issues, it is essential to stick to a very strict process of pushing new work orders. Only if everyone is using the standardized way of recording, tracking and managing issues, is it guaranteed that everyone involved can optimize his own work accordingly. Such a standardized process ensures that nothing is lost. People know where to find the information they need and the right triggers for urgency are learned by all. Such a trigger could be a certain issue status like “blocker” or a separate issue type like “Critical Incident”. This forces people to think twice before creating a super urgent issue request, because it will be visible to everyone and they will be held accountable for their decision to stop the complete team’s work. If they just send an IM, no one besides the recipient will ever know. In the worst case, the guy who worked on the issue might even let down the team because he dropped other, agreed upon, tasks to work on a chat request.
The silently humming productivity your team achieves when working at their own pace continues to amaze me. To keep up this flow within your organization, I’ve found it very important to simplify things by allowing only one way of dealing with task assignments: a simple issue tracking system.