I attended the second Limited WIP Society group @ LateRooms.com - this was in the format of an Open Space - essentially this is a conference style half hour time slots on things about Kanban and other systems thinking stuff... The tracks that I attended are below - I've tried to remember as much as possible!!
MMF’s (Minimum Marketable Feature)
This was interesting discussion - the main point was the importance of understanding what value. The definition of value must be shared between the business and development...
Other interesting points:
- Capability in order to be able to deliver a MMF – so in essence there has to be the technical ability to deliver something within a day. I.e. can you write code, test it and deploy it easily enough in a day. If you can’t then your transaction cost is too much and you are not going to get the benefit from a MMF. The other interesting discussion was about business capability – the business needs to be in a position where it can receive MMF’s and understand the impact on them.
- MMF’s are all about reducing risk, delivering value, and having a constant feedback cycle.
- Someone mentioned a graph in order to decide on whether an item is an MMF – I can’t find it at the moment.
- Alkthough it’s important to say “No” – some times its better to give people options to the business users.
- I’ve also heard of people using the following to decide on an MMF or to clear a backlog:
Somewhat unrelated but still important:
- Kanban doesn’t work with multiple delivery teams. If the team does not deliver the same thing then Kanban can’t work.
Daily Stand-Ups & Retrospectives
- The focus of the meeting should be unblocking the blocked issues – everything else is unimportant.
- Important that at the stand-up the team is protected. You need to reduce the external pressure.
- Managers have a changed role within Kanban – they have to prioritise and help to unblock issues – rather than manage people.
- The granularity of tasks is important – if the tasks are too big and nothing moves then something is probably wrong.
- The issues within the stand-up are important but the detail of the issue is not important.
- Some retrospectives should focus on analysing data others should be in the normal retrospective style – i.e. what went well, what went not too well, and what can we do better next time. It’s important that during a retrospective that everyone has done the best that they can do.
This was an interesting talk but unfortunately I didn’t take many notes. It mainly surrounded the fact that the change to Kanban is a cultural one which can be hard to invoke. Somehow we managed to start talking about The Choice by Goldratt! @wisemonkeyash talked about the glaze of resistance/layers of resistance and has posted this awesome link about why change is difficult. We started to talk about mermaids, and crocodiles! However, the overaching thing for me was that everyone is open to change it is just the way in which you invoke the change that is important. It has certainly highlighted that I need to read “The Choice” and other books – i.e. Driving Technical Change.
This was mostly inspired by the Theory of Constraints – why and how it is important to find a bottleneck. What to do with a bottleneck and other random thoughts about inventory in software development. I found this talk to be one of the most interesting because it’s a topic that I'm very interested in at the moment - for this reason I'm not going to excessively talk about it! This blog contains enough thoughts about this! It’s highlighted some interesting things about trying to elevate the bottleneck – something we are not doing at the moment.
An excellent night. I know I've probably missed some information!