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.
Already a Prophet
We’ve already learned of some predictions that we can do. The Wheel of Change predicts that Change would entail Feedback and would most likely entail another Change. We leveraged these Predictions into Planning for Feedback and Planning for Change. They make us better planners, because we know what to plan towards.
We can say that we’ve always been predicting, we just haven’t named it that. A PM predicts that a customer would need something, and creates a User Story for it. Timing, value and effort are uncertain details.
An engineer predicts that an application/system/team would need something, and creates a Task for it. Timing, value and effort are uncertain details. We’ll talk about removing these uncertainties in this series as well.
Some bugs are also predictable, because change has the potential to introduce Instability. We expect them to happen, we just don’t know their details yet. They are uncertain.
When it comes to long term Predictions, some of those are very technical in nature. In the book The Change Factor, we learned of several technical processes which turns applications to a Monolith, a Bundle and a Legacy. And of refactors. They are unavoidable, thus not unpredictable.
In the very same book, we also learned to uncover future problems that would eventually happen. Those too would no longer be unpredictable. Maybe these are the things we call maintenance and leave a buffer for.
So, why is it important and beneficial to be predictable? How Predictions affect Planning?
Don’t Act Surprised
The act or predicting is removing the unpredictable state of an event or a need. And we have learned many ways to invest effort into minimize the unpredictable.
Do notice that the opposite of unpredictable is predictable, but it is not the complementary of unpredictable. It’s not jsut a word play, but a way to overcome our binary thinking minds.
Predictable has a range to it. That is why we ask ourselves in hindsight “how predictable was this?”. As such, it would be easier to define what is unpredictable – if it had surprised us. Putting effort into predicting those, and we’d see those coming.
We should be surprised only by what is truly unpredictable. The funny thing is, trying to predict those who be a non-beneficial effort. It can be properly visualized with the concept of The Middle Way:
A right and beneficial effort would be to look for sources of surprises. One source could be “the business” itself. For example, If we are working for Amazon, we can not be surprised that Black Friday occurs annually. If we are working for Salesforce, we can not be surprised that salaries are paid at the end of month.
Another source could be communicating. Actively communicate with the sales team, to learn of their sales pipeline. We could predict an on-boarding of a new enterprise customer, and plan for it instead of failing to meet scale.
Actively communicate with the marketing team. There is always someone who sets a date for big marketing campaigns, which ends up with a surge in traffic that surprises us. Trace what surprises you, find your sources.
Suddenly, those would become easily predictable. They would no longer cause interruptions to the Plan and to the engineers. Predicting decreases the odds and frequency of those, which increases the odds of a Plan going smoothly.
Predictions are not made to avoid fault, they are made to avoid blame. It’s more than just saying “It was in the backlog”. Predictions are “We’ve thought it over, understood the risks, estimations and values, and we have all consciously decided not to put it on the Plan for now. We are not surprised that it has eventually happened”.
That’s responsibility, standing tall with a Prediction behind you and having everyone’s back. Because once predicted, we actively choose whether to act or not, with good reason out of conditions and necessity. Afterwards it would be impossible to argue it was unpreventable.
Truly Unpredictable
Real time incidents in a live production environment are truly unpredictable, but we need to properly define it first. These are crashes caused by events that could have been prevented, if only we had awareness they should be monitored and how. It might be a hard one to follow, so let’s walk through it with an example.
- For the first time ever our web server crashes and we have no idea why. That was truly unpredictable.
- We logged in and found out that the hard drive was full. Before doing so, we couldn’t perceive that this could happen. That is why it was truly unpredictable.
- We’ve added an agent that would warn us when it is 95% full. And still the web server crashed because we were incorrectly monitoring it, we set the percentage level too high. That’s why it was truly unpredictable.
- We’ll then set it to 75% and would get the right alarm, enough time before the crash to empty the hard drive. Now it is properly predictable.
Yes, it requires experience and expertise to know so and do so. Ignoring it would only cause more surprises, because Predictions and monitoring are tightly coupled. Both are essential to Planning, and we’d see why later in the series.
A sudden change in priorities (singular) is somewhat also truly unpredictable. But sudden changes (plural) in priorities are predictable. It would make the effort of Spring Planning non-beneficial.
Instead, Kanban methodology could be beneficial in such cases. Think of it as real-time Planning during the Sprint instead of wasting effort on pre-planning before the Sprint.
We sometimes go through chaotic times. There are some chaotic companies. It requires effort to bring certainty to chaos. Luckily, the next chapter probably has something to do with it as it is titled Uncertainties.