REPOST FROM CODEBETTER

I noticed that CodeBetter is slowing down. Maybe dying. I’m preserving my post from there, here to my site.

Original post

A couple of months ago I was very fortunate to work alongside a great team. They had a not so envious task before them, namely to introduce a new main concept into an legacy code base. You know, the code has been around for at least 5 years and now you need to add a concept that was no-one ever thought we would have in there.

They did that. In just 3-4 months and delivered with flying colors. I didn’t have much to do with that, I merely observed their work.

When they were done I proudly introduced the team to a new senior in the company and told him about their feat and how they had gone about doing it. His...

When our board is lined up as our process it’s quite often an array of columns starting to the left when the idea first comes into mind (or in a backlog column) continuing down our workflow, adding more and more value until it reaches our customers where we can learn from the usage of our new feature.

Although it could be tempting to go through the columns from left to right in our morning meeting, I would suggest that you consider doing the opposite.

• Blocked is not a column
• Todo - Doing - Done is not your process
• Done? There’s no Done
• Colors speaks volumes - use them deliberately
• It’s not a kanban board if you don’t have a WIP limit
• Walk the board from right to left
• Focus on the work - not the workers
• And for the love of...

My job is to help clients to use and adapt the principles of lean and agile to achieve a better flow of value. Sometimes I get questions from friends and old clients about how to do specific things. And sometimes I get questions from complete strangers.

Last Tuesday was such a day when Emily reached out via email and asked me three insightful questions.

I was happy to do that and my “fee” was that I can publish the questions and my answers here on the blog. So you’re reading my payment

Many daily stand-up meetings adhere to Scrum’s traditional format, where each team member reports on their activities from the previous day, plans for the current day, and any impediments they face.

While well-intentioned, this approach misdirects our attention.

Ensuring team members stay busy isn’t as crucial as ensuring work flows smoothly.

A simple adjustment can realign our focus, particularly during morning meetings.

• Blocked is not a column
• Todo - Doing - Done is not your process
• Done? There’s no Done
• Colors speaks volumes - use them deliberately
• It’s not a kanban board if you don’t have a WIP limit
• Walk the board from right to left
• Focus on the work - not the workers
• And for the love of everything holy - please tear off the post-it’s the correct way!

When Kanban emerged as a popular practice, it was often presented as an alternative to Scrum. However, as Torbjörn Gyllebring emphasized years ago, Kanban is not a replacement for your process. Instead, it serves as a tool for process enhancement, adaptable to various workflows. This adaptability is one of its greatest strengths, and it’s why I’m such a proponent of Kanban.

However, some early Kanban adopters, in their eagerness to depart from Scrum’s ceremonies, went too far and removed all constraints and trade-offs. “Kanban—love it! No planning, no sprints, no constraints—it’s just our board, and work flows as fast as it flows… Nice!” But, to be honest, a board without a Work In Process (WIP) limit isn’t really a Kanban board. Let me explain why.

• Blocked is not a column
• Todo - Doing - Done is not your process
• Done? There’s no Done
• Read More

One of the things that always catches my attention when I walk past a board is the colors of the stickies. Why? Because colors requests our attention and can help us in understanding more about a thing. Red is naturally a warning (in western culture at least), green feels ok, etc.

This is why I get troubled when I hear that the reason that we have chosen the colors of the stickies on our board is “because we took the ones that was closest to us”.

That is sad and I share a few thoughts on how to improve on that state of mind - it’s easy.

• Blocked is not a column
• Todo - Doing - Done is not your process
• Done? There’s no Done
• Colors speaks volumes - use them deliberately
• It’s not a kanban board if you don’t have a WIP limit
...

This comment is closely related to the comment about columns. In this post I’m more specifically want to talk about the “Done”-column. The last column on most boards. I’m on a crusade to rename Done all over the world.

• Blocked is not a column
• Todo - Doing - Done is not your process
• Done? There’s no Done
• Colors speaks volumes - use them deliberately
• It’s not a kanban board if you don’t have a WIP limit
• Walk the board from right to left
• Focus on the work - not the workers
• And for the love of everything holy - please tear off the post-it’s the correct way!

Let’s do it! Done-column - you’re going down!

Ok, got a few encouraging comments on the first post so I’ll continue this series. If for nothing else it’s keeping to my original blog-idea to write things down to clear it up for me and not forget about it.

• Blocked is not a column
• Todo - Doing - Done is not your process
• Done? There’s no Done
• Colors speaks volumes - use them deliberately
• It’s not a kanban board if you don’t have a WIP limit
• Walk the board from right to left
• Focus on the work - not the workers
• And for the love of everything holy - please tear off the post-it’s the correct way!

This time I wanted to talk about the column themselves, or maybe I dare to talk about the process they reflect. Our process for work!

It’s very interesting to see how a practice goes from a nice idea to best practice and over to tradition. In my community, the software industry, things move very fast so I’ve seen many examples of this; simple things like formatting of code, background colors of editor all the way to architectural patterns - all of these become default usages and tradition, and sometime “the way it’s done”. Sometimes people calls it cargo cult which refers to that I often do things without really reflecting over why.

When it comes to my field of practice; lean and agile there’s bountiful examples of cargo culting, but in this series of post I wanted to examine a few very practical things that I often notices on how agile team uses their boards.

It will be a little hit-list of my pet issues commonly found on agile/kanban-boards I’ve seen.

Scope creep is a common phenomenon in software development where the size and workload increases beyond what we first envisioned. In many cases this is so small that it happens without anyone really noticing but sometimes it can degenerate and slow down progress considerably. Sometimes even stopping a progress or team completely.

Scope creep comes from many sources, sometimes from the outside, but I think that the most common one are ourselves:

That value should probably be a configuration property…

What if someone decides to change database server…

This is of course good questions to ask and could be value, but I think there’s more value in getting a feature in front of users and learn about their behavior and how the feature is doing. After that we can harden it, make it more flexible or otherwise improve it.

Drifting away from my main topic… So now...