The Self-organising kitchen

I had the rare pleasure to have dinner at Luke Dale Robert’s Test Kitchen last week. It answered a question which has been bugging me for some time; what does a self-organising professional kitchen look like.

It’s important to understand that our model for a professional kitchen was invented by Auguste Escoffier, who in turn copied it from the Prussian Army. This can be seen in the name for the unit of a professional kitchen, the kitchen brigade.

This is a strict division of skills and silos which operate under their various hierarchical positions, traditionally named from the French terminology and ultimately reporting through their various leaders until you got to the dictator at the head of the brigade, The Executive Chef. Traditionally also easy to identify in the kitchen as he has the tallest hat or “toque”.

Since Luke’s restaurant is structured unlike a traditional restaurant, all this is eminently visible, especially if like we were, you are seated at the bar which puts you within arm’s reach of the chefs and expeditors.

What struck me about the restaurant is that it has been designed as a system. The system serves a vision and a set of constraints. In particular, the main elements of the vision are: a constrained number of seats. I’ve been waiting some six months to get a seat in this restaurant: it seats about 30 people when full. The other major constraint is that the kitchen is visible, indeed inside, the restaurant.

These two constraints have had some very interesting ripple effects on the product as a result. The amount of actual cooking which happens while the restaurant is in full swing is actually quite small. The main proteins are not deep fried or baked. Instead most of them are subjected to a quick sear. In addition this happens over induction burners. All of this means that the kitchen is not as hot as a gas fed kitchen, or as noisy from the air conditioning and extraction that would be needed.

This in turn has meant that the style of food is mostly small plates with diners offered a choice of 3, 5 and 11 courses, with the portion size allowed to vary as required. These two outcomes (small plates, mostly cold serving) has resulted in a unique style of food where there is significant emphasis on the composition of the final plate. This is not the usual meat and two veg sort of approach but rather a series of bento-box like constructed dishes.

What struck me about the kitchen was how quiet it was. Not monastery quiet, but rather, no need for raised voices. The other is the fluidity.

I worked in a few professional kitchens a few years ago. What I saw was that it was really hard to help someone once they got into the weeds. The kitchen is a finally tuned complex adaptive system. All the agents within the system know with a dreadful certainty when one of their number is doing the “dans de le merde” (as Anthony Bourdain puts it). You can feel it the way a race car driver can feel a finely tuned engine suddenly throw a piston. It is usually best in those circumstances to keep your own mise in its place. The danger here is that the weeds can spread quickly to the rest of the kitchen (hence the name).

And make no mistake the inevitability of variability and queuing will mean that sooner or later everyone will find themselves in this lonely place.

There were two things I noted instantly when I arrived at the Test Kitchen. The chef was not expediting. In fact, the chef was actually experimenting with a new dish (some kind of salmon brushed with squid ink) while the kitchen slowly spun up, serving welcoming snacks and the first few starters. It’s hard to see what the deal is here, but on inspection he is providing slack in the system. Later as things got faster paced he was able to step in and assist with plating and expediting, and then step back.

There were a number of chefs who over the course of the evening were able to move from station to station as needed. And when the presentation was not up to the Chef’s standard he fixed it himself rather than send it back.

Which brings me to the front of house staff. Rarely for such a high end restaurant, the staff happily float from table to table as needed. The system for recording orders was consistent (I know this because I could see all their tickets) and so when the expeditor had a dish ready, the next available server was able to send the dish to the correct patron without error by consulting the ticket. The other item of interest was their collection of metrics. The time of first order and the subsequent delivery of each dish was recorded (all using the same time code). I noticed that the cycle time for courses was a fairly consistent 20 minutes varying by no more than 2 minutes or so on each side.

The only moment of tension I observed the whole night was a mistake made in the recording of an order by a waitress. What was specified was four duck, when in fact the table had ordered two duck and two pork. This was caught as the dishes were about to be plated. This was the longest delay I noted as the two completed duck dishes were quickly disassembled to wait for the two minutes while the pork was fired. Again, here the design of the dishes (fast cooking, significant mise en place, composed by the expeditor) worked to the advantage of the experience as a whole, as the kitchen was quick to recover with minimal impact on other orders.

It is tempting no doubt as chef to attempt the local optimization of the kitchen in order to deliver food. What was the learning for me was how the vision and optimization of the whole was able to create a benchmark experience for me. What I saw at dinner was a well-oiled machine built on trust, respect and specializing generalists under the leadership of a visionary. Needless to say, if you are in Cape Town I recommend checking them out.

This thing is not like that other thing

One of the things I struggle with as a coach is convincing companies of the necessity for coaching. Part of this I guess is the self-interest involved. Mainly however, it lies in my seeming inability to articulate why training on its own is not enough.

