The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
the Ninety-Ninety rule, Tom Cargill
👹 Devil is in the details
You are agile, you are iterative, you deliver quickly.
To succeed in that, sometimes you need to make the tough choice of delivering something that is not perfect.
It breaks your heart to see your product go live without being perfect, but hey, delivering quickly and iterating is crucial, so yes, it seems like a completely valid choice.
But then, how can we deal with all the small glitches that are released in our apps? All those small details, that are nothing one by one, but that can turn your app into a sick product if you accumulate too much?
You know, all those very small tasks that should theoretically cost you nothing to fix, but the context-switch it involves is a high price to pay…
This small typo on the website that should take 2 seconds to fix, that you fix, and then have to wait for the CI to complete, you see some deprecations in the CI, you update deprecated use in the CI, thus break the CI, you fix the CI, your fix is live, you wake up and you have lost half a day. 😱
Make them go through the whole prioritization/grooming/development process?
Meh, it would require more time to talk about them than to actually fix.
Instead, why not wait until you have enough, and try to make solving them fun?
Welcome to the Polish days!
At Cheerz, we have launched what we call the “Polish days”.
No, not like this kind 🇵🇱of polish, but in the sense that you actually polish your app during this day.
Every once in awhile (~1/month), we announce a polish day. The goal? Tackle the biggest amount of bugs and small glitches we can tackle in one day.
We stop the sprint for 1 day, prepare a Jira board with all those small tasks, and have everyone in the biggest meeting room we have, in which we have the chance to still be able to approximately fit in.
The day starts, and now, the contest is live :
- Each opened Pull Request is worth 1 point
- Each fix that has been validated and merged is worth 3 points
As time moves on, we note all the scores on a big whiteboard in the room.
At 6 pm, the winner, the King of the Polish, is announced and prizes handed out.
The prize is important. It has to be good enough so that you want it, and silly enough so that you don’t really resent the game if you don’t win.
During our last edition for instance, in addition to a bottle of champagne, we offered the winner one additional anniversary: On one day of his choice, everybody in the company should act as if it was his birthday. Singing, congratulating, etc. 🎂
Plus, we hang a giant print of the winner in our office, as an everyday reminder of his glorious victory.
The only thing to be careful about is to not make the people with only a few points feel bad.
Not everyone has the same knowledge of the codebase, some people are more junior or recently arrived, and some just made poor strategic choices by picking harder or longer tasks.
This day will, of course, hugely benefits the company, but it’s also a game. And the game and its points should not be turned into a way to evaluate developers or measure one’s velocity or skills. It would be wrong, both in term of relevancy and how it could make people feel.
So far, we have heard nothing but good about the polish day.
It allows us to tackle a huge number of small problems in way less time than it could take if dispatched in a sprint. It helps us break the routine, focus and thus reduce the cost of context-switching. And especially, it helps us make the “experience debt” melt.
And all of that by having a fun day.
So why not give it a try your self, and tell us how it went?