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

Some observations on my boys

I have two boys aged 5 & 3.  I have no idea how my gender survives beyond this age range, here's why:

No distance is too short that I can't cover it at full speed.

I like to carry out conversation at ear splitting volume levels.

Anything you ask me to do is, at best, a mere suggestion (unless preceded by "I've told you x times already").

"yeah, she's crying" is empathy.

My selective memory is photographic "awwwww I never get to stay up".

The direction I am running is not the direction I am looking.

I am in constant denial "I'm not a little boy, I'm a big boy.  He's a little boy" .... "No I'm not. Muuuuuuuuuuuuum!".

Are defects the original user stories?

Just asking, and yes the defect comes after you've written something and someone somewhere found out it was not working as expected, but they feel similar to me.  Well at least similar in the context of "We have to have a requirements document signed off by everyone up to the CEO before we can even begin to consider to think about starting some kind of technical specification for the solution, so we could never use stories."

I would guess you already have defects, and when you are decide to fix these there isn't a document that bundles them together in some way (why would you try to do this, most defects would be independent, not all, but most).  There wouldn't be a sign off process, there is nothing to sign off.  The person doing the fix would need to spend time talking with the people who found the defect, and others to work out how to fix it and what the fix will look like - hopefully.

The defects would be - to a greater extent - recorded from the perspective of someone outside the system, rather than a technical task.  Of course there would be some prioritisation on what to fix first, because some defects have a greater impact/value than others.

Defects come with test criteria as standard.

It all feels very story like to me.  Surely if you can work with defects, then it shouldn't be too much of a leap to work with stories.  Maybe.

HBR bloggers wake up; find themselves in 1950s Japan

Managing Resources in an Uncertain World

From a blog called "The Big Shift".

We're moving from a world of push to a world of pull. Push programs operate on one key assumption - that it is possible to forecast future demand. When demand can be forecast, we can efficiently push resources to where they will be needed when they will be needed. But what happens when our forecasting ability diminishes--as it surely has in these big shifting times? Push programs become bottlenecks preventing effective responses to unanticipated changes in demand. In the business world, the result is often large accumulations of inventories.

I hope this isn't new to the authors.  It's probably new to some of the readers.

We only need to look at our dismal record in forecasting business cycles, financial risk, and earnings projections of individual firms from quarter to quarter to see that forecasting is no longer working as well as it once did.

When did the forecasting work?