So let me offer an analogy: imagine someone wanted you to teach them to play chess and win at it. To do this they want to know (and as a result, for you to teach them) what the best move is for every situation.

Now clearly, this is a ridiculous request.

Instead what you do, is first teach them the rules. And then teach them (usually by playing a few games) how to recognise good moves; moves which advance their position strategically. In other words, once they understand the rules, you teach them the principles of good chess.

How much more complex is software development, this "co-operative game"? It requires complex interacting agents to exchange information to produce an unknown (perhaps even unknowable) outcome?

How much more difficult would it be to identify (in advance no less) what all the possible moves are and figure out which one is the "best" one? And to do this without knowing what the complex environment and nature of the team and its constituent members are?

All we’re trying to do in the initial training for teams is establish the rules: e.g. stand ups are for the team, the Product Owner collaborates with the team to establish the priority of work etc. etc. Everyone needs a basic understanding of the framework, so they can play the game.

The problem is that in communicating this essential requirement, companies fixate on the training as an end in itself, rather than the beginning of a learning process. And my personal weakness is that I find it difficult to communicate the importance of values as the key factor in an Agile transformation, particularly in a sales meeting.

So I guess in the spirit of "inspect and adapt", next time I’ll try out my analogical argument.

Powered by Qumana

UX Fail

So I’d like to divert from my usual blatherings to something closer to home. I’d like to describe a recent epic user experience fail on the part of my telecoms service provider.

I have been a loyal customer of MTN for the past 8 years or so. I have been as close to a model customer as it is likely to get. I have never missed a payment and since the contract structure I have is ‘Weekend Minutes’, and I never use close to all of them, I usually end up spending at least some money on prime time calls.  Since voice is the main thing for me, and with all the interconnect revenues they generate from that, I’m guessing that I have been responsible for about R24,000 worth of revenue at a pretty decent margin over the lifetime of my account to date.

I’m also a pretty easy customer. I rarely phone the call center and I prefer to deal via the web, so in the past I have used MTN Direct as my service provider for new contracts etc.

So I’ve recently run out of contract and have wanted to renew. So my first port of call has been the MTN website.

I entered my details for a contract upgrade and after 2 weeks had not yet been contacted by a service agent. So here I am, wanting to renew my contractual relationship with a provider who apprently is not interested in reciprocating.

Doggedly, I continued to pursue this like some love-sick puppy.

Every few days for the next three weeks I have tried to access the site at: been greeted by the image below:

Screen shot 2009-11-20 at 6.25.54 PMSo foolish as I am, I just assumed that it really was down. Even for this extended period.

Until I received an email from MTN with my statement, which mentioned a ‘Summer Sale’. Clicking on that took me to the site in some weird aspx level. So clearly, when some maintenance was done to the site, nobody bothered to redirect the landing page to the correct aspx landing page. And since this has been going on for more than three weeks now (and yes, this screenshot was taken a few minutes ago), it mens nobody has bothered to check why their site stats are down. Their bounce rate must be 100%!

But now I have managed to get to the two pieces of information I am looking for: the handset and telephone number I need to call to arrange my contract. This part is fairly smooth, I get an email with the forms in PDF format, but I can’t edit them. So I have to print them, write all my details in my inelegant scrawl in a space too small to actually accommodate the info, scan and email back.

No acknowledgement of receipt follows. Unless you count the spam joke email I received the CSR who I exchanged email with, telling me to ‘Hang in there, it’s nearly Xmas!’

Screen shot 2009-11-20 at 6.38.20 PM

I had been told by the CSR that the phone could take about a week to reach me.

What frankly fascinates me is that I went through this exact process about four years ago with much less trouble and delay to receive the phone.

So three days pass. I receive two missed calls from a number I do not recognise. They leave no message.

This morning at 6:45 AM my mobile rings. I stumble out of bed, grab the phone from my wife’s hand and listen to someone mumbling at me. He’s asking me ‘How I am’. I am too stunned to really do anything other than blurt ‘It’s very early in the morning!’ To which he replies that he has a delivery of a cell phone for me, that he had tried to phone me yesterday and couldn’t get  through, and where in Johannesburg was I, so he could deliver the phone.

This is such a monumental screw up in customer experience that it leaves me literally stunned. I reply that I am in fact in Cape Town. What he said next I could not decipher and then he hung up.

Now, MTN is a company in crisis. And maybe, as a result, I should feel bad about taking my business elsewhere. But frankly, while I feel terrible for those people who will be losing their jobs perhaps some companies don’t deserve to live. It is clear to me that if the people responsible for managing this beleaguered organisation spent a little time trying to figure out how to create a remarkable customer experience, rather than chasing cost cutting measures, they might be able to save their business.

