How Kanban visualisations and conversations enable process improvement

After deciding to adopt a new process a key challenge is to actually start doing it. This is the story of how a team I’m working with decided to carry out code reviews as part of our process, and how our kanban board helped us.

The kanban board helped us visualise this new step in our process and allowed us to see that despite our belief and enthusiasm in introducing code reviews, we weren’t actually doing them. Reviewing the board at the daily stand up meeting provided visual feedback that lead to productive conversations about what might be stopping us and how we could improve. After we implemented new behaviours the board highlighted whether we improved and allowed us to continue to monitor our behaviour.

The team’s kanban board after we’d got rid of the queues, with no cards at all in the Code Review column.

Introducing the Code Review process: a focus on ‘just enough process’

At the team meeting where we discussed a code review step we wanted to introduce ‘just enough’ process to make sure we would actually do it. We agreed to do the smallest thing that could work and to avoid being too ambitious or strict in how we defined code review. We came up with the following rules:

  • If the person worked alone they needed to ask someone else on the team to come to their machine and discuss the code.
  • The developer who needed the code review was responsible for pulling another person in to do it.
  • If two people paired on the task it didn’t need a code review.
  • If the task didn’t need a code review then the developer responsible would say so at the daily stand up and if the team agreed, it could skip that step.
We also agreed to come back in a few weeks and review whether we thought the benefits of doing a code review were worth the costs by asking the team for examples of whether code review was ‘helpful or harmful’.

What the board showed next: Good intentions were not enough

During the daily stand up meetings in the first week of working with the new process, the team reported many tasks as “finished development” when they hadn’t been code reviewed. We started moving those cards to the right of the “In Dev” column. Within a couple of days it was clear that we had a queue of index cards to the right of the “In Dev” column.

We had a brief discussion on the queue of cards to the right of “In Dev” and we agreed that it was a sign that we weren’t doing code reviews in an effective way. We said we’d focus on doing code reviews and ‘unblock the queue’ that day.

At the next day’s standup the queue was still there. This illustrates an important point; changing the way we work is hard and sometimes good intentions are not enough. At that day’s stand up meeting we had a deeper discussion about what was preventing us from doing it and identified two major issues.

The first issue was a concern about interrupting other developers. We agreed that one solution was to do the reviews directly after stand-up, since the team had all been interrupted.

A second issues was making it more obvious which cards were actively being worked on “In Dev” and which cards needed a code review. To be more explicit we created a column on the board between ‘In Dev’ and ‘Waiting for Test’ called ‘Code Review’.

By the next day’s stand up the queue of cards in Code Review was gone and we haven’t seen a queue of work build up in code review since.

Visualisation and productive conversations are key to process improvement

The kanban board showed us that our behaviour wasn’t producing the goals we wanted. Seeing this and discussing it as a team helped us understand more about what was stopping us and allowed us to experiment and test new solutions, as well as providing ongoing feedback about whether the new process step was working effectively.

What’s your experience implementing new process steps such as code review? Have you found visualising has been effective in reflecting how well your doing? Have you redesigned the way you visualise things in order to help you act more effectively? Let me know your views and experiences in the comments.

This post originally appeared on Platformability: Insight from Caplin’s tech team

Tags:

About Benjamin Mitchell

Hi, I’m Benjamin. I hope that you enjoyed the post. I’m a consultant and coach who helps IT teams and their managers consistently deliver the right software solutions. You can find out more about me and my services. Contact me for a conversation about your situation.

7 responses to “How Kanban visualisations and conversations enable process improvement”

  1. Tom Howlett says :

    Yes! I love the way the Kanban board gives a continuous source of data that can be used in effective conversations. Something I’ve come to notice is that for us many of the conversations lead us to the conclusion that we are not having enough conversations! Your example of a code review is a conversation between 2 or more developers, our usual suspects of stories backing up waiting for QA or UAT are usually solved by us having more timely conversations to help us both understand the story and what needs to be done and more importantly what doesn’t need to be done. The overall effect of this on our team has been a huge increase in the amount and promiscuity of conversations and collaboration. Software is driven by people. People are messy not predictable, conversations help us cut through that mess to get to the heart of problem.

    • Benjamin Mitchell says :

      Thanks for sharing your experience, Tom. I that you say that starting to have conversations often uncovers that “we are not having enough conversations”. That’s a good point to keep in mind.

  2. Wayne Palmer (@waynerpalmer) says :

    Hey Benjamin! When we introduced code review (after being burned by no review) we simply started meta-tagging the wall cards with a “review” tag as opposed to adding an additional column. Same effect for us, the visualisation helped the guys to see that one of the cards was “close”, which encouraged them to review and keep the work flowing to a successful conclusion.

    As I look behind me now at the wall, I can see 4 cards which have this tag, and conversations at stand-up earlier was all about getting through those reviews (using Crucible, which has been brilliant at making reviews more impersonal).

    We do not have the “after stand-up, conduct review” principle, but is something which would be hugely beneficial to help improve the flow of work across the board. Will talk to the guys about it today.

    • Benjamin Mitchell says :

      I like that you used tags on the cards as opposed to an additional column. My hope is that the code review column on this team’s board is temporary. My own preference is to have the minimum number of columns on a board, in order to encourage a focus on “what the work needs” rather than “the steps in our process”. I also like the idea of work happening in loops, rather than artificially imposing a linear sequence. In the case of code reviews for example, I like the idea that the review happens as early as needed and as many times as necessary, if that’s what the work needs.

      I’m interested in your description that Crucible (I don’t know it) “has been brilliant at making reviews more impersonal”. Could you give some examples of what you’ve seen that leads that that view?

  3. Stew Stryker says :

    You made some great points. Thanks for sharing your experiences. We don’t do code reviews but have used weekly KB reviews and queues to point out changes needed. Maybe next week I’ll start a discussion on whether some queues are regularly over-limit and why that might be?

    • Benjamin Mitchell says :

      Thanks for leaving a comment Stew. I’m glad you’re thinking about discussion why your queues are regularly over-limit. I’d be fascinated to hear more about how that conversation goes!

Follow

Get every new post delivered to your Inbox.

Join 71 other followers

%d bloggers like this: