Goals Goals

Goals are fantastic as standards or aspirational states for regulation. Using a goal as a way to set direction is a fundamental part of Scrum and I am seeing it more in generic "Big A" Agile. of course the goal needs to be the right goal, and if we are inherently goal directed organisms then we need to make sure everyone has their goals aligned.

Having learned some skills for project management the idea of managing a plan based on the original estimates (aka commitments) never seemed right to me. In this situation the goal is to make sure the plan is met, be that the dates/scope/budget. Ah hah! that's project management, the magic is to drive the team to achieve this result. Of course it's also utter bunk, it's hitting the target and missing the point.

My rough sketch above is an attempt to show what I am on about. An idea becomes a plan, then there is some action followed by measuring progress, then checking the progress against the plan. This assumes the plan and the idea are correct. With these two assumptions there isn't much room to make changes. This is a simplification and plans do change, but from what I have heard it's more about "updating" the plan than intentionally varying the plan and re-planning is a significant effort that is met with disapproval.

Now if we manage our work to achieve the goal rather than to follow the plan there is greater opportunity for changing what we doing. The second sketch shows this simple difference, that is to check progress against the goal rather than the plan. Each cycle through the action, measure, check and change needs to be treated as an experiment, where we learn what works and doesn't work to achieve the goal. In this scenario nothing is assumed to be correct until it is proven to help achieve the goal, and we can refine the goal as well.

Unfortunately within a traditional work environment this is a big change in thinking. Outside of a specific R&D team trying something that might fail is rarely approved. Changing this will be a significant challenge as structure of the organisation reinforces these ideas of how to view success.

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.

Ball point game - debriefing and options

The ball point game is a fun exercise to help people understand a whole bunch of ideas for agile/lean/scrum. I have been running the game regularly over the last six months and thought I would put together some variations I play with.

The game was invented by Boris Gloger but I picked it up from Rowan Bunning and you can read the instruction on Kane Mar's blog.

Most recently I have been running the ball point game after a discussion on continuous improvement as the game lends itself beautifully to this. After running the game as described in the links I like to ask the following questions:

1. Who had all the ideas?
2. What roles did you all take?
3. When something went wrong what did you do?

I haven't found a team yet that doesn't give answers like:

1. No one had all the ideas, we all suggested ideas and tried some out.
2. Apart from the person starting the cycle there were no roles.
3. We tried to work out how to fix what went wrong.

I then ask the team to compare this way of working with their usual delivery process, thinking about the three questions again.

Then ask about flow, improvement, reinforce the PDCA cycle ideas.

Dysfunctional forms

Odd balls

For running the ball point game I like to have a mix of balls. Various sizes, textures and weights. The variability greatly interrupts the flow of the team and several teams work out that as the balls all have the same value (one point) they might as well discard all but one type.

Debrief - the varying ball sizes are like varying sizes of requirements (stories, PBIs etc). With varying sizes it's difficult to create flow. As requirements are information there will be some variation but there needs to be effort put it to even these out to allow teams to develop flow.

Multi-tasking

As the team is going so well (after the 5th iteration) I need to take some people out of the team to help another team to do better, so these guys will be available part time. All rules stay the same and the part timers are considered part of the team.

To make this happen the part timers need to stand with their hands behind their backs when I say so - this is when they are working with another team. The team has 2 minutes to plan and give an estimate.

When running the iteration I watch the clock and call "out" to signal the part timers are to have their hands behind their backs and "in" for them to return to the team. The whole team stops when I call "out" and restarts when I call "in".

This is not a fantastic analogy for multi-tasking, it would be better to actually have two teams going at once and have these people on both, or have the people walk away from the team to give them as sense of task switching maybe I'll try that some time.

One team recently put the part time staff at the end of cycle, and when they were "out" the team put all the balls in a bucket ready for these guys when they started again. What happened was the bucket near the end filled up quickly, never emptied and the original ball source ran out of balls. This was interesting to debrief to help these guys see the problems of a push workflow with the throughput constraint on the end not having any control on what was coming in - dunno if I succeeded with that.

Debrief - multi tasking can really interrupt flow. People working on multiple tasks/projects/teams make it difficult to get work done.

