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!

- Nice post about what it really means to have a cross functional team

- Other good post from Boris Gloger, about responsibility in a Scrum context

It’s a known fact that even though Scrum is a simple methodology, its simple concepts are frequently misunderstood. So, let’s mix the aforementioned quest for a software productivity measurement with those misconceptions around Scrum, and what do you get? Answer: the use of Velocity as a productivity measurement.

Using a single number (like Velocity) as a measurement of a team is plain wrong for several reasons:

1 - It’s very easily cheatable - inflate your estimates in story points, add water and… voilà: higher Velocity.

2 - For starters, Velocity doesn’t ever tries to measure productivity. Velocity is an agile planning tool! It tells us, as a team, how many story points we can “burndown”, on average during a sprint. Therefore, it helps the team to get an idea of what they can commit (roughly) on a Sprint Planning. So, let’s use Velocity for it was intended: to help us plan.

In my opinion, this focus on measuring productivity is misplaced. Let’s use that energy in measuring return of investment, on post-controlling the projects we delivered - in short, in analysing the true results of our finished product… instead of obsessing over an abstract number.

If you parachuting from a plane, you can cut the strings to the parachute in order to go faster - but will you get the desired results in the end?

Just a quick heads-up: you can find my review of “Making Things Happen” at McLean’s blog (to whom I thank for publishing it) , more specifically here.

Following the success of the first meeting, I’ll be present on the second offline meeting of PM forum from Xing.

Where: Vienna, Austria - Brandauer’s Schlossbräu , Am Platz 5

When: 14 Feb 2008, 07:00 pm — 11:45 pm (Berlin Time)

See you there :).

Here is a very interesting article about velocity signatures of agile Teams (thx, Dan)

If you are used to work in the command and control way that is implicitly imposed by futurology-based predictive processes, such as Waterfall, Scrum might look (at first site) like a “The Captain is Out to Lunch and the Sailors Have Taken Over the Ship(*)”-process. It’s the team members that attribute tasks to themselves? Whoa, what a chaos!

Not really. Remember that using Scrum means that the team is self-organized and (hopefully) autonomous. In order for a team to be self-organized, it takes a lot of discipline!

Let’s look at some examples - it takes discipline to:

• be at time everyday for the daily scrum meeting
• update, at the end of all working days, the estimated time remaining to complete the tasks you were working at
• concentrate on finishing the task you have in your hands, instead of starting 6 different tasks (and then finishing none, in the end)
• don’t interrupt co-workers when the are reporting their status during the scrum daily meeting

.. and that’s just for starters.

It takes a lot more discipline to work in a Scrum team, than to work in a command and control environment: on the later, you just do what you have been told to.

—————————————————
(*)winking at Mr. Bukowski