Quick wins: don’t we just love them? Those moments in which the IT can shine and show off their capabilities. With a minimal effort we can produce real value.
Well, that’s at least the promise and it reminds me of the proverbial „quick lunch“. Let’s dig a little deeper.
Principally speaking
Principally speaking, business value should drive prioritization. So, if there is a feature right at the top of your backlog and it turns out to be cheap, then by all means go for it. But this is rarely the case.
So, where do the quick wins originate? Oftentimes, it starts with a developer who has spare time and the perception that maximum „resource utilization“ will lead to maximum value. This starts the search for features or bugs with little implementation effort. Business value is clearly no longer driving the process and trouble has started.
In that search, the concept of cost is too narrow. The developer only sees his/her implementation effort — the decision to pursue a quick win tends to be a lone decision. The efforts for testing, deployment and maintenance are disregarded. A system-wide approach might lead to other results but then the developer would not be busy.
Do we always have to follow principles?
Consider the agile mantra “The leaders manage the principles and the principles manage the team“. What if your team does not value principles, especially important ones like to always deliver business value?The team, in my eyes, is unmanaged in that respect.
If we only talk about a few quick wins per years that shouldn’t be too bad. But if it has become an established (mal-)practice that developer wait times are filled with quick wins then your team has definitely left the golden path.
Quick win thinking in action
Let’s look at a real-life example of a 20-person developer team that I had begun to coach in 2019. We had just set up a physical Kanban board on which we tracked user stories and production issues. The user stories were kept in JIRA so we already had some prior knowledge of the WIP („Work in Process“). The team had about 30-40 user stories in active development. The surprise came when we made the production issues visible. At any time there were about as many production issues being processed — and that regardless of their priority. And while the user stories were finished at a rate of only a few per week the production issues had a much higher completion rate. After a few weeks, there were more than 100 resolved production issues and only about 20 completed user stories. The developers it turned out used any wait times they had to work on production issues. The direct response of the project leads to this observation was to triage and to then route only the most important production issues to the product backlog.
How do we change?
If your team uses quick wins, try this next time a quick win comes around. Propose to not implement the quick win and present some of the above arguments and see what happens. Try to instead focus on resolving blockers (nobody likes this but it’s still useful), helping a peer, doing a couple code reviews or even documenting the last user story.
Links
A nice discussion of the “quick lunch” can be found at Wikipedia: https://de.wikipedia.org/wiki/TANSTAAFL
