Ricardo Mestre’s Blog

(continuation of last post)

Joseph Pelrine pointed to the ABIDE model (from Dave_Snowden) as the “levers” that can be pulled in order to change the way a team is self-organized.

ABIDE stands for: Attractors, Boundaries, Identities, Diversity and Environment. Let’t have a quick look to some simples examples for each one of these “levers”:

• Attractors: add a charismatic guy as a lead developer to the team

• Boundaries: Code sucks? Bring in different testers

• Identities: related with roles and responsibilities

• Diversity: increase the diversity in the team: is the team composed only by Java developers? Bring a new one into the team whose background is .NET – very homogenous teams don’t self-organize

• Environment: change software, change hardware, offer free massages at lunch

In the afternoon, I attended (David Harvey’s) presentation “Social Objects: Dilbert considered harmful?”

So, what is a Social Object? Hugh McLeod (of (gapingvoid.com) fame) has explained it (here quite well in layman’s terms) - a Social Object is a pretext, a reason to people socialize “around it”.

David Harvey’s presentation highlighted that our environment affects how we behave - i.e. your behavior changes according with you are exposed to. And this also includes that Dilbert cartoon printout on your work place. (Read here what David has to say about it); I’ve even stopped to use (my despair.com mug at work) :).

Monday morning continued in the best way possible with a great Talk, “Coaching Self-Organizing Teams”, from Joseph Pelrine.
Joseph Pelrine is a Social Complexity Scientist, and a Certified Scrum Trainer as well.
This great presentation didn’t need support of slides/keynote; it was a pity that it lasted only 90 minutes, I could have listened to mr. Perline the whole afternoon.
To try to summarize this presentation is an exercise in futility. I will try to do it anyway, but it will not make any justice on how it was. You just had to be there.

Let’s start by defining what is Self-Organization.
A lot of times we confuse the concept Self-Organization with Self-Assembly. Quoting Wikipedia,

“Self-organization is a nonequilibrium process where self-assembly is a spontaneous process that leads toward equilibrium.“

The way that people organize - or, more precisely - assemble themselves within a crowded elevator is a very mundane example of self-assembly.
When we have people assembled this way we have a Group, but not necessarly a Team. If a Team is not acting like a team anymore (or never did, in the first place), what we have there is a Group, which is self-assembling. People don’t change their behaviour unless they have to.

Enter the Scrum Master’s role: when energy is applied to this System (and here System=Team+Tools+History of the SW previously developed), the System will move into several states of Self-Organization.

Take into consideration that: a) Self-Organization is a disruptive state (in the sense that it disrupts Self-Assembly, i.e. the pre-determined behaviour, before any energy was applied) and b) it’s a non-equilibrium state that will decay back to Self-Assembly.
And this is exactly why the Scrum Master’s job of keeping a Team on a high productity state is a work that’s never done. If you remove the energy, the Team will decay into Self-Assembly, into the “old ways” and will become a Group.

And exactly how much energy shall be then applied? Joseph Pelrine explains it in a very clear way on his blog: part 1 here and part 2 here.

(to be continued)

As promised, here go some lines about the Scrum Gathering which took place here in Munich last week.

On Monday morning, Jeff Sutherland (blog) kick-started the gathering with his Opening Address presentation.
Jeff’s presentation was overarching, as I’ve expected. Some interesting highlights were:

- If (and only if) your team’s Scrum implementation is really mature, use a story points burndown. In a team which has been using scrum successfully, doing so will make the administrative overhead lighter (compared to estimate time to completion for the tasks the developer has in progress), with a lower risk getting the wrong idea from the burndown state.
- Avoid multitasking. A lot of “work in progress” also means a lot of “waste in progress”. We can only deliver business value when the user story is “Done”.
- If only one element of your team can do a specific task/role/function, starting doing pairing immediately.
- The Product Owner can easily double the velocity of a Scrum team by getting the User Stories in the backlog to a high “Ready” state. I really like this idea – this needs to be done as an integral part of the “backlog grooming”.
- A team of average developers performs better than one with Prima Donna developers (or a couple of them, for that matter). No surprises here, but it was interesting to see the numbers that back up this truism.

The second Scrum Gathering of 2009 took place here in Munich, from Monday to Wednesday of this week.

Since I was ready to fly to Orlando last year to attend there a Scrum Gathering (but got a new job meanwhile), this was an easy decision to take, and I went, unsurprisingly, to this one - and I do recommend it to everyone Scrum Master with some experience his belt.

Since some people already asked me “where are the slides ??” a couple of time,here goes the link  for most of them. I will write later about the event in itself of course, as time permits. Have fun!