Changing - conceptualisation

Earlier this year a colleague asked me what I would look for in a organisation considering adopting agile. Where would I stick my nose? (paraphrasing, she was more polite than that). Being a whiteboard junkie I grabbed a marker and drew the following.

Technology - what the development group create and maintain

People - organisational culture, teams and individuals

Process - how do they try to make the work work

Environment - what is the physical environment like to work in

The idea is that agile software development is influenced by these four forces/elements/modalities/thingies/horsemen. The conclusion of my 5 seconds of thinking is that if you want to adopt agile you need to have a good hard look at each of these and how they will influence the change.

I now like to think about this without "agile" in the middle of the picture - as I think the idea is more generally applicable without the A word there. How do these forces influence the way an organisation develops software (or do pretty much anything)? So something more like this (based on Greene and Grant 2003 - house of change).

I think each of these forces has a balancing influence on the others, so that a change to one will be pulled back by the others, a sort of equilibrium. Any attempt at making a significant or lasting change will need to take this into account. (There is an inkling about entropy too, but that's still in progress.)

For example making a change to "go Agile" may start with changing the way projects are run to work in iterations ie a process change. The organisational state before the Agile adoption came about from the influence of more than just the delivery process and none of the following processes have changed:

• Hiring
• Release management
• Funding/budgeting
• Organisational change

The organisation has been structured to support these processes (and many many more) and the original project process is part of this melange. There is now a foreign body in the organisational system and it may end up being treated as one.

What about the other forces?

Technology - no change. Unless there was attention to technical excellence before the process change this is going to hurt. Odds on that delivery to time and budget trumped internal quality.

People - no change. The same people, who may have been comfortable with how work was before the change, and the same structures to support the people. A culture that developed from how the organisation worked. Teams that may have competed now need to collaborate.

Environment - no change. Maybe everyone on the team is on the same floor or in the same building, but this is not real collocation. A nice open plan office - recommended over the alternatives - is not really the place for noisy exchanges of ideas, you end up having stand ups in a meeting room, story walls hidden in the computers so no one is disturbed.

What's the point?

To make a change you need to have a holistic or system perspective, unfortunately conceptualising the entire system is difficult. Making effective change is hard, even when there are no explicit forces against the change there will be tacit forces that will hold you back. No amount of analysis will reveals these forces so get going and expect to learn about these on the way, and make that explicit.

Greene, J., & Grant, A. M. (2003). Solution-focused coaching: Manging people in a complex world. Auckland, New Zealand: Pearson Education New Zealand; New Zealand.

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.

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.