In this article I’m going to describe how by changing the focus of a team we can improve the way we work.

So how do we get a team to focus on the work that’s important? One way is to prioritize the topics in any conversations a team has so that the most important pieces of work are discussed first.

I coach a team practicing Kanban and every morning we have a stand up. For this we gather round the Kanban board and begin to talk about the items on it.

A typical Kanban board
We like to talk about the most important items first so we usually start off discussing the blocked items and what we can do to unblock them.Once these items have been covered we then moved to the items further down the board. We naturally start off at the left side of the board and work our way across towards the right side.

However we should ask ourselves – are stories in the backlog really the most important items for us to chat about? A phrase often used in the Kanban world is “Stop starting, Start finishing”. This tells us that our focus should be on finishing stories. To enable this I suggested we begin the stand up by talking about the items that are closest to being complete. Simply – we started to read the board from right to left.

As a result, the team became more focused on completing the items closest to being finished. By focusing in on the items closest to being completed we have seen a drastic reduction in our cycle time. This was reduced from several weeks down to 7-8 days.

Changing the way we read the board means that the last thing for the team to talk about in the stand up is the backlog and whether we could bring something in to work on. It makes sense to discuss this last in the stand up once we have a good understanding of our current state.

This change is a major factor in us thinking about Kanban as a pull system rather than the push mentality we had before.


Retrospectives: Muda, Muri and Mura

The idea for this retrospective was initially put forward by one of my managers. He suggested that a variation on Value Stream Mapping combined with Muda, Muri and Mura could potentially be a way to enable the team to look at our work from a different perspective. The overall aim of the session was to identify waste in our process. We can then focus on eliminating this waste in the future and hopefully reduce the time between initial idea and it going into production (lead time).

Muda, Muri, Mura (MMM) is one of the philosophies behind the Toyota production system ( As the Toyota blog tells us – MMM “work in tandem to eliminate waste”. Muda is a non-value adding activity, Muri means to overburden and Mura includes unevenness.

To start off the session I began by explaining MMM. I expected these ideas to be difficult to explain however it proved much easier than I imagined and the team members understood the concepts without any difficulty.

The next step was to create a stream map of our process. The idea is to understand what steps are required to put an idea into production.


We then mapped this onto a board.


The next step was a brainstorming step where the team members gathered together items which belong to each of the MMM categories. We had different coloured sticky notes for each category. The team members then took turns to put their items onto the board.

The team then grouped the items into themes.

They then voted on the theme they would most like to chat about and we managed to boil these down into several actions.

As an extension to the normal retrospective I then gathered all the data from the session. We plan to group this data with other teams who are carrying out similar sessions. This will enable us to identify any common problems which may be afflicting the teams across the organisation. We can then focus on these as areas which will bring greatest improvement to our lead time.


Overall I felt this session went well. I initially thought that the concept of MMM might be difficult to get across however the teams didn’t appear to have much a problem with this.

We had booked the meeting room for 1 hour and I expected us to complete the session within that time frame. This proved to be too ambitious and I would recommend booking this session for 2 hours.

Helping the team to focus on the entire process from the very conception of the idea until it goes into production adds a significantly different angle to the usual retrospective. I am quite confident that by working with the other teams to identify common issues we can start to have an impact on the lead time of our ideas.

Retrospectives: The Cool Wall

In the agile world we are continuously looking to improve. The retrospective is a period of time conducted at the end of a sprint to enable us to look at what happened and to identify ways we can improve. There are various techniques we can employ in the retrospective that will enable us to get to our goal, which in our case is, to identify some actions which the team can then work with which will help us to get better.
Recently I felt we fell into a rut with our retrospectives and occasionally we were unable to agree on any actions for us to help improve the team. I began to look at alternative techniques for running our retrospectives and for helping the team to think about the previous sprint from a different angle.
I came across the cool wall ( I felt that the team would enjoy this technique and respond in such a way that we would be able to come up with something useful.
I selected 20/25 different topics for the team to discuss and took the team through the process (these are listed at the bottom of this page).
During the data gathering process I noticed that the team were fairly consistent in their assessment of many of the topics. Some topics were easy to grasp and we quickly placed them on the board while others took a little bit of discussion before the team were happy. The team were a little unsure about the context of some of the topics I had chosen. I agreed that some of the topics were difficult for the team to grasp and pulled them from the list.
At the end of this process we then moved on to the discussion phase of the retrospective. We deliberately targeted the topics which had been placed at the lower end of the list. This provoked a productive discussion about these topics and we quickly came up with actions to help improve each topic.
Overall the team enjoyed this approach to retrospectives and felt that it produced new insights into various aspects of our work which we wouldn’t otherwise have seen.
I feel that this is a particularly useful technique to use when we want to analyse the broader context of the life of the team rather than focusing on the previous sprint which normally happens. While teams wouldn’t want to carry out broad retrospectives like this all the time I would recommend this technique to be used periodically to help improve more general topics. 
  1. Make sure the topics you choose are related to the team – not all topics fit all teams.
  2. New retrospective techniques will help to inspire different thought processes around your team.
  3. The cool wall is a great technique to help drive a more general understanding about the work of the team.
  4. This technique is most helpful when we want the team to think about the broader context of their work rather than focusing on the most recent sprint.

The topics chosen:

Dealing with bugs
Devops Role
Team Efficiency
Driving down on waste
Communication with other teams
Code Reviews
Investing in tech
Maintaining our codebase
Time keeping
Investing in process/tooling
Story granularity
Keeping a clean build
Asking for help