How Starbucks Implemented Lean

starbucks

This article was inspired by a fantastic “What Starbucks can teach us about software scalability” blog post by Weronika Łabaj. It is a very good reading and I’m not going to repeat the things about Starbucks process. I will only do some kind of sequel by recognizing some part of that process as Lean principles.

Go ahead and read it now, I’ll wait for you here…

Have you read it? OK, now let’s find out how it correlates to the Lean principles.

What Starbucks did and why is that Lean

You probably noticed that after a payment is collected, no order is pushed to the coffee makers. Instead of this push system, a “signal” is created (an empty cup) and placed at the visible place to be picked up (pulled) by the next free coffee maker. This is nothing but Lean pull system. Among the other things, it prevents overburden (jap Muri), which is defined in Lean as one of three main reasons for a dysfunctional organization or system.

Obviously, a Starbucks wants the customer to be served as soon as possible for many reasons. You can see that they optimized their process for a short throughput time by using different “signals” (paper and plastic cups) to introduce parallel processing. The important thing here to understand that they do not optimize for a optimal resources consumption, but for a flow efficiency (“stop starting start finishing”).

Parallel processing is not the only example of taking care about flow. Take a look at their decision to “keep baristas focused on fulfilling orders instead of preventing the occasional lost coffee”. Flow efficiency over resources efficiency is also a Lean principle.

Another great example of their Lean implementation is a focus to deliver a value for the customer. Don’t forget that value is always defined from the receiver side. In our case receiver is a customer that entered a Starbucks to have a cup of coffee. Recognizing a regular customers and preparing their coffee in advance is a great value for the customer. Some would say that it’s not a big deal and it’s a practice from almost every bar, but there is a big difference here to understand. Starbucks does not rely on a barista’s good will to do so, but established a system to train baristas work in this way. It makes a big difference and shows how serious and systematic approach about value for the customer they have.

Further possible Lean improvements

Now that we recognized some Lean patterns in Starbucks process, it’s funny to play with some other process improvement possibilities derived from Lean. The first thing that comes into my mind is to limit work in progress (WIP limit). An idea is to limit the number of “work items” (cups of coffee) currently in progress. This should help to deliver faster with better quality. We could achieve this by drawing a two rows with six cup placeholders in total (three for plastic and three for paper cups).  A payment collector would be required to put an empty cups into a placeholders. In case of no free placeholders, collector should stop collecting orders, and give a hand to baristas to clear the queue. Once a free placeholder appears, collector could continue with her/his primary job.

What else improvements based on Lean principles could they apply?

 

Here is Why Football and Software Development are Similar

I’m really impressed how much similarities are between sport and software development. Here are a couple of it in case of football:

  • 11 Messi would lose most of games. Also, our project would suffer in case of specialized teams (11 Messi) and in case of all “heroes” in a single team (11 Messi)
  • Estimates are mostly wrong. If not so, betting houses would bankrupt. Estimates in software development are not more precise then betting. #noestimates
  • Game plans changes often. We should stop following original game plan if a current score is 0:3. In football they do, or the journalist call them morons.

It seems that we can learn a lot from football. Is there anything that they can learn from us? Maybe they could try self-organizing teams? :)

How IKEA and Ben Franklin Can Help Agile Coach

Origami-crane

Recently I came across one of those things that we „know“ and „are natural“, but still it’s full effectiveness stays hidden for us until we read some systematic explanation about it. This thing that caught my attention is called IKEA effect. In short, it’s about increasing customers belief into value of some product by letting customer to „embed“ a small amount of his own work and skill into it. Usually it’s done by allowing customer to finish the product.

This effect was used by many manufacturers throughout history, but IKEA, a popular Swedish furniture manufacturer „put a golden plate on it“ by asking customers to assemble IKEA furniture at their home. Despite it was used since long time ago, it was untested scientifically until Michael Norton of Harvard Business School, Daniel Mochon of Yale University, and Dan Ariely of Duke University wrote a paper about it in 2011.

