Complex and Agile

In my first book excerpt, I described the idea behind the heat model. Here’s the model itself.

In the “turning up the heat” model, we differentiate between 5 different levels of heat: burning, cooking, cooling, congealing, and solidifying. It takes effort and energy to maintain any level of heat. The dissipation of heat in teams can be thought of as ‘social entropy’.  The natural forces of entropy as described in the Second Law of Thermodynamics apply as much to social organizations and interpersonal relationships as they do to molecules or galaxies.

Why do teams, even ones that are experiencing problems, not want to change? My thesis is that most of the time people and teams are in stasis and so resistant to change. To make change occur we have to raise the heat just enough people no longer feel comfortable in their current environment. I believe that when we see teams that stop doing TDD or other practices that it’s often because the heat has been turned off. Working in a rigorous fashion I recommend that we only make one change at a time in response to problems we want to improve. This allows us time to observe the system for retrospective coherence and adapt accordingly. It also reflects the fact that changes happen with a delay, and helps us to avoid over-correction (see Dörner’s example, later in this chapter).

The use of heat has analogy in cooking – most people on turn heat on or off but as coaches we need to understand the five levels. To connect the analogy:

Burning – food tastes burnt, teams fall apart.
Cooking – flavours in food are well integrated, teams adapt to new ideas
Cooling – bacteria grows in food, teams stagnate and start to stop using tools
Congealing – teams are starting to lose their flexibility and lock in their habits
Solid/Frozen – bureaucracy has set in, there are forms to fill out and sign offs

A coach needs to recognise the characteristics of a team in each of the stages. Most often, a team will be moving between levels, unless they’ve got to the state of complete burnout or complete stasis.

In the next book excerpt, we’ll look at the individual levels in more detail. It’s challenging for me to explain them, and I find that they’re most easily defined by example.

Writing

I’m on the road right now, and don’t have time to write a long post, but I don’t want to withhold this interesting insight from you.

Last week, I attended the first Swiss Lean/Agile/Scrum conference. As usual, the Swiss take a long time to catch up with new ideas and technology, but when there’s money to be had, they’re right up at the front of the line. Anyway, Ken Schwaber gave a very interesting presentation on the concept of “Done”. He showed the canonical burndown chart, and then took the individual vectors apart.

Seeing the variables separated like that got me to thinking, and I had the chance to run my thoughts past Karl Scotland and Keith Braithwaite, both of whom went out for a beer with me afterwards.

Back in the early days of XP, we defined a set of project variables:

The rule went, “Time, Resources, Quality, Scope - choose three”. Whichever three you chosse, the fourth variable would be a function of the other three. Which three were actually chosen was the customer’s decision. Some customers (and managers) don’t understand this rule, and try to grab control of all 4 variables. By doing that, the first variable that’s dropped is quality, followed by time.

So, how do these sets of variables map to each other? The first two are easy:

• time = time
• backlog = scope

The other 2 are a bit more difficult:

• V = f(R)

Velocity (burndown rate) is a function of the available resources. Regardless of what you have to do, having more resources will normally allow you to go faster. This function is non-simple and non-linear, unfortunately: as Fred Brooks rightly says, “adding manpower to a late software project makes it later”, but the simple case is a more or less linear function.

Quality is even more complicated:

• q = ∂V/∂t

As Dan Rawsthorne says, “Quality is the first derivative of the burndown”. The quality of a product is directly related to the development velocity/burndown rate.

So, so much for that thought. Keith spun the thought even further, proposing in his recent blog post that you can increase velocity by increasing quality. I agree with him, and I recommend you read the post.

Agile Adages

Last weekend, I attended the Agile Coaches Gathering, which was held in Bletchley Park. I met many old and new friends, and had an enjoyable time. Thanks to Rachel Davies and Mike Sutton for organizing it!

A very interesting incident took place at the gathering, one that got me thinking about the practical application of my work in social complexity to the people and teams I deal with. The gathering was structured as an Open Space, running all day Saturday, and all 40 participants met up Friday evening to discuss and decide on topics for the next day. At 19.30, we had a full board of interesting topics, Rachel announced that the evening session was over – and then it happened.

40 people sitting in a room, all thinking “now what?”

