Chocoholic agile adoption strategy - cont'd

After adopting the chocolate scale the team I wrote about has started using the scale as punishment for arriving late at stand up. The first person late must bring the smallest chocolate on the scale (furry friend), the second brings the next larger (chunky) and so on. The punishment resets after the 1kg block has been bought and consumed.

After a few days of non-belief and some small chocolate bars bought the team is now up to the 500gm block for the next late arrival, and has been for a week.

Do we really need to sit together?

I think co-location rocks for teams.  The first time I had the pleasure of trying Scrum proper-like I stuck three devs in a broom cupboard to work together, one of them still talks to me (he even uses nice words).  Is co-location really important?  Software development is a social process so people will communicate anyway even if they are close but not co-located, won't they?

In Managing the Design Factory Donald G. Reinertsen has a graph very much like this one.  It shows the probability of technical people communicating weekly by distance.  The original data is from a 1977 publication, so pre-email/SMS/IM/Twitter.

Warning - graph is an approximation of the data. As I don't have the actual data I have reproduced this as best I can.

At a distance of 10 metres the probability of technical people communicating to each other everyday is pretty low.  

If you're working in a serialised process you probably don't care - they don't need to communicate, it's in the spec.  

If you're working with a concurrent or collaborative process then you need the people side by side.

"But we have a stand up/daily scrum, so everyone communicates once a day.  We can skip this co-location bollicks and leave people at their desk."  OK, but are you more more open with someone you know well or someone you don't know well?  Co-location allows people to have the general getting know each other conversations that break down barriers and build relationships allowing for richer communication so they can tackle more important issues (eg What's blocking me). So nerr.

Chocoholic agile adoption strategy

I have been working with a team that had a go at relative estimation of their work rather than absolute or duration based estimation. We had some difficulties that I may cover in another post - when I get my act together - but the most enlightening part of the process for me was coming up with a scale they were willing to adopt.

The team members were more comfortable with duration based estimates for their work, but it was hoped to move everyone away from this to a scale that didn't carry any commitment baggage. During the discussion on estimation this came up

"If I am doing this work then it will take a day, if someone else does the work it will take longer"

 this  gave us a basis  to talk about using a different scale that does translate between people and tasks.

Story points didn't mean anything to the team as they are not working on user stories. I flippantly suggested Gummi bears, and this was quickly changed by the team into chocolate. The chocolate scale - based on Cadbury's chocolate blocks - has been adopted.

From smallest to largest:

• Furry Friends
• Chunky
• Half block
• Family block
• Half slab
• Slab

Potential problems with the chocolate scale
How do you calculate velocity? Is it 5 furry friends and chunky? What does this mean? The team lead is looking at using the net weights of these blocks as a numerical measure, we'll see how it goes.

What about inconsistency across teams because of different scales? In the longer term I think this would be a big issue, currently there are only two teams using relative estimates (this team and one developer working solo) so it's not an issue now. At present this is traded off against having the team start to think about their work in a different way. Eventually it may be required to standardise for communication and metrics,  the risk of this approach is to give the team control of something and then take it away.

What did this achieve?

The team now has a scale that is their own, I think ownership is important when you are asked to change. It might be flippant, but it is relative and there can be no confusion as to whether this is a commitment or an estimate. (Though I'd love to hear the usual please reduce your estimates conversation "4 family blocks and a chunky, come on that's way too big, surely it's only 3 blocks and a furry friend".)

The team have also estimated 2 weeks of work using this scale. Previously the estimation process stalled now using their own scale it was estimated very quickly.

Managing the design factory

I think I picked up "Managing the design factory"  from the references in the Larman & Vodde special. I wish I had read it years ago, so far it's a cracking read.

From the introduction

There are no best practices

...Best practices are only "best" in certain contexts and to achieve certain objectives.

..The great danger in "best practices" is that the practice can get disconnected from its intent and its context and may acquire a ritual significance that is unrelated to its original purpose.

Aaaaaamen brother