How we apply the Kaizen philosophy to reduce technical debt @ Whoz

Yeah I know, the steps are the only link between the image and the topic. Fair enough.

The kaizen philosophy says that a little change every day can drive a bigger change over time. If you do something 5 minutes a day, after a year that’s 30 hours combined!

At Whoz, we dedicate 17 minutes per day to reducing technical debt.

Technical debt is better defined with a couple of examples:

• “That piece of code is not perfect, but I guess that’s fine as we do the same thing elsewhere anyway”
• “I am sure that technology is the right choice, you’ll see in 5 years everyone will use it”
• “I should do it in a better fashion but I don’t have time”
• “We’ll see when we get there”
• “I really need to have that special type of visual component, I can’t use the existing ones”

Like any software company, our brilliant (and modest) team of developers has technical debt. And a few months ago, we decided to tackle part of that debt by setting up a recurring daily meeting we call ‘Daily Tech Standup’.

The front-end team for example would get together in a Meet conference room (always the same one) every business day between 9.11 am and 9.28 am. On the first day of the sprint, we define what will be worked on during the sprint, and every day we each work on a ticket (or collaborate on the same one).

Our backlog is made of tickets like:

Those things would be either too expensive to place in a sprint, or would usually require to be bundled to be big enough to enter a sprint. Also, some tickets would drive a developer crazy if done in one go (like rename a thousand files). Finally, going step by step allows us to learn and improve our methodologies, making the last sessions way more efficient than the first ones.

Those daily meetings also have three benefits:

• as a remote team (#covid) we like the social interaction of seeing each other every day
• having such a backlog allows us to quickly capture tasks during coding sessions & deal with them later (“did you see we named that task ‘undefined’? Isn’t that an issue?” “Yes definitely, let’s create a Daily Tech ticket and move on”)
• that is often the only opportunity to discuss with the design team on the components

We really believe such meetings are beneficial to the team and the product! However there are a couple of errors you need to avoid (we did them) when it comes to Daily Tech tickets :

• they should have the right size: it is either really big and can be split easily, or it is small enough to be done in one day (or a couple)
• they should not require brainpower. You should be able to do it while chatting with your colleagues
• they require review and testing, like any work done on the product
• they should not be used to secretly develop something that was rejected by the Product team
• they should not be considered as free, they still take time and energy from the team
• they aren’t the last touches of a too expensive story (“Let’s do the story during the sprint, and you’ll finish up the details during your daily tech” is a no-no)
• daily meetings should be compulsory, not optional

I just looked at the backlog, and we should be done by 2035, 17 minutes a day. See you there! #kaizen

🙋‍♂️Final note: my introduction could lead you to believe we only dedicate 17 minutes a day to reducing technical debt. That is obviously not true, we undergo regular and massive work to reduce debt.

❤️ Another final note: we hire talented developers! We don’t have ping-pong tables and free meals but we do have interesting challenges & tremendous potential.

Originally published at https://siebmanb.medium.com on January 22, 2021.