Another well known example of IKEA effect is from 1950s. At that time, instant cake producers increased their sales dramatically by changing their mix recipes that was too easy to cook. They decided to require housewives to add an egg during cake preparation and it was a step that made them feel their skills are still necessary and valued.

The fact is: we value more that we build.

Now, lets put IKEA effect aside and take a look at another psychological phenomenon – Ben Franklin effect.
A story says that Benjamin Franklin used to borrow a book from those who behaved closed to him or disliked him. Upon book return, Franklin always tried to strongly emphasize a sense of favor that he received. After that, a book owner usually became more friendly and open.

This tool is useful today as it was in 1730s when Franklin recognized it. It’s because when we do a favor to some person, we tend to like them more as a result.

Having know IKEA effect and Ben Franklin effect, agile coach can make his everyday job a bit easier.

For example, coach could ask development team to mount a kanban board at wall or to speak to managers to enable some process changes. These are not prescribed activities for team members, but can help a lot during agile transition. Team members will probably love and use that kanban board mounted at the wall by their own hands. This is nothing else but IKEA effect. Try to include all people that you coach in a way they produce something. If you expect them to use something, let them create it if it’s possible.

Also, you can employ Ben Franklin effect to work for you, too. If you’re an agile coach, then you experienced agile transition resistance for sure. I’m also sure that you can enumerate people with strong influence to others and with strong resistance to agile changes. If you can make this people to be more open and friendly to you, your chances to success will be much higher. So, ask them to do you a favor. Don’t forget that this favor doesn’t have to be work-related. If you’re out of ideas, you can always ask them to borrow you a book :)

I know that this post feels like a common sense „that we already know“, but I hope that mentioning it here can remind you about existence of something that you already know :)

Football “Theater of the Absurd” feat. Defined Process

football_board
Defined process is one of two major models to control any process. It implies that everything is known from the beginning and nothing will change along the way. A waterfall project management model is based on it and is traditionally (been) used to manage various projects. The problem arose with developing complex systems (like software) where defined process is not appropriate. Now we know that a second major model, an empirical process control model (EPC), is a better fit for complex systems. This model uses change to build a better product. Agile development relies on EPC.

Despite agile development maturity and proven superiority compared to waterfall model, every now and then we mess with questions should we still use waterfall in software development for some cases. Keeping in mind non trivial software projects, my answer is always NO. In environment where change is likely to happen, we should always use EPC. Moreover, forcing defined process in complex circumstances is not only harmful, but could be ridiculous, too.

I was always impressed how some other industries are not effected by defined process at all, and use EPC by default. My favorite is sport.
For example, let’s try to imagine a football team preparations for FIFA World Cup. It is a real project with people, deadline, goals, etc. Right? In 1998, Croatian national team achieved a great success by winning bronze medal at FIFA World Cup in France. There were many great players there like Šuker, Boban, Bokšić, Prosinečki,… led by a charismatic football coach Ćiro Blažević (Ćiro is his nickname).
Now, let’s put them in a defined process and try to imagine big upfront planning like this:

Ćiro: “OK, guys. A plan is to win all three games in a group stage. It’s very important step toward gold medal.
Boban: “Excuse me, Boss, but shouldn’t we stick to short term goal to pass the gr…
Ćiro: “No! Listen, Zvone (Boban’s nickname), you’re a smart guy, but you know nothing about project management. It is my responsibility to derive a plan and your responsibility is to realize that plan. I planned every single detail for every game that we’re going to play.
Bokšić: “But, how did you plan all games when we don’t even know against who we’re going to play?
Ćiro: “Objection Boka (Bokšić’s nickname)! Maybe you don’t know against who we’re going to play, but I know. I know it because I did a very comprehensive analysis and planned other team’s games, too. It’s my job to know and to plan, and again, your job is to realize that plan.
Ćiro: “But guys, don’t be so unorganized. Let everybody do their own job, not other’s job. Do you have some questions from your area of ​​responsibility?
Players: “No Boss.

