Disciplined teams strive to improve their predictability to enable them to collaborate and self-organize more effectively, and thereby to increase the chance that they will fulfill any commitments that they make to their stakeholders. Many of the earlier promises we have made work toward improving predictability. To see how to improve predictability, it is often useful to see what causes unpredictability, such as technical debt and overloaded team members, and to then attack those challenges.
Common strategies to improve predictability include:
- Pay down technical debt. Technical debt refers to the implied cost of future refactoring or rework to improve the quality of an asset to make it easy to maintain and extend. When we have significant technical debt, it becomes difficult to predict how much effort work will be—working with high-quality assets is much easier than working with low-quality assets. Because most technical debt is hidden (we don’t really know what invokes that source code we’re just about to change or we don’t know what’s really behind that wall we’re about to pull down as we renovate our kitchen), it often presents us with unpredictable surprises when we get into the work. Paying down technical debt, described by the Improve Quality process goal, is an important strategy for increasing the predictability of our work.
- Respect work-in-process (WIP) limits. When people are working close to or at their maximum capacity then it becomes difficult to predict how long something will take to accomplish. Those 2 days’ worth of work might take us 3 months to accomplish because we either let it sit in our work queue for 3 months or we do a bit of the work at a time over a 3-month period. Worse yet, the more loaded someone becomes, the more their feedback cycles will increase in length, generating even more work for them and thus increasing their workload further. So, we want to keep workloads within capacity, another one of our promises.
- Adopt a test-first approach. With a test-first approach, we think through how we will test something before we build it. This has the advantage that our tests both specify as well as validate our work, thereby doing double duty, which will very likely motivate us to create a higher-quality work product. It also increases our predictability because we will have a better understanding of what we’re working on before actually working on it. There are several common practices that take a test-first approach, including acceptance test-driven development (ATDD), where we capture detailed requirements via working acceptance tests, and test-driven development (TDD), where our design is captured as working developer tests.
- Reduce feedback cycles. A feedback cycle is the amount of time between doing something and getting feedback about it. For example, if we write a memo and then send it to someone to see what they think, and it then takes 4 days for them to get back to us, the feedback cycle is 4 days long. But, if we work collaboratively and write the memo together, a technique called pairing, then the feedback cycle is on the order of seconds because they can see what we type and discuss it as we’re typing. Short feedback cycles enable us to act quickly to improve the quality of our work, thereby improving our predictability and increasing the chance that we will delight our customers. Long feedback cycles are problematic because the longer it takes to get feedback, the greater the chance that any problems we have in our work will be built upon, thereby increasing the cost of addressing any problems because now we need to fix the original problem and anything that extends it. Long feedback cycles also increase the chance that the requirement for the work will evolve, either because something changed in the environment or because someone simply changed their mind about what they want. In both cases, the longer feedback cycle results in more work for us to do and thereby increases our workload.