Back when I studied, I worked part time in a local store. I was responsible for juice, soda, beer, wine, and other bottles of alcoholic drinks. I was responsible to order them, and to manage and refill remains over the week. Being a small shop, I also needed to be a jack of all traits. At times I had to have an eye on refilling vegetables, and fruits. At other times, I needed to refill milk, or answer inquiries from our cashiers. That said, there are some lessons I learned in that shop that helped me find my way once I joined my first job. Here are some nuggets from that time.
Continue reading Software lessons from a supermarketCategory Archives: Kanban
Process in Kanban
Something bothers me for a while about Kanban. These thought re-awakened during James Bach’s keynote at the Let’s Test conference in May. James was talking about the 1990’s movement into process. Processes needed to be everywhere. That’s why he became engaged with what turned out to end as the context-driven school of testing. Here is a quote that I heard in one form or another from the Kanban community:
The process needs to be defined, published and socialized — explicitly and succinctly.
(I got this from here.)
The Kanbanistas keep on confusing me with this. Here is why.
Continue reading Process in KanbanThe Satir Change Model and Kaizen
Right before Christmas I crossed a write-up of Al Shalloway about Kanban being the integration of Deming, Ohno, Goldratt’s Theory of Constraints, Satir and Nonaka. At a similar time I finished Jerry Weinberg‘s most recent book Experiential Learning Volume 3 – Simulation. Jerry explains the Satir Change Model in such a great way, that I would like to elaborate a bit more on the relevance of the model particular for Kanban.
Continue reading The Satir Change Model and KaizenTell a story at the daily standup
Yesterday during my keynote at the Agile Testing Days 2012 I said I see a lot of standups, where testers report on their yesterday’s work in the following way:
Yesterday I tested the thing with the stuff. I found some bugs, and filed them. Today I will test the foo with the bar.
I think this is horrible test reporting. While concluding the fifth beta of Elisabeth Hendrickson‘s upcoming book Explore it! I found a few more hints in the same direction. On the same line I will relate good test reporting during the standup to what for example Michael Bolton talks about when it comes to test reporting – we should tell three stories during test reporting:
- a story about the product
- a story about testing
- a story about the process
Lessons from complexity thinking
While Diana Larsen was in Germany in July she spoke about a course she was currently taking called Human Systems Dynamics. Since then some of my colleagues started to dive into it. So did I. I didn’t take the course, but decided to go for some of the books on it. The first one I came across is called Facilitating Organization Change – Lessons from complexity science, and deals with a lot of stuff on complexity science, self-organization, and how to introduce changes in a complex adaptive system (CAS). These are some of my first thoughts after finishing the book.
Continue reading Lessons from complexity thinkingImprovement vs. Radical Change
In the Kanban, Scrum and Lean hemisphere there is a continuous discussion about the radical change nature of Scrum vs. the evolutionary change method of Kanban. Both are often referenced as Kaizen or Kaikaku in Kanban. But what’s the difference? When do I need one or the other? And what does this say about change in general?
Kaizen
Kaizen is about improvement. Retrospectives in the Agile methodologies help to foster continuous improvement. After a limited time the team gets together and reflect on their past few weeks. In the original methods retrospectives where bound to the iteration limit, like one to four weeks. With the aspiration of iteration-less methodologies like Kanban retrospectives get their own cadence, and don’t necessarily fit the planning boundary.
Retrospectives help to improve one to three things that didn’t work well. Ideally applied the actions from a retrospectives help to change the development system just a little bit. In complex systems such changes may have unpredictable consequences. This is why we restrict changes to one to three items. If we try to implement more changes at a time, we are likely to completely turn the underlying system around, thereby getting an unpredictable system.
Over time such little changes eventually lead towards a system which gets stuck. If you keep on improving a little bit time after time, you climb yourself uphill towards a local optimum of improvements. Once you picked a particular route on that journey, you might find yourself on a local optimum besides too higher mountains. But how do you get from your local optimum to a higher optimum?
Kaikaku
This is where Kaikaku comes into play. If you got stuck in a local optimum, you may have to apply a radical change to your system in order to improve further. This comes with a risk. Once you set up for a radical change, you will get another system. Like introducing Scrum to most organizations comes with the effect of radical change. Where does my project manager belong in the three roles of team, ScurmMaster and ProductOwner? How do we integrate our testing department into the development teams? These are rather larger steps.
Comparing this with the landscape of mountains, Kaikaku is a large jiggle, like an earthquake, which might throw you onto a completely different area of the landscape. This might mean that you find yourself on another mountain top afterwards. This might also mean that you find yourself in a valley between two larger mountains. This might also mean that you end up in the desert of the lost hopes.
This also explains that too much radical change eventually leads to an uncontrolled system. Since you keep on jumping from left to right, you never settle in order to get a stabilizing system in which you can apply smaller improvement steps. In fact your system might totally collapse by too much Kaikaku.
This also explains that you should seek for the right mix of smaller improvements and larger radical changes. Once you get stuck, try to reach for a larger step, but just one at a time. From that new ground start to go uphill again by taking smaller improvements – one at a time. Over time you will eventually end up within a system that is continuously improving itself.
Kanban in German
Today I attended a presentation for the German edition of the Kanban book by David Andersen at the Lehmann’s book store in Hamburg. My colleagues from it-agile, Henning Wolf and Arne Roock translated the English book to German. They gave an introduction to Kanban, and answered some questions from the roughly 100 attendees.
