Retrospective on My Version of Lean/Kanban

Hello reader, today I’m doing a retrospective on the lean/kanban software development process that I used with my team during my 7 year tenure as a team lead. This process is one I customised iteratively over my time as a team lead after reading many articles and posts on other’s experiences with their software development process. I hope that this article can also help you in refining your software development process!

So what is a lean/kanban software development process? I can only give you my understanding of it which is likely to differ from yours and what the “official” definition is. This is okay as this is a retrospective on the process that I used, not a retrospective of a process that I never followed!

To me, a lean/kanban software development process encompasses the following points:

• Focus on delivering work - half finished tasks have little business value
• Each engineer on the team is restricted to a maximum of one or two unfinished tasks at any time
  • If the task is blocked on external factors, the engineer should use this downtime to assist externally to unblock the task, work on technical debt and/or do some personal or career development.
• Tasks should only progress forward. If a task needs more work, then deliver what is already done and create a new one for the remaining work. This means that complex work is often structured such that it can be incrementally delivered.
• Use a kanban board to visualise and enforce the process. A kanban board has columns representing task status and cards representing tasks. As a task progresses it will flow from left to right on the kanban board.
• Short (less than 15 minutes) daily stand-ups to ensure that everyone on the team knows what everyone else is working on.

The following were also some things that I did to customise the process:

• Stand-ups are summarised in a text post in our team chat
• Stipulated to the team that if they were looking for work to always pick the task at the top of the TODO column, since that column will always be ordered such that the most important work was at the top.

Retrospective - What worked well

Stand-up Summary Post

• No one needed to remember what was talked about in stand up since it was summarised in a text post
• Others in the company could follow what was going on in our team without having to make time in their calendar to attend the stand up
• Stand ups are now searchable because they are a text post in our chat

Always Choose From the Top of TODO

• Team didn’t have to ask me all the time as to what to do next
• Removes hesitation from juniors and intermediates when picking up complex tasks, allowing them to gain valuable experience.

Easy to See if Too Busy

• Kanban board was a great way to visualise how busy the team is. If it looked like there was too much work then I was able to take steps to manage it.

Downtime for Engineers Built In

• Because of the task limit and the fact that most tasks are generally externally blocked waiting on something (like code reviews or deployment) an engineer has the opportunity to do things such as clean up tech debt or personal/career development

No “Sprinting”

• Tasks are not expected to complete within a set cadence, which reduces stress on the engineers who are working on the task.

Retrospective - What did not work well

TODO List Could Get Stale

• The TODO list needed to be constantly reviewed, reordered and trimmed, especially as new tasks come in. This took a lot of time and I had to juggle this with my developmental tasks. It was a lot of work and a lot of context switching which I did not enjoy. Hence why I stepped away from a team lead (see here)

Stuck Tasks

• Some tasks seemed to get stuck in a certain status for one reason or another. I should have spent more time in trying to prevent this as it’s generally a sign that a task is too complex and needs to be broken up but I was juggling developmental tasks as well. Another reason why I stepped away from a lead.

Retrospective - Final Thoughts

I really like the lean/kanban process. It’s focus on task completion is really nice and the limit of work means that no one person will ever be overload with lots of tasks. I hope this retrospective gives you, dear reader, some ideas that you can use when refining your software development process.