Posts Tagged ‘training’

The Agile Restaurant

February 18th, 2010

I've been doing Agile training again, and after yesterday's course I started thinking of a better way to explain what process means in an Agile world and how it differs from either an ISO-style paperfest or anarchy.  This is the analogy I came up with.

Think about dining in a decent restaurant.  There's a certain number of interactions you expect to  happen – you're going to be greeted and seated, you expect to  be offered an aperitif or water, you'll expect to see the menu and the wine list, and your going to expect your water, wine and dinner to be served.  If any of these steps are missed you're likely to feel annoyed, but also if you are asked every 5 minutes if you'd like to see the wine list, that's going to be annoying too.

There's a few ways round this.  In some places each waiter looks after a number of tables and only deals with those.  This means they always know the state of each table and are unlikely to repeat tasks.  The problem is this is quite inefficient. If we get a large party in and the rest of the room is quiet we'd like all our available waiters to help.  We also have specialists (like the sommelier) who is going to have to serve the whole room. We might also have junior staff (the guy who brings the water) who isn't yet ready to deal with more complex tasks.

The traditional prescriptive methodology approach would be to introduce some kind of table checklist. We'd have a set of boxes and tick off the tasks: has the water been offered? Have they seen the menu? and so on.  The maitre d' could then manage these table cards and allocate them to staff.  He can also 'report' on the status of the room to the owner by looking at the cards.  Sounds good?  Well it does offer a fairly strong guarantee that we will perform each table task exactly once, but we have introduced a major organisational task that's going to keep one of our seniors busy all night.  We've also prevented the team from being able to be proactive – if they spot a table where things don't seem to be happening they can't pitch in and help without getting approval from the supervisor. I think that's why this isn't how decent restaurants do it.

In reality, restaurants create a lightweight protocol to let each other know what's going on without the diner necessarily even knowing.  When aperitifs or water is offered they will place a bottle coaster on the table.  Each table might be set with generic wine glasses that are never used.  Once the wine is ordered (but before it arrives which might take some time) they will be removed completely if no wine is required or replaced replaced with specific white or red wine glasses.  The details will vary, but the principle is the same.

Any member of staff can see at a glance what state the table is in and deal with it accordingly.  There's a system, but it doesn't need a prescriptive process with a command and control structure.  The team can be proactive and deal with problems having confidence that they understand the situation and what is required – what does or doesn't need to be done.  That's the kind of system we want a self-empowered agile team working in.  We can't report by looking at cards, but we can look around the room and know exactly how will each table is doing which is what we really want to know, and we also still have a guarantee that we won't duplicate tasks.

This is the kind of process we are looking to create for the self-empowered Agile team.

Share

Do classes create objects?

April 22nd, 2008

Recently I’ve been creating some training courses for engineers, one of which deals with OO.  I’ve obviously been reading the standard texts and poking around the ‘tinternet for inspiration and I came across what, to me at least, seemed a curious concept.

It’s a slide in a deck that is introducing the concept of class vs. instances.  As well as the usual stuff it goes on to say that a class is ‘a factory that creates instances’.  Now I guess I can just about convince myself what the author meant by this but to be honest I really can’t see this as a useful way of understanding the class/instance concept so I’m curious to see if anybody else thinks of it in this light.  I certainly won’t be going down this path because all I can foresee is confusion when I start talking about Factory patterns in the Design Patterns course the following day.
Still, life would be dull if we all thought the same.
Share