The work process sets clear boundaries, while creation is more fruitful with unclear ones. This may be the source of some problematic relationships between product managers and engineers. Luckily, something beneficial can be done. A Middle Way between process and flow exists. We’re going to see how different conditions create different boundaries.
Don’t forget to leave a buffer for maintenance!” was what me, my superiors and colleagues always reminded one another when we were about to plan a Sprint. “How much of a buffer?” was always the followup question. The answers range from “I don’t know, figure it out”, to “a rule of thumb says X%”. For some reason, no matter which X we choose, we ended up being wrong. By the end of this Planning series, we’d know why. Hopefully we’d also know how to do it right. In order to get there, first we need to decompose everything we know about buffers and expectations.
In the previous chapter, we talked about expectations. Both from and of customer’s, engineering and the Plan itself. In this chapter we’re going to talk about predictions, the things we know and expect to happen. If we know them, we can better plan for them. If that is so, actively predicting should be a part of Planning.
“Nothing can be said to be certain, except death and taxes”. Benjamin Franklin had a point. These are the results of trying to execute Tasks that are highly uncertain. Uncertainty, much like we did with the unpredictable in the last chapter, should be minimized. Let’s see how we do that.
So far in this series, we’ve been building a Plan bottom-up from its small components, the Tasks. We’ve explored it by minimizing the unpredictable, making sure we know what will hit us in the future so less interruptions and surprises would occur during the execution of the Plan. We’ve seen how each Task is born into uncertainty. Minimizing uncertainties, is making clear what we do, when we do, how we do and what is required to do. Various kinds of efforts are needed to make it certain enough (95% certain). A Plan, as it is a collection of Tasks, also has uncertainties to remove and unpredictables to handle. In this chapter, we’ll explore it combined.
Estimated Task to it. The gap between a Task and an Estimated task is bridged by considering variances and minimizing uncertainties. In this chapter, we’ll be learning how to actually get it done. A practical practice to uncover what is the work that needs to get done. A process which the Task needs to go through.
We finished the previous chapter of Uncovering Work with a Deliverable divided into a collection of correctly sized Sub-tasks. Such a collection is valuable to a more accurate Estimation. As the smaller and well-defined the Sub-task is, the smaller the mean and variance of the Estimation would be. Which would lead to a more accurate buffer taken, one of the outcomes of the practice we’re about to explore in this chapter.
Roadmaps have an internal contradiction. They set up a path for us to walk on, and the path always changes. If we stick with the Roadmap’s planned path and not walk on the actual path we lay, we’d end up at the wrong rabbit hole. Because on every step we listen to every Feedback given after a Change, the path changes while we walk on it. We Deviate from the original planned path. And the ever changing path is the one we should walk on, in order to get to where we are supposed to be.
In this chapter, we’ll explore this Non-Roadmap. Through the consequences of having one v.s. non, we’d try to better understand what a Roadmap is, when is it needed and why.
Roadmap, we commit to an estimation of it. But the longer the Roadmap is, the more uncertain it is. Thus commitment lays the seeds for future disappointments. And when it occurs, and we know it will occur, a Deviation triggers an already laid disappointment. Let’s see how those can be reduced and avoided.