CDE and Big Brother

Dear Junior

What can a sleazy soap opera teach us about coaching agile teams and their managers?

It was somewhat a surprise to me when I realise that the reality TV show Big Brother makes a good metaphor for explaining one of my favourite models for understanding self-organised teams: the CDE-model.

The Big Brother TV-show is a non-scripted soap opera where a bunch of people are locked up in a house together and followed by cameras day and night. The "thrill" of the show is how the people interact and react upon each other.

The CDE-model is a system-theoretic model to reason about how teams self-organise as a reaction on their surrounding. Of course these reactions are very non-linear and hard to predict.

What on earth have these two things in common?

Let us put ourselves in the shoes of the Big Brother producers. Say that the events in the locked house have become a little bit dull lately. The people locked up have settled for a pace of life where they all sustain without unnerving the others. Nice for them, but not thrilling TV. We need something to happen.

The problem for us is that Big Brother is non-scripted. We cannot direct Susan to "go and snug up Jonathan", even if we think it would be an interesting turn of events. We need to find other ways to change the behaviour inside the house without giving explicit directions.

So we decide to shake them up a bit by changing the conditions under they live. A rough partition can separate three types of conditions: containers, differences, and exchanges.

Containers

One type of conditions we can change are the containers.

We can lock the yard so that they are locked indoors. That will unsettle Bob who is used to take his morning strolls there. He might have to spend his mornings in the kitchen together with Alice, who has a terrible temper before getting her coffee. Or, we can open up an extra room, one that is a little bit hidden away, with very little insight - apart from the camera of course. Or, in the middle of the night we could push in an extra wall dividing the house into two parts; let us ensure that Tom and Lisa are locked up in one part, and Toms rival Jerry in the other part. Or, we could simply remove all doors. That could be fun.

All these are examples of changing the containers that contain the contestants - making the containers bigger, or smaller, or less connected, or more connected, or even dissected. 

Containers need not to be physical, there are other ways to divide a group. We can create a competition between two teams, then the teams become sociological containers. The teams can follow some obvious partitioning like city of birth or gender, or by some arbitrary dissection. 

The important part is that containers effect the patterns of interactions, so changing containers will change the behaviour.

Of course we could interpret "containers" literarily and put them all in a freight container. That is an idea.

Differences 

Another type of conditions we can change are differences and how they are resolved.

We can stir up events by introducing differences. For example, if we have an group of contestants with the same ethnicity we can send in a new contestant of a different ethnicity, for example sending in a white guy when there are only hispanics in the house. Or send in a professor of philosophy in a house with high-school drop-outs. You get the idea.

Sending in someone fair-haired when all are brown-haired will probably not make a lot of fuzz. In Big Brother, hair colour does not make a difference to how people treat each other - at least not in a way that make a significant change. We say that we only consider "significant differences". 

It differs from situation to situation what is a "significant difference" but in general the nuance of hair-colour is not one, whereas gender is - men and women are (sadly enough) treated differently. Same goes for ethnicity, sexual orientation and lots of other traits. All those are significant differences.

Introducing or enhancing differences are sure thing to induce change, but sometimes reducing differences can also unsettle the state of things.

Let us say we want to send in one person when there are four men and one women left in the house. Sending in a man would enhance differences from 4-1 to 5-1. Sending in a women would reduce gender difference to 4-2, but would probably be more interesting.

Apart from the differences as such, we have the issue about how these differences are resolved. 

One contestant might enjoy a particular kind of music, and preferably at high volume. Another contestant might not be so fond of that particular kind of music. However, they might be able to stand each other on a day-to-day basis. The difference is manageable, handling it is not difficult.

Now we can amplify the difficulty to manage differences, for example by introducing a large amount of liquor. Should either of them get drunk, or both, it will be harder to resolve the difference in taste of music, and we will probably see some interesting conflicts. 

Another difference is food preferences, one way to amplify the effect of this difference is to insist that everybody in the house agree on what should be served for dinner. Can be fun to see how Mark "must have meat" tackles Vegan-Lisa, even more interesting when he gets hungry. 