After a group stage, Croatia had 6 points and passed to a second round. They won against Jamaica and Japan, but lost against Argentina in a match with no significance. Ćiro called an emergency meeting.

Ćiro: “Guys, you screwed the plan. You wasn’t supposed to lose any game. That was a plan!
Šuker: “But Boss, we passed, who car…
Ćiro “No! We have to follow the plan. That’s what plans are for – to be followed.
Ćiro: “But, I have to admit, you’re not the only one who failed…
Team: ?
Ćiro: “I failed, too. Other teams screwed their games, so my original plan about our opponents is now dead. I should know it, but I failed…
Ćire: “But let’s go back to our case. Luckily enough, the game that we lost wasn’t in our critical path, so we still have a chance. Of course, that doesn’t mean that we can forget about that fail, it only means that we’re going to postpone consequences of it until the end of a tournament.
Ćiro: “BTW, Šuker, you’re not going to play next game, because it was planned to recuperate you for the next game.
Šuker: “But Boss, I feel fantastic! And I scored twice! Why I’m out now?
Ćiro: “Here we go again smart asses… remember the plan?
Team: “OK Boss…

Later on, Croatia “failed” to win a gold medal. They won “only” bronze medal and failed to realize a plan. Not realizing a plan implies a project was not successful.

Can you imagine such nonsense? Does this case sounds ridiculous to you? It is only a one-month project, so can you imagine how it would be with a whole season upfront planning? Indeed, it is ridiculous to use defined process in sports, so they never use it. They inspect and adopt before tournament, before game, during a game and after a game. They replan all the time. They never used defined process. They don’t even try to think to use it. EPC is natural to them.
Like in sports, EPC is natural in software development, too. We should stop questioning about that, and focus to deliver a value.

“Dear management, we’re already agile”


Agile is good, but we need management support for it“. “Agile adoption should start from management“. “Our agile adoption failed because management didn’t support it“. You hear it all the time, right? Indeed, such claims are everywhere. For example, 7th VersionOne’s State of agile survey says that in 63% cases initial agile champions were from management and also 31% says that management support is the biggest barrier for further agile adoption.
Well, it seems to me more like excuse then like a real barrier. People sometimes forget that bottom-up approach to agile adoption is all legal. Mike Cohn in his book Succeeding with Agile call it a “natural” approach.

I think that one of the reasons for such view could be that people don’t start from principles, but from practices. Starting directly from practices like Scrum could make you believe that you need deep organizational changes to start your agile journey. And organizational change needs, you guess – management support. What’s even more interesting that another reason is waterfall itself. To be more precise waterfall’s big upfront planning rule. It’s a kind of thinking legacy built into our brains that everything, including agile adoption, should be planned in details to succeed. And such big upfront planning and big decisions need, again – management.

Well, wrong.

Agility is a set of principles applied not only to an organization, but to people, too. Uncle Bob goes even further from here and says that “TDD is a personal decision“. Such a thought can be applied to some other practices and principles like kanban, pair programming, refactoring,…
Everyone should be aware that adopting some agile principles DOES NOT depend about management. I was a part of a team that tried and succeed in adopting Scrum without explicit decision and guidance by management. You can start tomorrow. No excuses!
It will happen that your manager will come back from some conference or training and will ask you to adopt agile. Put yourself in a position that you can say: “Dear boss, we’re already agile”.

What is the right recipe for spicing up your Scrum?

I noticed that a lot of people miss hearing that Scrum is a framework, not a method. It means that within Scrum you can (must) employ some other processes and techniques. So, what are the gaps that we have to fill in?

The largest gap is in engineering practices. This is because Scrum does not provide any of it. In this field things are very clear – for sure you should introduce some XP practices (continuous integration, pair programming, TDD,…) in parallel with Scrum.

