There are a number of Kanban games and simulations. Some of the better known ones are GetKanban and Kanban Frog Factory. For a while I wanted to play a game I have encountered about two years ago – Kanban Pizza Factory, which seemed more appealing to me, and I haven’t had the chance to play it yet. The game was introduced by Ralf Kruse from Agile42, and what I liked about it is that it is easy enough to play, it involves something majority of people love, and it can be easily analogized to our day to day life.
So, we have decided to dedicate our 14th Agile Practitioners meeting to a brief introduction to Kanban, followed by the game. Courtesy of Google Campus Tel Aviv, the meeting was held at the 26th floor of Electra Building with fantastic view of Tel Aviv.
The Kanban intro, as promised, was very brief, with types of waste and WIP being the areas that raised most questions. Read more…
My wife went on a one week break last week, leaving me to deal with three kids and a hectic week at work. I wasn’t concerned much with the situation, apart from one thing that I dreaded: laundry.
To begin with, you must understand the laundry cycle at our humble home. Let me draw a picture for you:
Everyone in the family dispatches new laundry to the work queue. That is, my missus and I place it in agreed baskets, and the kids just happen to drop it some place around the house: bedroom, corridor, washroom (not to be confused with washing room!), backyard, kitchen table – anything goes. Occasionally kids misplace laundry and place it in the washing room itself, but I attribute it to a temporary lapse of kidsism. Read more…
There are many reasons to go SCRUM in particular or agile in general. Each organization will have their own reasons and motivations. According to the 2011 State of Agile survey, top three reasons are to increase time to market, to cope with changing priorities and to increase productivity.
The question is, how do you know that you are getting there?
The default answer for most is KPIs. Measure it, and you will know that you are there. The problem with measurements is that they are very elusive. You want to measure one thing, and ending up affecting another. Regardless of the measurement, you may impact something that you didn’t intend to.
Why is that so? This is because when you measure things, you leave a trail, and this trail is not merely the guide to go back, it is also the guide to go forward, a kind of a forecast to the next target.
In fact, a trail is more useful to going back in order to fix things, rather than to predict where to go next. Take breadcrumbs navigation: It helps you go back in the application to re-navigate; it also helps you navigate faster on successive uses of the application. But it doesn’t help you predict what you are going to do. It can help you measure what users are doing most, in order to improve the navigation. Like in Hansel and Gretel, the kids wanted a trail back home, not a guide to go forward.
Take an example. Many teams use velocity as their planning tool. They use the amount of done stuff, in relative size, in order to plan how much they can sensibly fit into the next iteration. It is a planning tool, not a measurement.
Yet, organizations try to use this velocity to do more than planning. After all, velocity can be a good measure for productivity or even predictability, can it not?
Yes, if your organization’s main business is velocity. When were you last asked by your customers: “For the next release we would like to order 54 points and 21 epics, please”? Is this the kind of predictability you require?
Check out Smith and Jones Predictable Lighthouse sketch – are you convinced that predictability is something you welcome that much anyway?!
What kind of trail can you use that will record something deliverable, and not an artificial, game-able, number that can have collateral impact that is potentially undesirable?
Let’s examine few of the options:
Velocity: Dear team, please provide more story points.
No problem, dear manager. We’ll just skip all those tests, and the number is set to increase. Given that we do not provide the support, escaping defects will be anyway handled elsewhere.
Predictability: Dear team, please provide a consistent number of story points.
No problem, dear manager. We’ll just provide the same number of points. When something big comes in, we’ll just bloat the estimate, so we don’t have to deal with breaking to smaller stories.
Cycle time: Dear team, please provide a standard ratio between points size to the time to develop it.
Now here’s a good one. Cycle time can actually be a rather useful trail. But only if you consider it from a systemic point of view – which makes it much harder to measure. Otherwise, it may become similar to velocity
The problem with all the above is that it mixes several concepts into one number. The trail and the measurement are not one and the same. This is why using points or velocity as a measurement is risky. It becomes goal in itself, rather than means to a goal.
In such a trail, for every story you specify, in business context, WHAT is the system expected to do. This specification is turned later to an executable sequence that will verify that the developed code does WHAT it is expected to do. Note, that specification by example is not about HOW, it is about WHAT.
This makes a trail of business rules that have been proven, and are now part of our regression suite, and upcoming trail that is what business rules are to be proven in the coming iteration. In an analogy to the breadcrumbs navigation, where have we navigated so far, and where are we navigating to now. Note that over specifying (forecasting several iterations ahead) is likely to become waste.
Recall from the top of the post, the trail helps you go back and make corrections. In this executable specification trail, it enables you to either fix business rules that got broken due to changes, or to remove redundant rules – and code, in order to navigate better in the future.
Coming back to measurements – this trail is not a measurement. It is a trail.
If you must measure, try to check, for example, how many routes you are navigating on concurrently. WIP can be a good measurement for that. Yuval Yeret has a good explanation of WIP and using CFD to measure it. Once in place, you can start measuring also cycle times, but as a supporting tool for your WIP, not as a guide to limit story duration.
Alternatively, try to use Agile Earned Value Management (EVM). You may read about it in Tamara Sulaiman’s article here. While Agile EVM is useful for planning against budget, it has some hidden assumptions, such as scoping for the entire release.
The merits of one measurement or the other is the subject for a separate post. I will just comment that I like these measurements more than others because a) they are good tools for decision making, and not merely measuring; and b) indeed they are based on the trail but not measuring it.
As long as you remember that the objective of the trail is to correct yourself – to make the right decisions, you will be ok. Don’t force measurements if you cannot effectively use them for decision making.
Otherwise, you may find that you were hoping for breadcrumbs and instead of SCRUM you we left with, well, just the crumbs and no trail.
As part of my blogging life, I was invited to visit Mashani Salads factory in Beit Shemesh in the county of Jerusalem. I knew the produce of this maker, and I arrived with expectations to get some good food, but I also had a hidden agenda – observe the process, and use this visit also as learning experience. Little did I know that I was going to be surprised on both accounts.
The first experience was the passion with which Zohar Cadoori, co-CEO and co-owner, talked about his company. Passion for food, and passion for high quality. His description of receiving fresh produce from suppliers left no doubt – For Mashani Salads, making good business meant maintaining high quality. They demand it from themselves, they demand it from their employees, and they demand it from their suppliers.
Upon receiving goods, the staff would prepare empty crates, and sort the produce. Anything below their high standards would go back to the supplier. That does not mean low quality produce – these are produce you and I would easily bring home. We have examined the produce in the small storage – everything was top notch. Chef restaurant quality.
When we went through the production rooms, we understood what makes the preparation process work so well – no fancy machinery, no peeling devices, no robots. The vegetables are hand peeled, the carrots and cabbage chopped using standard equipment. Eggplants are grilled manually on designated grills. No smoke extract, no flavor additives.
There is no secret to Mashani’s success, other than maintaining high quality.
You are welcome to enjoy more photos and more detailed account of the visit and the preparation process in this blog post (in Hebrew)
As the visit came to an end, Zohar invited us back to his office to enjoy a light brunch – Mashani Salads, of course, and to answer questions. He has described why he is keeping low stock levels, and that it makes no sense to overproduce and ship out a product that stood in the chilling room and potentially be forced to sell it at a reduce-to-clear price. I asked him – how do you know how much to produce? And his answer was dead simple – I produce according to the incoming orders. I know what typical orders are, and if a big order comes in, I prepare in advance.
I asked further – so what do you do if a big order comes in and you cannot deliver in time? He said simply – I produce whatever I can for a first shipment, and make the arrangements for the next batch.
It was so refreshing to hear someone so much into the process: maintain low WIP, work Just In Time, Inspect and Adapt.
I also asked about the number of products they maintain. Mashani runs a restaurant and delicatessen in Rishon Le-Tzion, where they stock about 200 different lines, some are produced in the factory, some are prepared locally, and some are bought elsewhere. However, as a food supplier, although there are about 200 items in their catalog, at any moment in time they make about 20 different products. Around 40 employees run the entire factory.
Factory? I found that this word does not fit in with this establishment. Crafts-shop sounds more appropriate. Without a doubt this company does not deserve a ‘Fordistic’ title that resembles a mass production line. This is a lean operation, focused on making customers happy, rather than a fancy technological make-more-money concept or increase-shelf-life-over-quality approach.
I have no idea whether Zohar or his management team has done some proper process optimization courses. I do know one thing, though:
I have asked Zohar Why? Why do you insist on such high standards, although you know your prices are higher than the competition? At first he said, because he will not serve his own children anything less than what they are making.
But why? I continued. Surely you can make high quality food at home and sell something else to the market!
To this he responded that he could not allow himself to do that
Why not? I persisted.
This time he responded that quality is top value. You cannot compromise quality, and this is how you get your quality right.
What I felt from the beginning became clear now. This is what makes Mashani different from their competition: Values. They believe in their ways, and that’s what makes their product so good. Not the other way round.
There is no grand secret or a mysterious secret ingredient.
Where does this leave me? I am not yet sure. If I put my mind to it, I believe I can help them become better, leaner, whatever. But they don’t really need my advise – Mashani is already a learning organization, and it will be patronizing to think I can teach them anything they cannot find on their own.
As for other organizations… Bring me the CEO that is prepared to listen – not only hear. There has been much talk about Gemba Walks, and 5S and Six Sigma and more and how to practice them. But can you get a company to adopt new values and let go of old habits? Indeed, I find discussions such as “What makes a great leader” more valueable to getting the wheels in motion. Practices will inevitably follow afterwards.
After all, it all starts from the top and seeps down through the fabric of the organization.
Can you turn a non-lean manufacturer into a Mashani? And how? What do you think?
All things, great and small, come to an end, eventually.
So are new posts to this blog.
I am currently writing mainly to our blog at Practical Agile. You are most welcome to visit our website and blog.
Becoming agile 