As differences and resolving differences are a major driver for interaction, obviously changing those differences will change behaviour.

Exchanges

Third and last of the conditions are the exchanges with the outside.

If we let the contestants interact with the outside things will happen. We might let each of them have a (filmed) phone-call with a friend. Or we can have a small room where one at a time is allowed to speak to the audience. Or we might take away that room. We could put up a big TV showing news from the outside. We could fake the news we show. Surely things will happen.

Exchange need not to be communication. We can change the way food is delivered to the house; instead of small deliveries every day we make one big delivery once a week. That will cause some interesting effects at the end of the week when someone has eaten all the goodies on day one. If we are diabolic we can give them slightly too little to eat. Surely things will happen.

As exchanges are the connection between the very limited system in the house, and the very large system on the outside, it is not surprising that how the inside and outside are connected will effect the behaviour on the inside.

CDE

Of course there are a multitude of ways to unsettle the status quo in the house. However considering containers, differences, and exchanges (CDE) gives a good start to think about what leverages we can pull to cause the people in the house to behave differently. Or phrased in system lingo: to make the system reconfigure itself in another configuration.

System theory teaches us that lots of systems are dynamic and non-linear. This means that it is very hard to predict the exact outcome of a change.

As producers of Big Brother we know this. When we nudge the system in the house, we know that something will happen, but we do not know exactly what. We can have a guess, but we do not know. So, we need to be at our toes to watch out if things go another direction, and take compensating actions - or actions we hope are compensating.

Well, obviously neither you nor I are producers of Big Brother. And most probably we will never be. But same ideas can be applied to think about agile software teams that have self-organised and when coaching them or their managers. However, that is a subject which is a letter of its own.

Yours

   Dan

PS To be honest, my description does not perfectly fit how CDE was described by Glenda Eoyang in her Ph D thesis. But I think I am truthful to the main idea.

PPS Glenda Eoyang’s thesis can be read in full at http://www.hsdinstitute.org/about-hsd/dr-glenda/glendaeoyang-dissertation.pdf. A briefer introduction can be found at http://wiki.hsdinstitute.org/cde.

PPPS I think first time I came across CDE was when Mike Cohn introduced it to me during is tour when he released Succeeding with Agile, a good book for a lot of reasons and which also includes an introduction to CDE.

Blitz Retrospective

Dear Junior

One of my favourite method tools is a retrospective format I call the "Blitz Retrospective". I have used it in a lot of situation where it has been impossible to do "large" retrospectives. For example, in some situations, the teams have been very "retrospective sceptic". In other, there has been a formally appointed "scrum master" who was not very open to suggestions, so suggesting changes to his retrospectives would not achieve much. In yet other, the sprints have been so long I have not had the patience to wait a few weeks. In all these situations it has been possible to suggest, and do, a "really quick retrospective".

The "Blitz Retrospective" only takes 25 minutes, and its focus is to find *some* change the team think would improve things. The format consists of three parts: the startup, collection of ideas, and vote. 


Startup


If it is the first time, the startup is spent explaining the format so everybody feels comfortable with what will happen. I clarify that the purpose is to find one single idea of improvement that we will try out next week.

A question that always come up on purpose is why we are limited to one idea, and what happens with the rest. Well, if the timespan is only a week, it would be foolish to focus on more that one thing - it would just result in none of them being changed. 


As for the rest of the ideas that come up - they will be there in the back of peoples minds and might change things implicitly - but they will not be actively in focus. If it is not the first time, I usually quickly rehearse the procedure, but I spend the time on evaluating the last retrospective's "winning idea" - more on that later.

The startup in full should not take more than five minutes. 


Collection of Ideas


Second section is the collection of ideas. To help the team members I split a whiteboard in three sections labeled "Continue/Increase", "Start/Try", and "Quit".

First section "Continue/Increase" is for things we already do and that support our work. Second section "Start/Try" is for ideas that we think we should benefit from, but we do not do it already, at least not in any significant amount. Last section "Quit" is for things team members think we do, but should stop doing as it does not serve us well, or even harm us.

