Using a simple kanban to run effective meetings and workshops
I’ve found using a kanban a productive approach to structuring and running meetings, workshop and presentations. Many meetings or workshops are often run from a fixed schedule that isn’t easy to update or change and also isn’t visible to the participants. I wanted to find a better way of structuring the day which balanced some competing goals:
- Allow participants to take as much responsibility as they were comfortable with adding, removing or re-ordering the topics covered.
- Acknowledge that as a content expert on many of the topics it’s appropriate for me to offer suggestions about which topics are likely to be most relevant, and the order and approach to presenting them.
- Find an approach that addressed the previous two goals without spending longer than necessary talking about the process during the meeting.
The solution I came up with was to use a simple kanban system of post-it notes. UPDATE: I’ve blogged a few improvements on using a simple kanban to structure meetings
Here’s how it worked:
- At the start of the day I presented a list of topics/activities we could cover in a suggested order with suggested timings (e.g. 30 mins) in a “to do” column. At this stage there was an opportunity for the group to add or remove topics or re-arrange the order.
- I introduced a “doing” column with a (work in process – WIP) limit of one topic at a time. When we decided to start a new topic there would be a quick discussion about how long we wanted to spend on the topic, which we wrote on the post-it note.
- There was an exit criteria on the “doing” column, so that when we reached the time agreed we stopped and asked “is everyone happy to move on?” before it could move to “done”. This encouraged a focus on the coming to a close on topics before starting new topics (“stop starting, start finishing”)
- If anyone wanted to continue then they had the option of creating a new post-it note that could be added to the ‘”to do” column that could be chosen to continue.
- We then went to the “to do” column and checked if anyone wanted to add a new topic, re-arrange the list of topics and most importantly, decide which task to start next.
There were many benefits from using this approach:
- It allowed the participants to take as much of responsibility for what we talked about as they wanted and left open the possibility for them to take more responsibility at each “which topic next” decision point during the day.
- The list of ordered “to do” topics was visible throughout the day, so people could make more informed decisions about which topic to start next. Nearing the end of the day it helped the participants focus on spending their ‘time budget’ on topics they thought most valuable.
- The overhead of this approach was minimal.
- Discussing how long the group wanted to spend on a topic helped me gauge how valuable the topic was. In one situation participants asked for a 10 minute overview of a topic which really focussed how I presented it. We also adopted the practice of asking someone to say what was most important about the topic, or what the key outcome they wanted from a topic was as the topic started (similar to defining the success criteria on a software development task)
- It gave people an experience of working with kanban that increased their understanding of the approach.
- Whenever discussions went off-track we stopped and asked “do we need to add this as a new ‘to do’ topic?”
- Rather than having to structure the list of topics at the start of the day, when we have least information about what will be useful or interesting to the group, we were able to defer this decision by making lots of smaller “what’s the next most important task to begin?” decisions as we went.
I’ve used this technique several times in workshops and meetings and continue to find it helps increase the productivity of the meeting by ensuring the group are engaged in discussing exactly what they want to talk about for the time they want to talk about it. Have you used a similar approach? What’s your experience been?
Thanks to @HakanForrs and @YuvalYeret for discussions about Jim Benson’s Lean Coffee format which inspired my approach.
How three forks on a hand-drawn chart helped a team improve
After visualising the workflow of a recent client’s software development process, and showing where the work was, the team realised there was a queue of tasks that had been developed and were waiting to be validated (‘tested’). The team decided to move from a “I just do my task” approach to a “whole team” approach where they focussed on making a single task flow across all of the development process with minimum delay. They decided that rather than continuing to do more development and hoping that the validation work would eventually complete, the people who did development would go and help those who were validating the work.
The problem was that the Development Manager (who believed his role was to maximise the number of development tasks completed) was concerned that if the development work stopped to reduce the queue in validation, then eventually the validation step might run out of work to do.
In order to address the Development Manager’s concern we went to the hand-drawn cumulative flow diagram (sometimes called a finger chart). The cumulative flow diagram was drawn each day, by the team member who ran the daily stand up, by simply counting the number of tasks in each stage of the workflow. The x-axis shows time in days, and the y-axis shows the number of tasks in each step of the workflow.
As we had a couple of weeks data it was possible to extrapolate the rate at which the validation work was being completed. We were also able to extrapolate the rate at which development work was finishing. In order to do this extrapolation we grabbed the nearest straight-edge items we could find, which turned out to be forks!
As the photo shows, the forks indicated that it would take about two weeks for the validation step to run out of work to do if most of the people doing development spent their time helping do the validation. This data allowed the Development Manager to feel more comfortable about allowing the strategy a shot for a week, after which it could be reviewed.
This example demonstrated the benefits of using quick, low-fidelity data collection methods. The discipline of hand-drawing the chart each day meant that it was better understood by the team members than if it had been automatically produced in an electronic tool. The team were also able to see how the data could be valuable, as it allowed them to discuss the Development Manager’s concerns with data rather than just opinion.
In the end, the strategy to work as a whole team and focus on the validation step turned out very well. The team were able to reduce the time it took to validate tasks, providing quicker feedback to development (which reduced defects), increase the amount of work they got done at the same time as improving the team’s morale.
Do you have stories of using quick, low-fidelity data collection techniques to improve team performance?
Helping overcome impediments between Managers and Agile Teams
Agile teams often experience difficulties when they have to deal with problems that occur outside the team and may require management involvement to resolve. I’ve seen several Agile teams lose motivation when they question whether managers are really committed to helping the team. Often the team struggle to be open with the manager about the perceived problems or how they could jointly come up with ways to improve the situation.
Here’s a hypothetical scenario based on my experience:
Mike, the Development Manager at a small company, asked Alice, an Agile coach, to come in and help introduce Agile to his organisation, starting with the key development team.
Alice ran some introductory workshops with Mike and the whole team. At the end of these sessions Mike told everyone “I’m really excited about the potential of Agile to help our organisation, starting with this team. I want to do all that I can to support it”
When Alice came back to the organisation a few weeks later she found that the team were beginning to express doubts about how committed Mike was to adopting Agile. Mike had stopped coming to the daily stand-ups and worse, he wasn’t helping them remove the blockers they experienced with tasks that required a specialist user experience designer in another team.
The team told Alice: “Mike’s not doing anything to remove the delays caused by other teams. He says he supports Agile, but when we need him to help us out, he isn’t there for us. Yet again, the problem is with management! There’s no point us doing this Agile stuff if we’re not supported”
Alice agreed with the team Mike’s role is to help the team by overcoming organisational impediments. She decided to encourage Mike to attend the team’s daily stand-up where she hoped he’d recognise that the reasons for blocks which were causing delays on the tasks were things that he should help with. If Mike didn’t see this for himself, Alice would then model this behaviour for Mike by asking “What would it take to remove the blockers on those tasks? Would you benefit from help on those?” If this fails then Alice would be more direct to Mike by asking “What’s your view on talking to the team about the blockers and seeing how you could help?”
What’s your view of Alice’s approach to helping in this situation? Here’s my view – I welcome your thoughts if you see it differently.
- Alice seems to assume that what the team complain about is valid – that Mike is not helping resolve the causes of the external blockages – without clarifying what the team have said or done to raise the issues they see with Mike. Alice seems to assume that the team’s complaint is valid without checking if the team have raised their issue with Mike.
- Alice doesn’t ask the team for the reasoning behind the assumptions they seem to have made, firstly, that Mike is aware that he isn’t helping them, and secondly, he has deliberately chosen not to help them out. Alice doesn’t ask the team why they seem to think that Mike has deliberately chosen not to help them. It would be useful to focus on directly observable data – what the team has seen Mike do or say that lead them to their views?
- The next question is what have the team said or done to make Mike aware of the situation? Have they been explicit and described their point of view? If not, what, if anything prevented them from doing so?
- Alice seems to jump straight to taking action to help the team out, and in doing so, taking responsibility for them, rather than discussing her approach with the team and giving them an opportunity to handle the situation more effectively.
- Alice’s choice to ‘model’ the ‘correct’ behaviour for Mike, without explicitly saying that this is what she is doing, is an easing-in approach with the manager which may be based on assumptions that the Mike couldn’t handle being told directly. It’s likely that Mike will work out that Alice isn’t being direct with him, but rather than guessing what Alice’s view is, Mike is likely to feel puzzled or confused about what Alice is holding back.
Here are a couple of suggestions for how I think this situation could be dealt with more effectively.
Adopt a mindset of curiosity
First off, it’s worth trying to adopt a mindset of curiosity rather than certainty about the team’s view of the issue and the meaning and intent behind Mike’s behaviour. It’s common for the team in this situation to believe that they see the whole picture, that Mike is either lacking the right perspective or being deliberately difficult and the team’s task is to illustrate the obviousness of their perspective so that Mike will change. A more productive frame of mind is to believe that the team see many important things, but not the whole situation, Mike may see additional things they don’t and the task is to work together to design a productive way forward.
Focus on getting directly observable evidence rather than assumptions
It would be useful for Alice to ask the team to tell her what they’ve seen Mike say or avoid doing that leads them to believe he is aware of the blockers and has deliberately chosen not to do anything about them. Getting down to the level of directly observable data – what a video camera would capture – would allow Alice to understand more about the problem and potentially highlight how the team’s behaviour may (inadvertently) be contributing to the situation.
Strive to raise the issue with the people involved at the time it happens
An effective situation would be one where the team were able to raise their concerns directly with Mike and ask if he sees it similarly, or perhaps sees something that they are missing. For example, they might say:
“On our task board, there is a task that is blocked because we’re waiting on another team to do some work for us. Our understanding of the Agile process is that your role is to help us overcome these situations. Does that match your view? If so, can we share our view about what’s causing this blockage and how we could work together with you to remove it?”
In my experience working with teams using the suggestions above has created productive outcomes even in complex situations. I welcome your experiences or views in the comments.
Hi, I’m 
Benjamin Mitchell's Blog 