And let me be clear; I don’t blame any of the people I have dealt with thus far for the terrible customer experience (crap website, poor email protocol, phoning me while I am still asleep). The poor guy who doesn’t know I am in Cape Town and whose been told he has to get hold of me is likely some poor schlub who works for near minimum wage. He is more than likely doing what he has been told to do.

I blame PF Nhleko for creating a culture of mediocrity where this kind of crap is allowed to happen at all.

So cheers MTN; it wasn’t worth the pain of keeping the relationship going.

Capitulation is not consensus

As I coach more and more teams, I notice a pattern. Scrum masters who fear (or loath) conflict try to resolve discrepancies in estimates as quickly as possible. They will try to force a majority vote as consensus. Or worse, place the dissenter on the spot, somehow implying that they are holding the process up.


This creates a dangerous dynamic within the team. Conflict is seen as bad and to be avoided. The way to recognise this is when you hear a statement like: “I guess I could go down to a three”. The scrum master is missing the purpose of the meeting. The team is there to gain a common understanding of the work. When a team member capitulates, they’re robbing the team of an opportunity to really understand something. It makes the team as a whole, less effective.

It also makes the estimation meeting less representative of the team’s understanding, and as a result team members begin to see less value in it, resulting in greater skepticism in the process of estimation. Which sets up a vicious little circle.

The underlying problem here is the notion that dissension is a zero sum game. The notion that an argument has a winner and a loser means that people will sometimes refuse to participate. The culture we should be trying to create is that of strong opinions, weakly held. Argue until you’ve been convinced otherwise. Then gracefully move on to the next topic/item.

The scrum master’s role is to fascilitate the discussion, to make sure that it remains a robust discussion about the issue. More importantly, the scrum master should be coaching the team in why the estimation meeting is important and how to best use the time in those meetings. This comes down to understanding the principles and not executing a set of rote ceremonies.

Henrik Kniberg on Scrum

Henrik has published his slides for his upcoming talk at Agile 2009. They represent what I believe to be a concise, entertaining and complete intro to everything you’ve ever wanted to know about scrum. His book ‘Scrum and XP from the trenches‘ is usually the first book everyone reads when they want to know about scrum, so he’s had a huge impact on the community already.

Note, he is now also running for a position on the board of the Agile Alliance. You can find his position statement here. He certainly has my support.

And then, as an added bonus he has published a great scrum checklist, so you can measure the success of your implementation.

You can also follow him on twitter.

The Tool Trap

As a life long fan of technology and one privelaged to work within a high tech industry, it’s easy to get distracted by the shiny…

used with permission:

used with permission:

Technology is nothing but tools. When you consider that the people who are usually most passionate about technology are the ones in the agile camp, the proliferation of agile tools in the market place has a sense of inevitability.

It is also the most common mistake we make as practioners, certainly when we start down this agile road. Agile = Cool so we want all the shiny cool new tools. Preferably one written in Ruby (or Python or Haskell). With many rounded corners and buzzword compliance.

I think the reason why we fall into this trap, why we find it so compelling is because we’re technologists. At our core, we believe that given the right tools we can change anything for the better. This unflagging optimism is why I read too much sci-fi. On my first real scrum job, I immediately went straight for the throat and tried to find the right tool to get this scrum stuff embedded into our development process ASAP. I believed that the tool would help us ‘do it right’. Turns out there is a word for this belief: Technicism

And I got it precisely wrong.

Agile adoption is a change process, and change is hard. We all too easily use technology to hide from change. My problem with most electronic scrum tools I’ve seen, is that it is all too easy to use them to hide the valuable stuff that help us to manage the change. (Maybe if we had the technology where all our walls were display screens that were also touch-sensitive it might be different.)

Change is also about humans. People. We’re complicated beasts and slow to change. So the best thing to use to bring that change about is the base instincts. For example, we’re social creatures. That means that the most important influences on our behaviour can be found in our peers. This is a function of our evolutionary history. So use the peer pressure to help drive behaviour. A visible example of this is the daily stand up.

In a recent conversation with a much wiser man than myself, Peter offered the not entirely surprising insight that most agile teams which move from a physical (cards, sticky notes, scrum boards) to an electronic one, usually go back to the physical. I believe that there is a sinister conspiracy at work: Scrum is in fact a 3M marketing ploy. The insight that I get from this is one that is easily lost in a cubicle farm. Making software is a social activity, and the technology we use to communicate is a poor analogue for our evolved communication patterns. Alistair Cockburn has a graph which illustrates this wonderously. In fact go read his talk while you’re at it.

