“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 could truly relate.
I remember when I was working at Wiser, we were constantly getting more work and work done without an end in sight. Another component to code, another feature to deliver. But even after a perfectly done execution, a week or two afterwards a Change was needed. It could have been just a small bug to a specific client. Or that we haven’t entirely 100% resolved what the company is still continuously trying to resolve. The need was not yet fulfilled.
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.
Agreement of Done
A sense of continuation and achievement is extremely important to every living being. Because the opposite of it is the sense of standing still and it creates frustration.
Let’s recall our sense of frustration when we see a Task on our Agile Board in the state of “In Progress” for an entire month. Multiply it, as it happens every morning for 20 work days a month. In every daily standup, we find ourselves explaining to others why we haven’t got it done.
So, a frustrating Agile Board looks like:
It’s state could be because of an unexpected complication; plainly waiting for a final green light from the customer; or because we deploy only once a month. Although the reasons are valid, it frustrates us because the Task is assigned to us. We are the ones who still haven’t got the job done. And by the end of the month we look back on what we’ve done, and the Done column is empty. Not only do we have no sense of accomplishment, but frustration out of no-accomplishment.
At RapidAPI the PMs (Product Managers) and engineers had a very different Definition of Done while working on the same Agile Board. The engineers had a technical one – once the code was deployed to the production environment without issues and no more reverts needed. Ido would then take the Ticket and move it from “In Progress” to “Done”.
A week later we would wake up one morning and the ticket was mysteriously moved back from “Done” to “In Progress”. There was also a mysterious comment saying “this should have been otherwise. Change this as soon as possible please”. It was because the PMs had a completely different Definition of Done – when the customer is finally satisfied. The conflict between the Done Definitions is why Ido has always kept saying “I’ve moved it into the Done column, why are we still working on this?!”.
Tasks have to be correctly put to rest, agreed on when to put to rest and continuously be put to rest. That is why planning is so important. We’ve just seen the frustration it can add to a company’s culture. In this book, in the series of the Wheel of Change and the following ones, we’d be learning how to be better planners, to help us help others work with a sense of ease. Specifically, we’d learn how to correctly divide our work to get a board with a sense of accomplishment, such as this:
There is no Done
I’ve seen and managed several Agile Boards. I’ve seen a lot of Tasks moved to Done. I’ve seen lots of people get the job done. But the one thing I’ve never seen in my life is the work done. I’ve never seen the end of it. We get the work done, and there is always more work to get done. Well, except for when a company shuts down (s**t happens). Have you ever wondered where work comes from? How are Tasks born?
In the beginning, there was the entrepreneur. Hopefully one that read The Lean Startup. He woke up one morning with an idea (Event). He wrote it down on a piece of paper (Task). Asked a friend for an opinion (Feedback), and fine tuned the idea (Task). He cut it down to 20% for an MVP (collection of Tasks), and the rest was labeled version 1.1 (first Tasks in the backlog!). He then executed the first task of the MVP, ending up with a deployed website doing just one thing. And on the 7th day he rested.
A week later he got an email from a promising customer (Feedback), saying that the website does not load on his iPhone (Task, first Bug ever). The entrepreneur who turned into a founder fixes it. A month later he got an email from his 10th customer asking for the one thing, to also do another thing (Feedback).
The founder thought it through and did as the customer asked (Task). He deployed the website’s new version and a minute later got an alert from Pingdom that it is down (Feedback). The founder fixed the little bug he himself created (Task) and redeployed. And on the 7th day he rested.
On the 8th he got another Pingdom alert (Feedback) and the cycle started all over again. A month later he got another email from his customer (Feedback) and the cycle started all over again. Six months later the business grew to 100 customers. The not-so-important tasks of v1.1 grew important with the business. The newly hired product managers & engineers has picked up the first task of v1.1 and started working on an MVP.
Turns out it somewhat increases the company’s main KPI of Customer Lifetime Value (Feedback). The company got emails from 10 customers asking for this and that (Feedback). The metric of “Clicks on the Buy Button” shows the MVP has only scratched its potential (Feedback). And the cycle starts all over again.
5 years later with 10,000 customers, some of the smallest once worthless Tasks/Features in the backlog, are now full of potential. And the cycle continues. 10 years later, a mid-level manager wakes up one morning with an idea (Event). And the cycle starts all over again from the beginning.
We will model, visualize and explore this story. Which we’ll do throughout this series to gain many insights and outcomes out of it. Starting with recalling that every Task can be generalized to a Change, as all of our work is to Change. Let’s then call this model The Generalized Change-Feedback Rabbit Hole of Decaying Value, or T.G.C.F.R.H.D.V. (T.M.) for shorts. Or The Wheel of Change. Because it’s more catchy.
We might have had a misconception about where Tasks come from. Tasks aren’t born of Tasks, not out of Changes. They are born out of Events, mainly Feedback ones!
We can already notice the relationship between time and value, which we will further discuss in this series. A Task’s value can decay with time (it’s not so important to do that right now). On the contrary, its value can also grow with the business which grows with time. What wasn’t important to scale last year with 100 customers, is anticipated to be critical with 1,000 customers and we’ve reached it today. A 1% increase in “Clicks on the Buy Button” metric, was worth only 100$ a day when the company was small. As the business grew, a 1% value could grow to worth $10k a day.
Visualize in your mind, that as the company grows, we are zooming in further and further into the wheel. When zoomed out, the wheel’s long tail seems made of small Changes. As we zoom in with the growth, the tail is still long but the head grows bigger. So it is no wonder that even though we continuously move Tasks to the “Done” column, we never get the sense the work is done. Because it doesn’t. It never is. We are never done. Change entails Feedback that entails Change.
In this series, we’d be centering on the Change. In the followup series we’d be centering on the Feedback itself. Which are both together the basis for the third series on Planning. But before that, in the next chapter we’re going to pause and wonder – has it always been like this?