We’ve 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, 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 know better what to predict would happen 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 met these commitments as well. To ensure and follow up on that we measured predictability: what we commit to at the beginning of the month, would be actually Done by the end of the month. The impact for me, as a group manager, was that the next Sprint Plan needed to be ready before the current Sprint ends. And ends fully delivered. To set and meet our customer’s expectations. Both in deadlines and satisfaction. 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 on the US East Coast woke up. Those on the West Coast woke up another half day afterwards.
We got Feedback because Change entails Feedback. It’s supposed to happen. It could have been a small Feedback, but it could also have been that we have worsened the experience. Sometimes dramatically, either to a UI/UX Change or a technical one. It happens, but what also happens if the Feedback entails 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 and 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 Sunday, the Sprint’s end, to the previous Wednesday. The Sprint’s end was moved to the end of Monday. That 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 Sunday and Monday 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 Sprints to plan, so 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 Feedback that says everything is 100% good. As such, it’s better to take it into account.
The sub-task was estimated at 1.2 days (a weighted PERT calculation taking high variation into account, we’d dig deep into this during Planning). When we ended up with no Change required, it was fine. The work is never done. As the Sprint X+1 plan was ready for execution, we just nibbed from it. I never heard anyone complain that work started earlier and was finished before the promised deadline.
Lastly, we’ve shortened the internal Change-Feedback process. Designs remain on paper until executed. So 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).
To support it, we needed to iterate with smaller Changes and 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 (more on this in the Committed Planning series). Almost on a daily basis, at least one sub-task was deployed to a QA environment for a PM’s inspection.
As designs were quicker to leave the paper, PMs could sooner interact with it. By itself, it caused us to avoid executions of valueless tasks. Not less important was a more refined version was delivered to the 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 predictable. Everybody won.