Archive for October, 2008
Chipotle has the fastest service of any fast food vendor I go to. Rush hour, takes five minutes max. Go in when they’re nearly empty and I can be out in under a minute. Feels faster than the best McDonald’s times, even if it’s not really. Why is this?
Chipotle does Kanban!
Why do I say this?
Their customer-facing staff are all generalists. They know how to work the register, make all the types of food, and warn the guys behind them when more supplies are needed.
They have a WIP limit of one order per person working the line. The cash register has its own WIP limit of one, or possibly two during the lunch rush.
Customers are the users, the food is the feature. The employees don’t write requirements, they ask you just enough about what you want to satisfy the current stage of development.
The first employee pulls an order from the input queue, which is the line of waiting customers.
That employees take the order through the stages until there’s another, non-busy employee next to them, then hand it off. There is no knowledge transfer, because there are no requirements beyond what’s already piled on your burrito.
The first employee returns to pull the next customer, while the second employee works with the customer for beans, salsa, cheese, and so on, possibly allowing the next employee down the line to pull the customer’s order forward.
At full employee capacity, there is one employee filling each stage and the customers move at a steady shuffle down the line. If there is no need for full capacity, then employees can clean tables, the kitchen etc while a smaller number of employees runs the food line.
At lower employee utilization, better (i.e. faster) employees are able to cover more stages, and are not limited in their performance by the process.
They do Kaizen events whenever something is screwed up. The employee will stop the line, solicit assistance from the adjacent employees or the kitchen as needed, and fix the problem. Work doesn’t flow around in most cases because things are fixed very quickly and quietly.
Let’s look at the key indicators:
They have work tokens (Customers) that utilize single piece flow (the order) and managed through WIP limits (Set dynamically by the resource count).
Resources pull work from station to station, avoiding all queuing for work in progress. (Technically, one order does queue before the cash registers most times)
They stop the line and resolve problems rather than allowing inventory to accumulate.
They have subordinated all other functions to the goal of minimizing customer lead time.
I’m typing this in the car on my way to Ohio to see the in-laws because I just
finished having an incredibly compelling discussion with my wife. My wife is an
educator and has a masters of education specialized in adult online learning
with a minor in curriculum design. We were discussing her frustration with some
of the course authors and facilitators she works with regularly and
transitioned to a discussion of how modern education as a whole interacts with
online learning and online degrees. I’m going to describe a bit of recent
educational history below. Please read this with the history of Agile, Scrum,
and the current evolution of Kanban approaches in mind. Please keep in mind
that I am intentionally disregarding correspondence schools going back into the
1800’s, although I could easily draw parallels there, too.
Online learning has spent the last two decades working very
hard to become an accepted mainstream approach. Initially, online learning was
used for niche training, and then degree programs began to become available
from a variety of small schools. A huge variety of approaches were tried
throughout the 90’s, with the good ones sticking and the bad ones quickly being
forgotten. In the late 90’s and into the early 00’s, the industry started to
consolidate with regard to the approaches and mechanisms used to deliver the
learning, as well as the formats that were adopted for structuring the
Sound like the early agile movement? I find it interesting
that there are summarization books that collect the successful approaches for
online learning, just like Highsmith’s “Agile Software Development Ecosystems”
does for agile.
Now, with University of Phoenix having led the charge and
defined a highly effective “How” and then proven that it can be scaled very
profitably, there are a huge number of small schools starting to get involved
with their own programs. Additionally, the big, traditional universities are
taking notice of what’s happening and introducing their own online degree
programs. However, not only are the big schools years behind, they have a
number of difficulties trying to integrate this “new reality” with the
large-school mindset held by their administrations and tenured faculty.
I believe that sounds quite a bit like Scrum. It’s become
the de facto “way to do Agile”, and it’s a very good one. My wife’s Master’s
degree is from UOPHX, and I believe Scrum is vastly improved over traditional
methods, so I don’t mean this as a slam. The big universities fit well with the
issues faced by large companies trying to move towards agility.
The next wave is happening now. Back to where I started this
discussion, my wife was chatting about a survey of “Authentic Learning”
performed by her boss. This is where she sees the industry going next, and
she’s certainly applying the principles and practices of authentic learning to
her work, even before these principles and practices have accepted names or
approaches. The essence of authentic learning is in moving away from students
“learning how to be students” and towards “learning how to learn”. As an
isolated example, authentic learning stresses challenging students with
problems that have many possible solutions, rather than “traditional” problems
with a single, gradable answer. By the way, “authentic learning” is new the same way agile is new. People have done it for a long time, but it’s hard, and takes work, so people don’t do it out of laziness or lack of discipline.
This is where I see Kanban fitting it. It’s not the answer,
but it’s a positive move in the right direction, and it serves to move beyond
the status quo towards a meaningful improvement. Even better, not only does it
stress individually fitting solutions for the problems faced in development, it
includes the Kaizen improvement culture for Just In Time improvements to the
process. As an aside, I see Kaizen as being superior to the retrospective
approach used in Scrum because it is event driven (pull) instead of periodic
Now, we’ve done a great job pulling in many lessons from
manufacturing to use in improving our software development process. So many, in
fact, that manufacturing is becoming a very common metaphor, possibly even more
common than the previous metaphor of home construction. Guess what? We’ve hit
another single-metaphor system, and we’re driving straight towards stagnation
again. I believe that now is the time to begin pulling in more metaphors,
ideally those built on proven models. Education, with its many learning models,
has a lot to teach us. Science, with its well defined methods for belief and
proof, has a lot to teach us. Architecture has taught us patterns, and only
recently have people really applied those to processes. I think we can learn
quite a bit from service industries. Chipotle runs a very effective Kanban
process for burrito building, for example. Economics had a great deal to teach
us in managing incentives. The military could teach us a lot about specialized
training, and about layered planning and delegation, and about utilization of
specializations in a generalist environment, and about drastically changing the
intent and behavior of a large force in a short period. There are a nearly
infinite number of sermons out there that could be applied in various places.
Traffic management could teach us [more] about avoiding bottlenecks. Some of
these have been done already, some need to be done more, some might be brand
new. I don’t care, so long as the knowledge comes to us!
Summary: Go forth, find guidance and wisdom from other disciplines, bring it back. And share it.
I was a band member once upon a time. In middle school, I played French Horn for four years. Then, I didn’t pick it back up for over 15 years until last December when my lovely wife gave me a wonderfully shiny silver French Horn for our five year anniversary, with the encouragement to start learning. I toyed with it on and off, remembering the fingerings from muscle memory and really getting into playing the basic songs in the books she bought me. However, I continually got discouraged because I was quite simply unable to hold a tune; the pitch of most every note was off by at least a half step, often a full step. I lived with this, and slowly got discouraged and the horn started gathering dust until a couple nights ago when we decided to try playing a duet with my wife on the baby grand.
“Let’s just play some scales, maybe that’ll help you find the pitch” C Major, here we come! C… sounds great! D… hmmm… E… that’s off… and so on… right up the scale… only C and A seemed to be hitting consistently. After a while, I got frustrated, asked her to hold a note, and tried different fingerings until I got one to match the pitch. WTF? Why is this a 2-3 when I’m used to playing it as a 0?
Then came the dawning realization that banished my ignorance, my assumptions, and the sum total of my muscle memory. This wasn’t the same horn! There are two types of French Horns – Bb and F. I grew up playing an F horn, this apparently was a Bb horn. So I got out a pencil, copied the Bb fingerings from my fingering chart onto the music, and started playing (very very slowly). Instant pitch! My problem wasn’t a 15-year-old embouchure as I’d assumed for the last year, it was a disconnect of my core knowledge!
I should have remembered what I knew. Heck, I even read all about it in David Agans’ book! FIGURE OUT THE PROBLEM BEFORE FIXING IT! Doh!
First, I’ll repeat the news that’s all over: Microsoft has released the “final” version of Silverlight 2.0 to the world! This is a major step for .NET developers, because it means we can do really incredible things on the web without massive injections of AJAX or having to learn Flash. For example, take a look at what we’ve done with Inkubook. However, there is a lot to be said about how Microsoft approached things.
I believe that until Friday, October 10th, Microsoft has led nearly a perfect game with regards to how they’ve managed Silverlight. Here’s my perspective of what they did until now:
- Released a very minimal 1.0 edition that solved a small number of challenging problems in an elegant way.
- Very clearly communicated the known limitations of 1.0 while sharing plans for 2.0 as they became available.
- Released a very early build of 2.0 that generally did not break exiting 1.0 applications.
- Refreshed 2.0 with new released several times, clearly communicating both where the changes were likely to occur, and then what was broken as a result of earlier work.
- Successfully supported the Olympic Games with a Beta product with very few issues.
- Repeatedly engaged the community with what’s going on throughout the process, with many Microsoft developers and program managers sharing the work in progress and building training material on their blogs.
- Taking the unprecedented step of releasing an RC0 a short time before the release of a web-based product would break many developers application. They told the community that we’d have a short notice before they released the real final version, but they wanted us to have a chance to get everything updated ahead of time.
Fourth Quarter, two minute warning, Microsoft up by a touchdown with the ball and all their timeouts remaining.
Can anybody out there please tell me what possessed Microsoft to change the game plan this close to the end? Here’s what (to my perspective) happened:
- Friday, Oct 10, Microsoft announces a conference call for Monday the 13th through their PressPass site (http://www.microsoft.com/presspass/press/2008/oct08/10-10GuthrieSilverlightMA.mspx).
- Apparently, they also communicated a gag order internally, because nobody inside Microsoft blogged about Silverlight over that entire weekend with the exception of Jessie Liberty’s ongoing Silverlight daily tutorials.
- As a result, many teams probably missed this call entirely. We were only aware of it through the vigilance of one developer… on a team where everybody tries to follow blogs and keep up on the tech we’re using day in and day out.
- During the call (Monday, noon EST), Scott announces that Microsoft will be releasing Silverlight to the web “Tomorrow morning”, with no more detail. Note that he essentially just said that “Sometime in the next 12-24 hours we will be turning off your web site unless you’re ready.
- After the call (Monday, 1pm EST) we go into scramble mode, refreshing the prototype branch where we characterized the fixes to the breaking changes, merging it into our mainline build, and throwing the entire team at “making it work”. Please note that this meant that means that most of our developers needed to install VS SP1 (1-2 hours), uninstall and reinstall the silverlight developer tools, runtime, and Blend (1-2 hours)… prior to this, we had one machine capable of building our site in RC0.
- Microsoft makes an updated breaking changes list available. This list includes a half-dozen new items. This list does NOT include a number of items that have been commented on public blogs between the publication of the two lists. There are a number of breaking changes that have affected me that are not on any list. (Examples: Negative border widths no longer valid in styles, changes to when ActualWidth is set relative to first Measure pass, introduced need to explicitly call ApplyTemplate in some cases)
- That afternoon (Monday, 3pm EST) through evening (Monday, 11pm EST) we flew through our code base… first, commenting out or deleting the bits that didn’t work, then slowly fixing them back in once we got a baseline working.
- The first posts about it start coming out, and most of them aren’t from MS employees (Monday, ~4pm EST)
- We put in place plans to put the site into maintenance mode as soon as we see evidence of the RTW,
- We go home (Monday, 11pm EST), planning on cleaning up further graphical glitches in the morning.
Now, you notice that this has a fairly happy ending, for which we’re entirely grateful and I give full credit to my team for accomplishing this in less than 12 hours… even the new dev that just started yesterday stayed till 7pm and made meaningful contributions. This doesn’t change my opinion of how Microsoft bungled this release.
I have personally lost a lot of trust in how Microsoft will support products on their Go-Live licenses. They’ve earned a lot over the last couple of years, but much of it was burnt today. I still don’t know when they will flip the switch and turn on automatic updates to existing clients… which greatly impacts our release plans over the next week or so. At this point, I think I’m going to stop, and end with a few specific steps that Microsoft could have taken that would have saved my trust.
- Announce the plans to the world on Friday when they were clearly already set. If there was still a chance of calling it off, tell us that, so we can plan accordingly.
- Provide a specific forum to discuss the logistics with the community. Silverlight.net would be a great place for this. Who knows, maybe the community could suggest things to make it go more smoothly all around.
- Specify a single, authoritative place (blog, forum, web page, whatever) where we can get up-to-the-minute status of what’s happing… is the RTW out there, is it available, etc?
Summary: Communicate – don’t shut down at the most critical moment.
I very much appreciate the quick reaction from Tim Heuer at Microsoft. After exchanging a number of emails with him last night, I want to clarify a wee bit:
I am VERY IMPRESSED with how Microsoft communicated leading up to this release, right up until Friday of last week.
I am VERY IMPRESSED with the work produced by the Microsoft developers at a technical level.
I am VERY IMPRESSED with the road map that’s been shared and followed.
I am VERY IMPRESSED with the efforts extended by most contact points to “make things right”, especially Midwest architect evangelist Larry Clarkin.
However, I still have a core set of issues, which are summarized below:
Key issue: No warning was given of when and where the announcement
would take place. ScottGu didn’t even post on his own blog that he’d be
making an announcement at 9am Monday.
Key issue: The information followed a different path than all other announcements did previously.
Key issue: The original announcement said it would be short, possibly
very short notice. I don’t think many people understood that meant
“same day notice”
issue: Monday’s announcement said “we’ll release this tomorrow
morning”. Nobody clarified a) What time (i.e. 11pm PST?) or b) that
automatic update would/would not be turned on out of the box.
These three things are what I find to be the three critical aspects of all of the professional (and personal) relationships I share.
Trust, for me, is continually completing the things I say I will do. Trust is easily built by committing to a small item, then successfully providing that small item. On the other hand, trust cannot be achieved by being told what to do and then doing it. I’ll keep Kanban mostly out of this post, but this an aspect of why pull works. Trust can be lost, but it can also be regained, and even very low-trust relationships can be successfully transformed through the relentless pursuit of improvement.
Value is key, in business. Every relationship and communication carries transaction costs and coordination costs. Within the context of the responsibility your trust has permitted you, each individual must strive to provide maximal value to those around them. In exchange, that value will be returned, possibly multiplied. Perceived value is the down-payment on a relationship, delivered value is the rent. Words can create a relationship, but only actions can sustain it. Otherwise, casual (low cost) relationships will slowly wither, one-sided relationships will wither quickly with one person being frustrated, and painful (high-cost) relationships will be terminated. Often, the processes of gaining trust and delivering value are tightly related. However, value is very time-sensitive (here comes real options), while trust suffers only from the slow effects of entropy. This is how long-term partnerships are built across many short engagements.
Integrity is the cornerstone of all of these. Integrity is ethics, morals, and much more. Of these three topics, integrity is the only one that starts full, and it’s the hardest to refill when it’s been lost. Integrity can be lost, and it can be made visible to others. Occasionally, in exceptional circumstances, it can be regained. Integrity means that you stand up for what you believe, for the rights of others, and for just the "right thing". It means you admit your failures, and acknowledge the need to rebuild trust and value in the face of difficulties. It means you acknowledge and respect the trust and value offered by others, abstaining from activities that knowingly hurt others. Oh, and the other thing, integrity doesn’t count when it’s easy, you only get points for it when it’s hard. Integrity is advising a competitor of a potential leak or security risk, rather than unethically using those errors. Integrity is accepting the fault for the entire project failing, and then doing something about it. Integrity is refusing to let the general apathy rule the day.
These three things are critical to myself, and to any enterprise with which I am associated. As my personal and professional networks expand I am also recognizing that each of these things has a network effect as well. The more people with whom I have engendered trust, the more default trust I seem to have from their trusted peers. This was especially visible at Agile2008. It was my first entry into the Agile world directly, but the trust and value exchanges with people at the APLN Summit two weeks before somehow gave me direct access into the speaker circle, and as a result I spent much of the conference learning (and hopefully helping others learn) with the most respected individuals there. What’s more interesting, is that I can trace the chain of connections back to a single lunch I shared in Chicago during 2005. That chain could have been broken at any time by a failure on any of the three items above.