Then team members are free to write down suggestions in any of these sections. Usually, I let them write on stickies, so that they can write a short statement on the sticky and explain it briefly when they post it on the board. If a short discussion emerges, then fine. However, if it seems to turn into a debate, or risk running long, I cut it short pointing to the purpose (find one idea) and the procedure (there will be a vote later). 


I also try to convince the team to keep the suggestions very concrete and limit them to thinks they directly can effect. For example, replacing the ventilation system of the building might really improve, but selecting such improvements is just asking for failure. In other retrospective formats such ideas are really valuable, but the purpose of Blitz Retrospective is basically to get acceptance for retrospectives - and then they must make a difference. We want things we actually can do, and that we can do within a week.

The collection of ideas could take ten to fifteen minutes. On occasions when time has not been an issue, I have let it run on longer - but usually most ideas are on the board after ten minutes. 


Grooming the List of Suggestions


When getting closer to the end of collection of ideas, I take a more active role, starting talking about the stickies in the "Quit" section. 


It is extremely valuable to get the "Quit" feedback, and I really encourage people to post such suggestions. However, I am a firm believer of that you should focus on "telling the good stories", because the stories you tell (and repeat) will become part of the "team lore" and shape the atmosphere of the team work. This is the basic idea behind the organisational philosophy "Appreciative Inquiry".


So, telling "bad stories" will basically make people feel bad - but not do much good in the long run. Telling "good stories" will culture a nice team atmosphere as well as enforcing the good habits.


Therefore I take on the role as the "positivist fanatic" and try to rephrase each sticky under "Quit" into "positive" ones. For example, if a quit-note says "stop coming late to meetings", I might suggest a start-note "meetings begin exactly on time - even if people are missing".


Before throwing away the "Quit" not I ask the original poster whether the new notes have captured the original purpose. Surprisingly often there is an additional aspect I had not understood. In the "begin on time" example, the poster might say: "It is not only about starting on time, it is also that every time someone arrive (late) there is a start of chit-chat and small talk that disrupts the meeting". To capture this there will be a second note start-note "keep meeting focus when people arrive mid-meeting".

I also ask if there are some suggestion that the poster think is a duplicate of some other - if so they can have it removed. Merging two similar suggestions to one of course gives them a better chance to "win".

Still when "grooming", the board is still open for new ideas, it is just for the team members to step up, post a sticky, and present the idea.

At the end of collection of ideas there often are a load of ideas and we only have a few minutes until we shall leave the room with one selected idea: time to vote.

Voting

For the voting, I simply rearrange the stickies and let each team member give three suggestions one vote each. The sticky with the most votes is the winner and is what the team should try for improvement the coming week.


As for the rest - things might improve just by having vented them, but they are not in active focus.

Evaluation


Next week I use the startup section for a quick evaluation. Here I want to separate two parts. 


One question is whether we did as we intended at all. Not trying isn't necessarily failure. Things change quickly from time to time and we might have had valid reasons not to do it. Even "did not have time" is a valid reason - and suggests that we should put aside time.


If the team did try the suggestion, the second question is whether it helped us or not. If it was helpful, we try keep doing it. If it was not helpful, then it is important to keep in mind that it was an experiment - and such should have positive and negative outcomes from time to time.


If the suggestion was tried and found helpful, we should find a way to formalize it. Technical stuff might go into a new check on the build server, working habits might go into the team's "Team Rules" or "Working Agreements" - whatever the name. The important part is that we do something that makes it plausible we will continue doing this good thing we have just found.

Getting Retrospectives Going, at All

I have found that running a few Blitz Retrospectives often results in an acceptance of having retrospectives at all. In combination with the not-very-scary format "ok, we can spare 25 min after Friday lunch", it is a good way to get retrospective started at all.

Of course, such a brief format misses many points - things a longer and deeper retrospective will catch. But the purpose of Blitz Retrospective is not to catch those - it is to win acceptance for having retrospectives at all an pave way for deeper retrospectives down the road.