Problem - this makes it look like people working part time are a pain in the butt for delivery.

Co-location

Another fun dysfunctional form is to stop the team from co-locating. Give the team the usual planning time but no team member may stand within 3 metres of another. All the rules are the same.

Debrief - it's harder when you are not right next to someone you are working with. It's more difficult to respond to what they are doing and vice versa. There is essential non-verbal communication that you can have when you are co-located that helps to enable more useful verbal communication.

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.

Book Review - Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum

Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum by Craig Larman

My review

rating: 5 of 5 stars
This is a fantastic book to help with the issues of taking scrum/agile/lean/xp from a small software development team into a much larger scale product development effort. The depth of knowledge and experience of the authors is demonstrated by the fact that they don't give any silver bullets, but describe tools for dealing with complexity of scaling.

The first half of the book on Thinking tools is well considered and useful. Most of it isn't a surprise to me, but the section is well written and distills the fundamentals of systems thinking, lean thinking, queuing theory, false dichotomies and being agile very well. These thinking tools are used to help the reader understand the concepts in the second part of the book on Organisational tools.

Organisational tools is fantastic, covering Feature teams, Teams, Requirement areas, Organisation, and Large-scale Scrum. Using experience and the thinking tools Larman & Vodde describe why you would adopt these tools to help scale. I regularly did the "d'oh, it's so obvious when you put it like that" forehead slap reading this section of the book.

The recommended readings and fantastic reference list at the end will ensure I blow another huge wad on books this year.




View all my reviews.

It works, who'd have thought?

Why do a stand up?

Last week I had a call from the lead that is not on same site as the QA ask "can we do a deploy, or will this affect the testing?". It's nice to be asked, and the answer was easy "In the stand up the QA said she was not testing in that environment today..." and just to keep everyone chatting "...give her a call though".


Why demonstrate at the end of the iteration?

Business availability on my current project is not a problem, they're at stand up, they're around the team, they're on the phone, they're there, it's great. Despite this proximity and their close involvement with work as it progresses, at the last demonstration they asked "what are we doing about saving in this app?". Then there was a discussion about what they understood the behaviour should be and why. It was great to have this feedback with entire team there to hear, question and understand their ideas.

The best things in life are free, but that's for the birds and the bees

Compensation of agile teams (XP teams, scrum teams, what-have-you) is a tricky issue. Ken Schwaber takes a stab at it in "The Enterprise and Scrum" (if you haven't read it, the bad news is the lack of Star Trek references) where he ties parts of compensation to enterprise performance (doesn't even say "warp factor" anywhere) which is nice because you want everyone focused on the enterprise and not their individual role. Mary and Tom Poppendieck have a swing at it in "Implementing Lean Software Development" and make some nice points about promotion, influence and my favourite "Find better motivators than money" - something I particularly support because
1 - I'm not motivated by money (ok I like not being poor, but I prefer books & music to cash though I do like Pink Floyd's Money)
2 - It works with Prof Vroom's expectancy theory, which looks to have some reasonable thinking behind it and how can you doubt someone with onomatopoeia for a surname?

The problem with compensation is - IMHO - organisations couple compensation with organisational structure and motivation/incentive (can you couple three things?). The higher up the structure the more compensation, and the bigger and broader the bonus (eg retention bonuses). When you have a self-organising, cross-functional team the structure is removed. These teams are organised around enterprise/product/project goals so incentive for role based performance fractures the team mindset.

So here is an idea I have been toying with ready to be torn apart by better thinkers.

Salary should be a factor of responsibility and (positive) influence (ok that does mean the higher up you go in the org chart the more salary you should have). Individuals with great deal of organisation experience should have both of these, ie if you can influence how the organisation behaves you should have some overt responsibility for the outcome. This allows for people with different skills and preferences to be adequately payed without giving up their vocational passion to earn more by becoming a manager.

If there must be a bonus give it at the team level, if there are multiple teams give it at the project level. Then have the team decide how to adequately distribute the bonus. Wait, that was too easy, and you can't trust the team to look after that kind of thing - but you can trust them to deliver on a strategic, money making project.