My friends know that I hate the tradition of everyone at a conference going out to eat together. You all pile into some poor restaurant, start pushing tables together, and generally drive both the restaurant personnel and the other diners mad. Why do you need to push tables together? It makes it much more difficult for the waiters and waitresses to manoeuvre, and honestly, you can’t talk to more than the 5 people surrounding you at most. It’s loud, it’s noisy, it’s uncomfortable. It puts a stress on the waiters and waitresses, taking all the orders, serving them all at once, and then having to deal with people demanding separate checks and paying with a mix of cash (in multiple currencies), debit card, and credit card. It’s even worse for the kitchen staff, who get bashed with a large number of orders without any warning.

40 people sitting in a room, all thinking “I’m hungry.”

As if the problem with the restaurant wasn’t enough, we had to deal with people staying in a number of different hotels, none of which were within walking distance from the gathering site, and a number of people who came by train, and had no way to get to either the restaurant nor the hotel.

So, how does one solve this problem?

Rachel gave it a good try. She told me afterwards that her prime concern was to have no one left stranded. Once she asked people who needed a ride somewhere, though, things took on their own momentum, and there were cries of “everyone who wants to eat Indian in this corner” and “anybody staying at the Premier Inn in this corner” and “anyone with a car over to this side”. Pure chaos. Admittedly, Rachel and Mike had tried to plan things a bit, and had posted a list of restaurants for people to choose from, but as you’ll see if you look at the list (http://tr.im/mqen) some people either couldn’t/wouldn’t decide, or were gaming the system by keeping their options open and not committing themselves.

“So”, I thought to myself, “this is an excellent example of what happens when you try to apply ordered systems techniques to a complex problem domain. How would I deal with this?” And so I used the incident as a case study in my Open Space session on self-organization the next day.

We all tend to fall into the habit of trying to bring un-orderly situations under control. In complex situations, however, even someone as skilled and experienced as Rachel had a tough time doing so. The domain had three main variables – restaurants, hotels, and transportation – with each person having an unknown combination of the three. With 40 people, that’s a lot of possible combinations to match up.

So, how would I solve the problem? Instinctively, my first intervention would be to “turn up the heat”, to give people the sense of urgency necessary to break through their lethargy and self-organize. Saying something like “we gotta get out of here in 5 minutes, because they’re closing” would provide the shock necessary. The problem here is that the level of heat generated is not predictable (we’re in a retrospectively coherent complex system here), and we don’t have the luxury of doing multiple probes in a probe-inspect-adapt loop. Would 10 minutes be better? Would 3 minutes suffice? I don’t know, so it’s time to start thinking about what I do know.

One thing I know – or rather, assume with a high degree of certainty – is that all the attendees are adults. They got to Bletchley Park., which means they took responsibility for organizing that, and they assumedly took responsibility for organizing their accommodations for the night. It’s 19.30, and everyone’s there, so no one has a hotel that they need to check in to immediately, lest they lose their reservation. So, why not just forget the hotels for now? Doing that would bound the problem more by reducing the number of variables and complexity. People can go to their hotels after dinner. Also, letting people go to dinner first works to our advantage. Social network stimulation takes place at dinner, people find others staying at the same hotel, and the restaurant staff are usually knowledgeable (if not always helpful) about the relative locations of the restaurant and the hotel. They’ll know how far a walk it is, and can also call a taxi if need be.

This leaves us with two variables  - food and transportation. Given a choice between catching a ride with someone, and going with interesting people to a restaurant that might not have been first choice, or being fixated on a particular restaurant, at the risk of calling a taxi to get there, and then having to eat alone, I assume that most people would choose the first option. This assumption is supported in part by the fact that quite a number of people signed up for multiple restaurants during pre-planning (see above). So, with the restaurant variable becoming at least partly dependent on the transportation variable, we’ve gotten things down to one variable – transportation. The simplest way to solve the problem of one variable would be to ask all those attendees who have no transportation to raise their hands, and ask the others to help them. Wait around for a few minutes to ensure that everyone’s been taken care of, and no one is standing there alone and lost, and you’ve solved the problem. You’ve also solved it in terms of Rachel’s initial concern, i.e., that no one was stranded.

What did I do? I had driven up to the meeting with my good friend and business partner David Harvey – actually, he drove, since I can’t deal with people driving on the wrong side of the road. Knowing our mutual dislike of large crowds in restaurants, we checked around on the net for a nice quiet place that serves good food, and that was a bit out of town, and booked a table for four there. As we anticipated, we weren’t the only two who wanted to avoid the post-meeting turmoil, and so we spent an enjoyable evening eating and chatting with Steve Freeman and Keith Braithwaite.

Uncategorized

This is the first slice from the book chapter on the “Turning up the heat” model.

Vegetable soup

My grandfather was a fantastic chef, and he was a great inspiration to me. My parents named me after him, and not only did I inherit his love of, and talent for, cooking, but unfortunately also his girth. One of the first things I learned from him, at a very early age, was how to make vegetable soup. OK, maybe he just wanted some cheap help for mise en place, but at that age, I didn’t care.

Vegetable soup is simple. It consists of carrots, celery, onions, leeks, some herbs, and lots of water. That’s all. He’d let me peel the carrots and onions, and then he’d chop up all the ingredients and throw them into a pot that was so big it reminded me of something the cannibals threw the missionaries into in an old movie. An hour or so later, magic had happened, and out of all these ingredients emerged a tasty soup.

One day, after I was old enough to be allowed to use a small knife myself, I decided to surprise my grandfather and cook vegetable soup myself. Early one morning, I snuck down into the kitchen, got the ingredients, prepped them, then threw everything into the pot and waited for my grandfather to come. When he entered the kitchen, I jumped up, ran over to him, told him I had a big surprise for him, and proudly pulled him over to the stove. He looked into the pot, and what he saw was – mush. Careful to not upset me, my grandfather said that I had forgotten something. “But I put in all the ingredients as you always do,” I said. “Yes,” he said, “but the most important thing in making soup is not an ingredient itself - it’s turning up the heat.”

The same thing happens to us every day. We get a group of great people together, expect they’ll make a great team, and then watch as they act like a bunch of idiots, without understanding why this is happening, or what we still need to do to get them to work well together. We’re forgetting the main ingredient!

The team is the fundamental unit of software development. A team of skilled and highly motivated individuals, creative, focused and productive, is the cornerstone of the Agile philosophy. It does not follow that a group of people, however carefully selected, will auto-magically form a team capable of producing excellent software, on time and within budget.

Any group of people will self organize, according to the social and psychological principles, or ‘human nature’ that have influenced human interactions since the days of cave dwellers. Self-organisation will happen eventually, then, but there are two reasons why leaving a group alone to self organise for software development will almost undoubtedly fail. First, few projects incorporate the time or resources necessary to allow a stable organization to emerge before any work is done. As the saying goes, ‘a drop of water may hollow out the hardest stone,’ but we can’t afford to wait that long. Second, the team that emerges will be likely to have developed according to individuals’ ingrained behaviour patterns, many of which will reflect our primate ancestry. All groups of primates self-organize. This mainly results in the establishment of a pecking order, a rank and power hierarchy. Self-organization ends up being a fight for alpha male dominance. This what probably not what you want – unless you’re the alpha.

So, for a group to become a team, you must turn up the heat high enough that the team members cannot maintain their ingrained behavioural patterns.

If you don’t increase the heat, people won’t need to change the way they normally behave, and so they won’t change. Any self-organization will revert to being the basic primate fight for alpha male dominance. Unfortunately, this isn’t always an easy thing to do. Another thing I learned from my grandfather: for most people who haven’t trained as cooks, heat is a Boolean. It’s either all the way on, or all the way off. A good cook, however, knows how to regulate heat, how to use it to his advantage. He also knows which kind of heat to use in which situation. Too much heat, and things burn. Too little, and they don’t cook, don’t blend well enough to become soup – or whatever else you’re cooking. No heat at all, and they stay in their primitive state – raw. Only when the heat is right does cooking happen, do flavours blend, whilst retaining nuances of individuality.

It’s the same thing with people. Too much heat, and they burn out. Too little, and they don’t feel the need to change and adapt. Only when the heat is right do they adapt their behaviour and meld together to form a team.

As the posts go on, we’ll look at the Heat model, its different temperatures, the thermometers (analysis tools) available, and the various stoves (interventions and techniques) available to turn up the heat on a team.

Writing

So, my book is finally starting to take shape. As we clean up and copy edit it, I’ll be posting bits and pieces here. Feel free to drop by here now and again to see if anything new has been posted - or subscribe to the RSS feed.

Another reason for posting book excerpts is to establish a bit of precendence. I’ve been researching and talking about why all this agile stuff works for years now, but since I never wrote much about it, and since a lot of others are starting to learn the same lessons, I guess I have to “stake my claim”.

I released a small excerpt back in October, which was posted on the Agile Journal website. It was intended to be the first part of a multi-part post. Unfortunately, after posting, 2 things happened: first, I crashed and burnt out, which put me out of work for a few months; and second, during the time I had to work on the book, the whole direction and structure of it changed. This meant that a continuation of the post would not have been a book excerpt, but a separate article, and I didn’t have the energy to do that. My apologies to all of you waiting for the follow-up.

Writing

So, I’ve come full circle. “Coaching self-organizing teams” started out as an advanced training course which I held in-house for my best clients. It’s one of a group of courses I developed to help people working as coaches and ScrumMasters to do their job better. I’ve presented shorter versions of it quite successfully at a number of conferences:

XP2008
Agile2008
XPDay Benelux 2008
XPDay Germany 2008
XPDay London 2008
OOP 2009
QCon 2009
SPA 2009

and now it’s time to offer the full 1-day course. I’ll be running it in London on Thursday, May 21, and you can find more details about it here. If you’re interested in becoming the best agile coach you can be, you won’t want to miss this course.

Uncategorized

From yesterday’s paper (my translation into English):

Her DNA was found at 39 crime scenes, she was on the most-wanted list for 15 years, police forces from most European countries were on the lookout for her - now we know who the supposed phantom killer is: a 71-year-old woman. Years ago, she worked in a Bavarian factory packing the cotton swabs which investigators use to gather evidence.

It’s still not clear, though, how her DNA got on the swab…

Uncategorized

Back in January, I started using Facebook. My original intent was to use it to maintain a small network of close friends and colleagues I do business with. The demon that is Facebook, though, had other ideas…

I’ve moved my business work over to a bespoke network I set up at Ning, I’m opening up Facebook, and I’m now awaiting the deluge of Dunbar’s 150 acquaintances. I won’t spend 42% of my time nurturing these contacts, though.

Uncategorized

How often have I heard people talking about win-win situations in business, where what they ended up with was was, at best a compromise - i.e., where everyone gets what no one really wants.

At the end of my Scrum courses, I do a final exercise and let the attendees prepare a 5-minute presentation on Scrum. Depending on the people and circumstances, this presentation may be targeted at management, marketing, customers, developers etc. At a recent course, someone asked me how I would present Scrum as an elevator story to management, and I remembered something I used when starting my business in 2001:

Scrum is not a win-win proposition, but a triple win-win-win proposition. It meets the needs of all 3 parties involved in the process: customers, management, and developers.

• Customers  win by getting the product they actually want and need.
• Management wins by having a real-time tracking and controlling of time and budget.
• And last but not least, developers win by having the freedom and responsibility to build world-class products.

That’s my story in a nutshell…

Agile Adages

Almens - the view from my office

Last December, Bettina and I moved our official place of residence from Basel to Almens, where we’ve been living most of the time anyway. It was a shock for me, though, after having spent 28 years of my life in Basel - although considering the fact that I spent 195 days last year on the road, my official address should have been the business lounge at Zurich airport.

In any case, Almens has ca. 200 residents, and they don’t hold elections there. When there’s something to decide, everyone piles into the schoolhouse for a meeting. I just attended my first village meeting Monday evening. Hmmm…it seems that, for many people up here, it’s more important to talk than it is to decide. It reminded me of what I like to say about meetings: the purpose of (most) meetings is to avoid responsibility.In any case, my impression was that the intelligent members of the village had prepared themselves for the meeting, and didn’t have much to discuss. The others, though, did neither, so we wasted much too much time repeating things already stated, and listening to some really stupid arguments. My only consolation was that there was only a CSI re-run on television. Oh well, it looks like my decision to attend future meetings may be influenced by the TV schedule - but isn’t it that way in many other places?

By the way - the picture above shows the view from my office window. I put it in to make you jealous. The schoolhouse is just to the right and behind the church.

Diverse