The second group of ingredients for spicing up our Scrum are what M.Cohn call GASPs – generally accepted practices of Scrum. These are not rules, so practicing or not practicing it does not make you having or not having Scrum. At this point, it is probably very interesting that lot of people doesn’t really know what is a part of formal Scrum definition and what is not. For those of you who feel uncertain I recommend reading of Scrum Guide (http://www.scrum.org/Scrum-Guides) as some kind of “formal”  Scrum definition. What I feel is a really necessary list of GASP that everyone should add is: user stories, story points and Scrum board. Close to it are release planning and backlog grooming meeting, but I think it depends about project nature do you need it or not.

Additionally, there is a Scrum add-on introduced by M.Lacey in his book Scrum Field Guide that is not so widely known, but I like it and use it a lot. It is called Forth question in Scrum. At daily standup, additionally to a standard three questions, you ask “On a scale of 1 – 10, how confident are you that we will accomplish the goal of this Sprint?”. I usually use it with persons that are introverts and I have already felt the benefits of this approach.

And now we come to an interesting part – what about really modifying Scrum? I mean, to break the rules? But before we dig in deeper into this topic, I must say something very important: Do not modify Scrum before you understand Scrum principles. Again: Do not modify Scrum before you understand Scrum principles. For example, simply deciding not to do retrospective meetings without any other “replacement tool” to enable improvement is a very bad thing.

OK, back to the track. Recently two Scrum modifications occupied my mind. The first one is Scrumban – a hybrid process between Scrum and Kanban. Scrumban or Scrum-ban tries to use best things from Scrum and Kanban. I’m not going to describe Scrumban here because there are very good descriptions of it elsewhere (e.g. here), but I’d like to say that Scrumban really looks usable for maintenance and event driven environments. Also, it has a very strong growth of popularity (e.g. according to VersionOne’s State of Agile Survey).

The second Scrum modification is something that I heard from Hakan Forss at Agile Adria conference 2013. Hakan proposes to replace retrospective meetings with Toyota improvement kata. In short, Toyota improvement kata states that we have to set up some final state where we want to be and then, by doing experiments, we try to get there in multiple steps. I must admit that I was interested by this staff and right now I’m looking for a good opportunity to try it.

You may have noticed that both “real” modifications of Scrum comes from Lean. This is not surprising because Lean is entering into software development very fast. Mostly because of Kanban. As we all know, a change is in a heart of agile development, so maybe a Scrum will change significantly in upcoming years. Recently, Jeff Sutherland and Ken Schwaber announced a new version of Scrum Guide. We don’t know details yet, but maybe some non-cosmetics changes are close to be published. I mean, formally. Because in practice, these changes are already in place.

“We have no time” Consequences by Example

I think that everyone of us who did some serious software development at least once heard that “we have no time, so we have to take some compromises”. In these cases, almost always quality is the one that gets hurt. Despite the fact that almost everyone knows that it is not good in the long term, this happens very often.

So, I decided to find some examples from the world outside of software development to think about what are the real consequences of “having no time”. Imagine world like this:

  • waiter decided not to be polite because he has a lot of guests to serve,
  • hairdresser decided to use a machine only, not to use a comb and scissors, because a lot of people are waiting in line,
  • house maid decided to put all dust under the carpet because hey, an effect is the same – a house looks clean,
  • building company decided not to build-in any windows into your home because it’s much faster with walls only and same effect can be achieved with light bulbs,
  • cycling in a standing position is much faster, so we don’t need a seat at all,
  • car producer decided to use only computer simulated testing because it allows them to deliver new models much faster,
  • the priest decided to say a Mass only via podcast, because people doesn’t have time to come to church,
  • authorities decided to abolish all city speed limits, so that people could travel much faster,
  • your dentist decided to pull out all your bad teeth because it is much faster than dental treatment,
  • teacher decided to talk as faster as he can, so a class can be finished earlier

Not ready to accept such compromises? Then, why do you think your customer is ready to accept your software development compromises?

8 Monkeys in a Cage – a Mura Learning Game

Image

Last time when I was teaching Lean, I found myself in trouble. The topic was to teach students about 3M principles: Muri, Mura and Muda. As always, I planned to do some practical learning games. There are a lot of games about Muda, some very good about Muri, but very few about Mura. Additionally, we were in a very small classroom with computers fixed at desks, so I was in trouble finding some good Mura learning game appropriate for my situation.

So, I created my own Mura learning game which requires only a projector, a piece of paper and a pen. Even a projector is not really necessary if you print monkeys and give it to students. The game itself is improved through multiple sessions and it seems to me it is a solid Mura learning tool. That’s why I decided to publish it here and at tastycupcakes.org.

Here is a game description:

Objective

Mura is one of three fundamental Lean principles. In short, it’s about unnecessary variations. It states that people are more productive when not dealing with unnecessary variations. Playing this game should help people to feel a situation when variation is unproductive.

Timing

20 minutes

Materials

  • a projector and a presentation
  • 2 pieces of a blank A4 paper per student
  • a pencil for every student

Preparation

Give two blank A4 papers to every participant. Ask participants to draw “cages” on their two papers, so that monkeys can move in later. Every side of both paper should be divided by two lines resulting with four equal squares on each side of both papers. After this, every participant should have a total of 16 cages ready.

Tell participants that in this game they are not competing each other and not competing against clock. The goal is to feel the difference and to discuss it at the end.

The Game

Put a slide 2 (the one with four different monkeys) at projector. Tell participants to draw these four monkeys in cages onto their paper. They should do it by drawing monkey no. 1 in a top left cage, monkey no.2 in a top right cage, monkey no. 3 in a bottom left cage and monkey no. 4 in a bottom right cage. After this they should turn the paper and repeat drawing of 4 monkeys. Give them 5 minutes for it.

Now, put a slide 3 (the one with only one monkey) at projector. Ask participants to take the second paper and fill in another 8 cages, but this time always with a same monkey. Give them 5 minutes for it.

The Learning Point

Ask some of participants how they felt during the first session (with different monkeys) and how they felt during a second session (with only one monkey). What was faster? Which session was more stressful?

After this, let them understand that a task was to draw 8 monkeys, not to draw 8 different monkeys. So it means these variations were unnecessary. Also, it is important to say that a real reason why they were faster during a second session was because they learned how to deal with this monkey.

Help participants to correlate this situation to a real world examples:

  • one of the worst situation are unnecessary variations in product backlog. It generates stress and makes us less self-confident during estimations. That’s why we need a balanced flow
  • it is relatively often that people implement multiple, slightly different implementations for a same problem. We don’t need such variations. In that case, we should use “a same monkey” – a component
  • ask participants to add more real world examples of unnecessary variations

How to Teach Agile Those With No (Bad) Waterfall Experience

Recently, I had an opportunity to give a series of agile development lectures to students. Since the differences between agile and waterfall was my main driver during my first agile days, I started with it. But soon, I realized that none of them have any waterfall experience. They don’t know how bad it is, so they’re unable to realize real benefits from agile development. Of course, they guess there are some problems like responding to a change, but they have never felt waterfall problem on their own, so were unable to “buy” agile at first.

Then I remembered my CSM course in Vienna. There were some people who started their agile experience since day 1 at their workplace. It was a different kind of people compared to my students, but very similar about their waterfall experience – none.  They were very positive about agile, so I asked myself what was their strongest motive to use agile. The answer was obvious – a practice. They learned and “fell in love” with agile by doing agile, not by comparing it to waterfall.

Then I decided to teach my students with as much practice as possible. We did a hands on lab to learn TDD, simulated a sprint zero at a real case and learned muda by optimizing their classroom environment. It turned out that they like it a lot. They seem to have “bought” agile principles in an easy way.

So, if you need to convince a group of people who are free of bad waterfall experience, don’t talk too much about differences between agile and waterfall. Save this story for those of our kind who were frustrated by waterfall. Instead, try to teach them agile principles by giving them as much practice as you can.