We started the previous chapter by trying to figure out how The Wheel of Change was born. We ended by realizing how important it is for it to keep spinning in order to not cause delays to meet business needs. And we do so by making sure to deliver fast by delivering small. And as Change entails Feedback, it would entail we’d be getting back a small Feedback. Which would entail only a small Change.
In this chapter and the rest of the series, we’ll be talking about how these insights affect our day-to-day work, what challenges they present and how to overcome them. We’ll dig deep into Planning and Sprint Planning in a future series, but we can already easily understand the consequences of The Wheel of Change on it. Because now we already know better, we know what happens right after a Change.
Plan for Feedback
At RapidAPI we were committing to external customers, large enterprises. Management wished to make sure we also internally meet these commitments as well. To ensure and follow up on it, we measured predictability: what we commit to at the beginning of the month, would be actually Done by the end of the month.
It impacted me as a group manager. I needed to make sure the next Sprint Plan would be ready before the current Sprint ends. And make sure both are fully delivered as promised – to set and meet our customer’s expectations, both in Deadlines and value. But there was a problem.
Sprint X was fully done and delivered mostly with zero errors in tests and monitoring on Sunday evenings, because Israelis work on Sundays. The next day, on Monday morning we would start working on Sprint X+1. Problem was that Feedback started rushing in half a day afterwards, when our customers in the US East Coast woke up. Those on the West Coast woke up another half day afterwards.
We got Feedback because Change entails Feedback, as it’s supposed to. It could have been a small Feedback, but it could also have been that we have worsened the experience. Sometimes dramatically, either due to a UI/UX Change or a technical one. It happens, but Feedback also entails another Change. And by the time we knew what and how to Change, we were already a few days deep into Sprint X+1. And that’s Ido being frustrated, because out of nowhere the Task was no longer Done.
The plan of Sprint X+1 was interrupted during execution, which lowered our predictability score. Sometimes the interruptions were so big and frequent that planning for Sprint X+1 ended up being a waste of time. We couldn’t fully resolve the problem but we took some actions to reduce the odds of it happening.
In Israel, deployments were moved away from the Sprint’s end on Sundays, to the previous Wednesdays. The Sprint’s end itself was moved to the end of Monday. It has given the US product team a buffer to get customers’ Feedback, and to plan the Change required. By then it would be the weekend in Israel, so it was their responsibility to make sure to leave the Israeli team exact instructions on what to Change. In Israel we had both Sundays and Mondays to execute and deliver it by the Sprint’s end as promised. And as we got Feedback, we ended up with a more satisfied customer.
And once we switched to Kanban there were no more Sprints to plan. The problem had kind of gone away eventually on its own.
Plan for Change
Another measure we took, that applies to Kanban as well, was to add a Sub-Task to each User Story, named Product Change Request. As Feedback entails Change, it was almost always indeed done. The odds of getting Feedback that requires a Change is higher than getting a Feedback saying everything is 100% okay. As such, it’s better to take it into account in advance.
The sub-task was estimated at 1.2 days, a weighted PERT calculation taking high variation into account which we’ll dig deeper into in the Committed Planning series. If we were lucky to end up with no Change required after a Feedback, no harm was done. The work is never done. As the Sprint X+1 plan was ready for execution, we just nibbed a Task from it, and started working on it earlier than committed. I never heard anyone complain about work starting earlier and and finished before the Deadline.
Lastly, we’ve shortened the internal Change–Feedback process. The faster engineering can give the product manager something to “play with”, the faster a PM can have Feedback on it, as they have proper tools and methodologies and access to external customers (more on this in the follow up series of The Wheel’s Feedback). We wished to code less, in order to gain smaller Feedback and sooner.
To do so, we needed to iterate with smaller Changes, and to better plan for it. The User Story remained the delivery unit to the customer, but we’ve divided it into Deliverables and complete sub-tasks. Almost on a daily basis, at least one sub-task was deployed to a QA environment for a PM’s inspection. [More on this in the Committed Planning series]
As the PM’s designs were quicker to be fulfilled, PMs could sooner interact with it. By itself, it caused us to avoid executions of valueless tasks. Not less important, a more refined version ended up being delivered to our customers. Feedback continued, which is good, but Changes were less required and were smaller. Lastly, Ido was less frustrated. And I was happy we were more predictable. Everybody won.
In the next chapter, we’re going to talk about the spin itself. On controlled and uncontrolled spins.