Scheduling Work
thinking past the timebox
Work scheduling is the set of protocols we use to commit stories to work and manage progression through to getting them done. Release management is often so closely bound up with work scheduling that they seem like the same thing, and when things are running smoothly, it hardly matters. However, when there are problems, separation of concerns is what keeps us from getting tangled up. A lot rides on our choice of Scrum, Kanban or bespoke scheduling system.
Strategy vs. Tactics
Project management is where you set your strategy for balancing time, budget and scope; Work scheduling is where you figure out the tactics of how you’re going to accomplish those goals. Release management is where you deliver on your goals, including setting stakeholder expectations.
To separate out the concerns of release management from work scheduling, compare the different approaches to work scheduling, including Waterfall, where you plan from inception to delivery before starting, Scrum, where you batch work in time-boxed iterations, Kanban where iterations are not time-boxed, but limits set on the amount of work in progress.
To Scrum, or not to Scrum
When an organization attempts to reduce Agile to a prescriptive methodology like Scrum, there is a tendency to lose sight of where the practical work of project management and release management fits in. Release management, in particular, takes in many questions beyond what you need to resolve to get the work done.
Scrum is increasingly taken as a synonym with Agile, which is taken as a Software Development framework. I prefer to think of Agile is simply a set of principles, and Scrum as primarily a work scheduling system with a lot of supporting recommendations. When you try to squeeze everything in one package, then it becomes hard to see where problems originate.
Work scheduling in Scrum is done by Sprint batch. To a certain extent, this is a response to the problem of shifting priorities being imposed on the development team by whoever has the biggest salary. The Scrum Sprint seeks to seal the team off to prevent this kind of interference and allow the team to focus on getting work done.
Another reason for scheduling by Sprint batch is to establish cadence, to build confidence that despite appearances, there is steady progress. These can be good reasons for batching work by Sprint, but it comes with tradeoffs.
The Signal Card System
Cloud-based systems to keep track of work are very useful, but when people begin to think of Jira as their work scheduling system, and Kanban as Scrum without the time-box, and then we’re missing the point of what we need from a work scheduling system. Where Scrum batches work by Sprint, Kanban batches work by capacity, using signals to indicate when to pull in additional works. The differences are significant.
Kanban also provides for defending the development team from arbitrary assignments, perhaps better than Scrum. In Scrum, we say that the team should only work on stories committed to the Sprint, but there are good reasons for adding stories to a Sprint, and so the wrong reasons come in through the same door. Kanban doesn’t try to sort the good from bad reasons; it just makes the decision to sideline work in progress for new work an explicit action with unambiguous visibility.
Understanding the Work
Everybody gets that building software can be complex, but there’s less clarity on just how complex the process really is. If our goal is more than just getting work done, improving our process, than we don’t care so much about exactly how we schedule work, but how our work scheduling system lends itself to helping us understand where we’re bleeding value.
It’s a common misconception that your work scheduling system, is your process, but it’s more like a toolkit to help you model your process. Your process is what team members are doing. You can’t understand it until you model it. Once you model it, you can begin to see the most critical areas for improvement.
Thomas Verleene — "Time Square, New York"
Let's agree to define productivity in terms of throughput. We can debate the meaning of productivity in terms of additional measurements of the business value of delivered work, but as Eliyahu Goldratt pointed out in his critique of the Balanced Scorecard, there is a virtue in simplicity. Throughput doesn’t answer all our questions about business value, but it is a sufficient metric for the context of evaluating the relationship of practices with productivity.