Kanban, Lean and Agile mysteries
Just got back from DARE conference in Belgium. I don’t know how Maarten makes it happen, but I always leave with more ideas than I had when I came.
I ran a session on visualization – highlighting our brains limited capacity capture and record knowledge (and what to think of when using visualization).
An amazingly interesting subject. I also introduce five lenses to visual work which (you as coach) can choose to apply in the order the organization is capable of learning from it Room was packed which always warms a presenters hart.
Enough talking, here are the slides!
Let me introduce a tool I’ve found useful – Concepts.
Concepts is a one page specification, in A3 format that represents a product idea of feature. It is enough to enable a prepared conversation with the engineers developing the product. Think of it as a “flexible minimum specification”.

The idea
The concept owner is a person passionate about the idea, regardless of role, who works to realize the product idea all the way to happy client.
There is no handover.

Concepts helps you
- Treating post release challenges as part of normal design
- Decrease friction between business and development by setting clear expectations of what should be prepared before entering into conversations with developers
- Develop a minimum specification, flexible for your context
- Increasing the value added time of your development team by training business people to arrived prepared with the right questions
- Increase learning by completing the feedback loop all the way to customer use
- Sharing the work load of a product owner onto a team
- Lower waste:
- preventing ideas with unclear value (hidden in big requirement documents) to enter solution design,
- less rework after release “bugs development should have foreseen”
- avoiding heavy documentation in the early stages of product development when uncertainty is at it’s greatest
Companies have used concepts to:
- Keep a single thread all the way through to working at client
- Help product owners spend more time with real users
- Solve product owner overload scenarios
- Remove handovers
>> Download the full article
Here are some Concept section examples
(A shortlink: crisp.se/concepts)
Added a visualization combining architecture with progress follow up for more complex product development scenarios.

You’ll find the complete collection of boards here!
Cheers
Mattias
Bug lists have the potential to consume a lot of your organizations effort. Bugs drive re prioritization, dispatching, reporting, followup - even though they might be of one time nature and random occurrence. Whenever I encounter a huge bug list is to I ask which of these the organization will fix the upcoming release and then why they care about tracking the rest.
Over the years I have gotten a number of different answers to why the huge bug lists is maintained. I’ve found that many answers are really confusing the original purpose (to fix it) are with something else. An example can be mixing the purposes of “learning what provides a top notch service from the eyes of the customer” , “fixing the damn thing” and “tracability” – then attempting to provide answers to all of these above from the same tool.
I’ll share some of the dual purposes with you to provide you with some simple litmus tests. Each the well intended purpose below have better solutions.
- For keeping track of product limitations
- Awaiting and aligning prioritization (to be done later since organization units use different prioritization schemes)
- For reporting without action
- For maintaining traceability although we do not intend to fix it (ever)
- For dispatching to the right team
- For learning about frequent reoccurring sources of problems (this can be done outside the bug list)
- For pleasing every customer/user (some have marginal value)
- For maintaining pressure on the organization (political motives)
Hope it helps!
/mts
Can you run a conference where every presenter has to present using code? Why not! Meet ITAKE (Bucharest, ay 30-31). A coders delight.
Our friends in Eastern Europe, Mozaic are trying out a new conference format where each presenter has to present using code. Gotta love initatives like that

Kanban and Scrum book is now available in Swedish translation, you can download from InfoQ here
Thanks to Johan Natt och Dag!
February 25, 2013 – 5:21 pm
In software, one of our favorite tool to deal with uncertainty is iterations. But is it always the better option?
The last week I’ve got the question two times of how to address critical in deliveries from subcontractors. For example: hardware, preparation of land, machinery, buildings or third party platform updates. How can these be addressed? Do iterations hold the answer? Are there better options?
Let me introduce lean flow thinking and show how it can be used to improve the outcome of critical third party in deliveries in your projects.

read more »