Ok, how about do it like this. If there is monetary bonus it should be associated with the outcome of some work. Some of the benefit the organisation receives from this work should be taken to reward the team. I now depart from K Schwaber's idea in that I think the bonus should distributed dependant on your contribution, and not you seniority. Taking Kerth's Prime Directive (that's a touch treky "remember the prime directive number 2s") everyone has worked to the best of their ability and I think should be rewarded evenly, they are already being payed based on the difference in influence and responsibility so don't double up.

Distribute the bonus based on the number of days/iterations people were working on the project. If you're on the gig from day one, you receive the maximum amount, if you're on it one day it's the minimum. People who work across projects in a kind of consulting role should pick up the dosh from all the projects they touch.

To make this work all projects will have to have explicitly stated value that can be demonstrated, which is surely a good thing. Think of the pleasure of portfolio management.

A side effect would be that everyone wants to be on a small team doing a high value project. Which is ok, because why would you do low/no value projects, and to deal with the need to have longer project have these projects do multiple releases to deliver some return before the end of the project.

No one will want to work in BAU or Support, so get rid of it. "Developers should eat their own dog food" J Sutherland 2008. If you make it/design it/depploy it you're responsible for it. So this should keep people focused on delivery high quality results.

The product owners that regularly return their estimated value would quickly stand out, not just in the finance department, but when teams form everyone will want to work with these people.

There must be significant problems with this agile utopia, but I hate to contradict myself so I'm not going to think about it. I also didn't bother with expectancy theory and trying to work out the motivators for individuals, get over it - I did. There is nothing here about how to hire or review people if this is implemented, sorry about that.

The big bang smack down

Recently watched a couple of peeps from Salesforce.com give a presentation on their fanfare, reverb for the voice "agile transformation". There were many points to their presentation that made me go "ewww" and "ahhh" but what struck me the hardest was the big bang, all at once approach for the change.

My general opinion is incremental change, prove the new stuff works, and grow teams and projects organically from this. The hassle with this is the still running waterfall projects that will be running when the first agile project is started. No agile project in a normal waterfall shop will start well, it will be a complete disaster, every problem from every project will be exposed in the first few weeks. The project will be red - because project managers can only cope with three colours - and everyone up and down the food chain will hate it. The concurrent waterfall projects will be considered a haven of tranquility and good news, not like that *$#@ing agile project. Any team member who isn't comfortable in the new project will want to run back to the good ol' way and they will have the voice - from experience - to let everyone know how crappy the agile project is.

If you do all projects at once, every person and team, then everyone has a crappy time together. There is no "well running waterfall project" (ohh look at that spec, and that Gantt chart, now that's how you deliver software) to turn back to, to compare to, to contrast with. It's all or nothing. Lance the boil. I like it.

Learning - Maturity

Watching two games of netball last weekend I witnessed an example of team maturity.

The first game was children learning their favourite game. Two good teams, but both are still learning how to play the game. Both sides were "teams", people drawn together with a purpose and direction. They worked together to achieve a goal - no pun intended.

The second game was a professional game with highly skilled and trained athletes. These teams are made up of masters of the game, some of the best players in the world were on the court. The rules were the same as the first game and the outcome was just as close (one point) but the execution was different.

The first teams were strongly focused on what they needed to do in their role, where they could go on the court, where their matched opponent was, what ritual in the game was being performed. The children would stop suddenly at the sideline or the line of their zone. They knew if they were Centre there was another Centre to look for, when the ball left their zone they stopped as there was nothing more they could do. They exemplified a strong demarcation in their roles and actions, and this is part of learning about the game. Just like learning a new role, or new job.

The second teams were markedly different. Apart from the skill, the boundaries were constantly being pushed. The ball moved forward, across and back down the court with the one team working as an organism attempting to achieve their purpose. Individual marking was replaced with a zone, if one-on-one marking was required marking your exact opposing player was less relevant, what mattered was that opposition players were all marked. The lines of the court meant Jump! Stretch! as the players played the ball in the air, not touching down out of the court or offside until they had passed. The team worked within the rules but pushed each one.

What am I going on about?

A team that works within its rules and boundaries without pushing these can achieve their goal, but is an immature team or a team that is learning what it can do. A great team is the team that pushes their boundaries to achieve their goals. The focus shifts from individual effort first to team first.

Hardly profound