I have found that the format works well for that purpose.

Yours

   Dan

ps Ester Derby and Diana Larsen have written a great book named Agile Retrospectives that is really helpful once you have gotten past that initial resistance, have established retrospectives, and want to elaborate them, specialise them, or just improve them in general.


pps Tobias Fors has made the point (blog post in Swedish) that feeling safe and secure is fundamental to engaging in a retrospective. He suggests the fundamental rule being "Everyone did their best given the conditions", and I have seen it helpful to start each retrospective with writing some similar statement on the whiteboard.

Scrum Coaches Ought to Use Scrum

Dear Junior

Throughout the years I have been in contact with several initiatives to introduce Scrum to either a single team or to an organisation as a whole, as well as myself playing the role as consultant/coach/mentor. Most of the coaches that have driven these initiatives have seemed to be thoroughly convinced of the advantages of iterative work, time-boxing, limited sprint-commitments, demonstrable business value etc. Also, several of them have spoken about how Scrum is not a methodology limited to software development, but that it is a general project framework. Yet, very few of these initiatives, which are projects of their own, have been planned or executed in any way that resembles Scrum, with backlog items, sprints, demos, definition of done etc. Rather, most of them have either been waterfall (“first interviews, then determining sprint length, then …”), or they have been the process equivalent of “happy hacking” (cruising around in the organisation, going to the meetings that seem interesting at the moment, coaching someone here, throwing a workshop there, improvising from day to day).

If they really believe in Scrum, why don’t they use it themselves?

A project “introducing Scrum” out to be run as a Scrum project. In this project the product owner (“Scrum-product-owner”) is the one “owning” the process problem, probably the CTO, CIO or Head of Development; they are the ones that want see visible improvements. The role of the scrum master (“Scrum-scrum-master”) of this project is most probably the coach/mentor. Finally, the team (“Scrum-team”) consists of key people that will do the work of transforming the work: apart from the coach, there will most probably be the scrum master to-be, perhaps someone responsible for processes, perhaps a CM.

The backlog items might be

“As Head of Development

I want an estimated and planned backlog

so that Business side develop trust in that IT work to generate business value”

DoD: Of six named stakeholders, at least four should grade the statement “IT delivers according to priorities and plan” with “agree” or better.

or

“As Team Member

I want peace-of-work for at least two weeks to finish what I have committed to

so that I will be able to finish stuff”

DoD: Team has performed one sprint where they delivered what they committed to at sprint planning

Each of these should give a concrete organisational impact with an obvious value, and that value should be possible to demonstrate.

The team (coach and staff) should estimate how hard it might be to make that organisational change, and for the next month (or whatever sprint-length they choose) focus on that change and commit to make it happen. E g creating peace-of-work might be a fulltime-job to shield the team from “executive requests”, and will then be estimated high. In that case the Scrum-team should perhaps just commit to that story. Or, it might be easy, in which case it will have a low estimate, and the Scrum-team could take on doing something more in parallel. Of course, the Scrum-product-owner (CTO/HoDev) will judge what will give the most benefit for the organisation given the cost (estimates) and select the story that give most bang-per-buck. During the sprint, they meet daily to synch their work, and the Scrum-scrum-master (i e the coach) facilitate that the Scrum-team works in an efficient fashion. After the Scrum-sprint is over, they all meet, demonstrate what has been achieved, have a retrospective to gather and share experiences; and off they go again.

So, why is not more “introducing/improving Scrum”-projects structured this way? From someone promoting Scrum, using it for his/her own work should be a no-brainer.

Or, do they not think Scrum is suitable?

Or, is it awkward to put on the self-discipline needed to actually follow a process?

Or, is it just too hard to come up with a backlog?

Or, don’t they want to give up control to the Scrum-product-owner/CTO?

Or, have they simply not thought about it?

I have no idea. At least, this is the way I prefer to run Scrum-improvement projects, and I am surprised it is not more common that what it is.

I think eating your own dog-food have some merits.

Yours

Dan