“I don’t understand why this is still a thing. I’ve moved it to the Done column, why are we still working on this?!” is what Ido, a senior engineer who worked on my team at RapidAPI, used to frequently say out of deep frustration. I can truly relate. We merely thought we were done with it, but we never were. And we never will. Let’s talk about how Tasks are born and die.
Change entails Feedback that entails Change. We need to pause and ask ourselves “has it always been like this?”. So let’s take a little detour. Let’s go back to the days before Agile and get a quick history lesson.
Spinning is important to meet the business requirements. The trick to deliver fast, is to deliver small. And as Change entails Feedback, it would entail a small Feedback followed by a small Change. Let's talk practically on the day-to-day implications of this.
The spin has a speed, which can be controlled by throttling it correctly. We can speed it up and slow it down when necessary. It would require to overcome our self created inertia.
Only when a Change is done, its actual business value presents itself. From the moment of initiation to the moment of completion, a value goes through a process of fruition which ends with the actual value. The actual value and the expected value will probably differ, and both will be effected by the duration of the fruition process.
In the last chapter of this series, we're going to talk about one last property of the Wheel of Change. Sometimes we just need to know when to stop spinning it, otherwise we'll just be executing valueless tasks.
As most Changes are born out of it, feedback fuels, throttles and sets the direction of The Wheel of Change. We would only be talking about feedback caused by people, processes, communication and relationships. In this chapter, we’d first be talking about the importance of feedback itself. With stories and use cases from non-feedback processes.
In this chapter, we’d be exploring the effect of Feedback on Change. On how the right feedback at the right time leads us away from a non-beneficial Change, which then leads us away from the wrong rabbit holes. We’ll see what happens when insufficient feedback is gathered, the wrong one, or at the wrong time.
we’ve talked about what are the benefits of getting the right feedback at the right time. It prevents us from going down the wrong rabbit hole, and from wasting time on coding. Alas, there is one more thing that takes us there. And that is misunderstanding feedback. And we do plenty of that.
In the last few chapters, we talked about the importance of feedback and the feedback process. We’ll follow up In this chapter and the next, by talking about the internal feedback process, and how it changes the development process and feedback itself. As it involves the two characters of engineers and product managers, we’ll be exploring it from both their perspectives. By that, to try and reconcile between the two.