So what I have learned is that this agile stuff, works a whole lot better when I step away from my identity as a tool user / maker. In fact I get a warm fuzzy feeling whenever I see my team in front of our scrum board…

Hero-Driven Development

I feel like I may need to start this post by paraphrasing a song: “You’re so vain, you probably think this post is about you.”  I have had the privilege of working with some remarkable technologists during my career and the danger is that they misinterpret what I’m about to write about. Steve McConnell calls them “10X Developers“. They’re the ones who can produce code at a rate of 10 times that of the average. Every software company would like to employ them, and some believe they do.

What I’ve started to notice is what amounts to an organisational anti-pattern.

Anti-Pattern: Hero-Driven Development

Captain Squarejaw to the rescue

Problem: Whenever some gnarly problem raises its head, the Hero is sent to fix it. The team sit back and let the Hero work, maybe watch what The Hero is doing. The Hero fixes the problem (slays the dragon) and the team gets back to doing what ever it was they were doing till the problem was discovered. The Hero flies off into the sunset.

Context: The team has hit an impediment which is within their theoretical skill base but without the experience or resources to fix the problem. The person accountable for delivery is panicking. The team is thrashing and seem to be getting no closer to a solution. Someone lights the signal for The Hero who swoops in to save the day.

Forces: Every software development project is a hostage to budget and schedule. In this context it makes sense to solve the problem as quickly as possible. But this is inevitably a short term fix; depriving the team of the opportunity to learn from failure and pain means that their growth will be stunted. The team’s ownership of their work diminished. In the worst case scenario it can lead to a loss of confidence and morale. There is also the danger that over time, the threshold of what is considered a problem will decline. The perception could evolve that the Hero gets all the interesting work. And worst of all, that any work done by The Hero is immune from scrutiny.

Solution: Trust the team. This is their problem, their mess. Support them where needed, get them expert help, but make sure that the team does not lose ownership of the solution. The Hero can still step in to help the team solve the problem, but the difference is in how the help is evaluated and used by the team. This is an act of collaboration and not an act of salvation. It is vital that the Hero be seen mainly as a ‘consultant’ to the team, whose output should be mainly advice. If The Hero is writing code, it needs to be dealt with in the same way as any other developer’s code. It should meet the team’s “Definition of Done”. And ideally, it should be reviewed publically so that the team can learn from the event and hopefully improve (Inspect and Adapt). It is better as a longer term strategy to have a team of heroes than to depend on a single person to solve all your problems.

Note, I am not concerned in this post with primadonnas or those who don’t share their knowledge. This is not the true Hero. If I had my druthers, I would fire those people from any organisation I was working for. In my experience someone who is trying to make themselves indispensable in an organisation deserves to be shown the door; they are acting for their benefit and not of their team mates or company.

My Ada Lovelace posting

I promised to write a post about a woman in IT whom I admire as part of this campaign.

The woman I admire happens to be my wife, Karen Greaves.

She has been my mentor and inspiration. She has made a reputation for herself as a superb boss (although I hesitate to allow her to be my boss, at work). Her people are fiercely loyal and she is loyal to them.

She comes from a technical background, having worked for Microsoft. I think she enjoys shocking developers by understanding their technical challenges and being able to suggest solutions. But it was really in product and project management that she discovered her true calling.

She has long been a supporter of agile methods, and has worked passionately to make it part of the environment where she has worked. I learn every day from her experiences with scrum in her environment.

For me, she has been an inspiration for how I would like to be, and perhaps a large part of the reason that I got into this business.

So today,  I salute her accomplishments in the software world, but I didn’t actually need a special day to do that.

Orlando Gathering

For those of us not lucky enough to be in Orlando right now, the Open Space findings are being captured at:

Presentations are also being published to the Scrum Alliance site at:


There has been some vigorous discourse about the state of scrum in the past few months. I’m not going to refer to them specifically.

What it feels like is that scrum has reached a level of acceptance and recognition that it has now become mainstream enough to warrant the kinds of attacks that can build your reputation. Everyone loves the little guy; this is why it is useful to frame arguments as a battle between the little guy and the big guy. The insight to take away from this is that rising to the bait will only encourage more baiting. There is no right way to do this.

At the moment I feel a bit like scrum’s bulldog.

I think Martin Fowler probably has the right insight. The baiting, criticisms and misunderstandings will be an inevitable aspect of the growth of scrum. what we as a community need to do is emphasise the technical aspects of a scrum implementation that will ensure success.

Nothing succeeds like success; which means that in order to be successful, we need to do more with regard to practices like continuous integration, automated regression testing and test driven development and refactoring (especially in the architecture area).

The one area where I will usually reply to percieved criticisms is where I think it is founded on a misunderstanding of a practise or role.