My key takeaways:
- Kanban can fix problems, but not straight away
- The board will show you what your problems are, you can introduce changes and see if it improves.
- Do what helps, not hinders.
I wanted to capture the steps that John went through in the class, so this is my take in what John covered and his facilitation approach.
Facilitation & Preparation
There was really good preparation, there was a visual representation of a dummy company to stimulate conversation, there was a retrospective board, and a meeting kanban board to visualise the agenda.
Here is a sample dummy company diagram , similar to the one that was used.
This is a designed to represent a complex scenario, (feel free to drop me some comments to update it).
Lets create your board
If your going to do this exercise with a team, here are some suggested steps to take:
- Identify the business goals – Key for the product manager or owner to get his/her vision across.
- Create a shared product mission- to get the team on board, a useful tool is to create a product box. For the supplies, you can pick them up at staples along with some pens and stickers. Get the team to break up into groups of four to six (this works best with cross-functional participation). The team creates their vision of what the product will look like, with the box, decorating the front and the back, a product name, a logo, a strap line, some key bullet points to sell it, perhaps a user guide or user reviews on the back.
- Define the resources – How many people are available in each stage of the system ?
- Make the board - you will need, pens (big ones are better, people write less and bigger ), tape and a big wall. Its important to note, there is no wrong board , there is no right number of stages. You can always add more or remove a stage if they are not working for you. Some guidance would be: to add some stages if your not seeing progress on a frequent basis, and if your updating the board to much, it might be time to simplify the board. The great thing about kanban, is that the trigger points , frequency and the time spent updating, are unique to you and your team, you get to define them.
You can add swim lanes to signify groups, features or perhaps releases.
- Next value stream mapping – we did not get the opportunity to go into to much detail, but the quick version is identify how long an item of work takes, and how long that item of work stays in a stage. for more information check out the limited WIP Society.
- Review the flow - Getting flow establish is a key point. You ideally want a nice balanced flow, aligned to your WIP limits. This is not a one time activity, you will need to set your WIP, and review to see if there is flow, or any slack or bottlenecks, it may take some tweaking and time to get there. One of the benefits of flow is that if you can manage to get the requirements to be similarly sized within reason, you no longer need estimation workshops, as your predictability will come from the throughput….we do X number of items per time slice. It is an advanced technique and will require a good sell to the business, depending on your agile attitude within the company.
- Identify the bottlenecks – Now that we have the system in front of you, have a go at identifying the bottlenecks. Does the work look evenly balanced between each stage given the numbers of resources available in each stage ?
- Get feedback, fast- Kaizen, continuous improvements. Have some brainstorming sessions to identify possible solutions. A good technique is the “yes,and” technique, that comes from improvisation. The premise is that if we say yes,and that ideas will flow more freely. You might find it useful to ask one person to scribe the session, and then let the rest do the talking.
Some discussion points during the session:
For me it depends what you want your developers to spend time on. If we can get the requirements or stories into the same sized groups, ie small medium and large, then we can track the throughput, for example, 5 smalls a week, or 3 mediums. This is not to say you cant use story points, and if your teams are comfortable doing that type of estimation, then there are probably bigger issues to solve.
Based in the conversations during the session, people found that standups got shorter, and in some cases stopped, and in most cases only really focused on discussing blocking issues. This is due to the board being updated JIT, so if you want to know the current state of things, look at the board. This is dependent on the team being more disciplined then in scrum.
One of the other points made was about managing dependencies with other teams, eg what happens if you need team 2 to finish a story or fix an issues to enable you to proceed. In this case the team might nominate a representative to attend other team stand ups on behalf of the team and then report back to the team.
Bugs and defects
I like the strategy John came up with. If it’s a quick thing to fix, call it a bug. If it’s a big lump of time, call it a defect. Bugs should be fixed asap, the QA should have a chat with the dev and the dev should ideally fix it there and then. Given the limited wip, the dev will still have context. If its a defect, stick it on the backlog with the other work.
All in all, it was a great session, I look forward to more of his talks.