by: Christopher Pola
This post is Part 1 of a two-part series. You can read Part 2 here.
What’s all this fuss about task schedules? Are task schedules the best way to manage work in the domains of the modern knowledge worker or product development? The answer is flat out “no.” Managing work via task schedules is akin to adopting a production-line mindset. Applying that system of management to creative and human-centric endeavors often exacts a heavy tax, generally in the form of waste. Furthermore, the research in neuroscience, psychology, and management science provides some gravitas to the fact that the mechanical nature of this style of management is contributing to the gender gap and employee burnout issues of today. I bet you don’t have to rely on the science though; you can also probably reflect on your own experiences to know how those things all play out.
The issue is this: Task schedules are very deterministic, yet product development work is inherently variable. The result is that the task schedule always ends up being at odds with the actual delivery dates, and the task schedule takes precedence over learning and discovery cycles. It’s a little backwards when you really think about it. What ensues is that people focus on outputs versus outcomes. People’s motivation and morale fades as they’re ultimately responsible for what they feel to be arbitrary things they had no input into. It all snowballs from there. I have visceral memories of numbness in status meetings as the interrogation around the task due date canceled out the possibility of any intellectual conversation about the actual work, which would have actually been beneficial, that is, valuable to desired outcomes.
There are better ways to manage product development than task schedules, and my preference is the responsibility-based planning and control method. This approach to managing both workflow execution and actual work can yield the following benefits:
If you are a Rally user, you can rejoice because implementing responsibility-based planning and control practices is quite easy due to key functionality in the platform. I will step through those benefits above, and the key functionality in Rally in the remainder of this two-part blog.
The concept of responsibility-based planning and control is quite simple: The fundamental imperative is that the schedule or deadline is never missed, and teams deliver their best effort on those scheduled or milestone dates. That schedule is set by your operating model, such as the enterprise sprint/iteration, release calendar, or milestone date. An enterprise planning calendar is not a requirement, though stacking the principles of cadence and synchronization with this practice can be a force multiplier.
So, remember, the iteration or sprint, release timebox, or milestone date becomes the schedule, not the task completion dates, and these dates are never missed. The rest is the responsibility of the team; they are expected to self-organize and deliver their best work by that date, guided by the strategic objectives that are set.
To implement responsibility-based planning and control, you must limit the work expected of the team to its capacity, period. Managing the capacity of a team, program, and portfolio is the critical enabler for this practice. Visual management of a team's capacity is a more superior lean management practice too, and, voilà, you have Release Planning, Capacity Planning, Team Planning and Milestone timebox functionality in Rally. These capabilities will help you implement responsibility-based planning and control and simultaneously manage all the variable inputs across the different planning horizons and life cycle phases of product development.
As a consultant, I used the data in Rally to manage, track, and forecast the capacity and velocity of teams, programs, and portfolios. If it is a new team, or you don’t have a good grasp on the team's capacity (velocity), then apply the scientific method to determine and improve a team's capacity: iterate, experiment, get feedback, and use empirical data.
Some teams will know their capacity and have a feel for the work. Other teams might build in slack like operations teams (% of unplanned work). Other teams will be constantly refining their backlog to get accurate real-time updates on the amount of work that remains in the backlog as work items continue to be refined. Here’s how specific capabilities in Rally can help:
In my next post, I’ll detail some of the additional benefits teams can realize by adopting responsibility-based planning and control practices.