Tom Breur
17 January 2016
Time-boxing helps drive
focus. It “forces” you to set priorities. You “force fit” the must haves into your time-box, and then
determine which nice-to-haves may
still get done. A valuable part of time-boxing is that you learn over time, how
much you can realistically get done during a Sprint (as time boxes are called
in Scrum).
Part of the valuable feedback we get from Agile processes is that you learn, empirically,
what is and isn’t attainable. While coaching Agile teams, I sometimes observed
overly ambitious folks who repeatedly missed their Sprint goals. Or, who
habitually incurred technical debt in an attempt to make it look like they are
achieving the goals. The latter is of course largely the same, just a “special case” of missing your Sprint goals. If this is what you see, then
apparently those goals weren’t really attainable after all. The objectives
weren’t realistic.
You may then conclude this
team is inadequate, or that you don’t have enough resources, or whatever
conclusion you may draw, but you just can’t fit 10 pounds of potatoes in a 5
pound bag! By bringing “reality”, i.e. past experience into the equation, you turn “estimation” into “analysis”, one of the apparent differences between Scrum and
Kanban.
It is only natural (and
actually part of their role) for Product Owners to “persuade” developers to fit
their most pressing needs into the next Sprint. But sometimes we “just can’t
get it done”! What we typically mean is: “I don’t know how to do this”, a more
courageous way of stating the same. Although difficult to do, pointing to past
“lack-of-success” of meeting Sprint goals is the most valid predictor of what
can or cannot be done within the next time box. And if you don’t (want to)
believe it, it’ll only take another Sprint to find out…
No comments:
Post a Comment