Category Archives: Project Management

My Tack on Effective Change

One of the key characteristics of how we coach our clients’ teams is that we help them start from where they are and introduce small, frequent changes that help them progressively achieve their goals.

Each incremental change is driven by a problem the teams recognise they are facing. We then help to find a small change they are happy to introduce as an experiment. This change must be a solution or a step towards a solution to the identified problem. Sometimes this experiment will be limited to a single iteration. Sometimes it’s limited to a single user-story in a given iteration.

Based on the outcome of the experiment, the team decides what to do next. They may continue the experiment, introduce the change beyond the limitations of the experiment or even abandon that change and try something else.

This has two distinguishing factors.

1. Solving Problems: We focus on solving problems not introducing solutions

2. Continuous Improvement: Delivery continues, becoming increasingly productive

1. Solving Problems: For example, we’ve often been contacted to ‘introduce TDD’ or ‘transition a team to Scrum’. Usually, we find that behind these solutions are problems that our client instinctively understands are there but articulates them as these kinds of solutions. Sometimes they want to reduce the amount of re-work, or get early visibility of achievable scope within a time-constraint. Other-times it’s a solution for solution sake.

By solving the problems the people in the organisation recognise as holding them back, they are bought into each change. Sometimes our job is to help them recognise the problems. Retrospectives are a great way of achieving that.

2. Continuous improvement: When helping an organisation to solve the problems they face they expect large and significant change. Instead we help them make a continuous series of small, team-driven changes. This allows them to continue to deliver with the net effect of gradual and continuous improvements in productivity.

We generally find ourselves taking this approach because for most of our clients, big-bang change is not practical simply due to the impact on productivity. We can understand this using the Satir Change Model (explained very well by Steven Smith).

In this simplified and slightly adapted representation, you can see that with a large change there is a period of net-negative productivity. Once the improvement starts to take hold, performance increases take productivity back into the black.

On rare occasions when an organisation’s software reaches critical mass (it’s more expensive to change than to replace) big-bang changes might be necessary. We’ve worked with a client that had exactly that problem. They took the brave step of ceasing delivery while they redefined how they did things and coached their teams in how to do it. This worked out positively for them. After about 6 months of intensive coaching and 3 months of implementation they delivered a revenue generating system to replace something that had been previously worked on for 18 months and had remained incomplete.

Most organisations would find it difficult to take that step and need to continue to deliver whilst transitioning from how they work today to how they want to work in the future. It is for this reason that we find ourselves employing small incremental changes, eliminating the things that add friction to their process – one problem at a time. Doing this with small experiments helps the organisation limit the risk and achieve continuous delivery and continuous improvement.

A way of understanding how this works is with the same Satir Change Model. If we take the curve shown above illustrating big-bang change, shrink it so that each change represents a much smaller alteration to working practices and then repeat, what we end up with is a much healthier looking series of changes.

Yes, each change can slow productivity temporarily but the impact is dramatically reduced and quickly offset by the improvements gained.

The area under the graph is productivity. If the changes are small enough there is never any period of net-negative output.

Another reason this works well is that it reduces the amount of cultural resistance that you have to deal with. Instead of a lot of resistance from many people for complex reasons, you tend to have only a few people resisting the change. Because the change is driven by a need to solve a recognised problem you have more people in favour of the change. Because change is frequent, people get used to change. In fact, they become experts at it and no longer resist the mere idea of change.

Commercially, it also gives you much more flexibility and allows you to adapt your vision continuously as you learn more.

Julian Davies, a developer at one of our clients, likened this to sailing. To travel from point a to point b in sailing you do so in a series of direction changes, called tacking. This is necessary when point b is against the wind.

You could, theoretically, do this in two long legs with one direction change. However, this leaves you vulnerable to changes in wind-direction potentially taking you significantly, perhaps even catastrophically, off course. Tacking is generally done with a series of small diagonal legs where each leg allows you to adapt to the changing wind. These frequent opportunities to read the context, i.e. the wind and currents, means that we will only ever be slightly off course with plenty of opportunity to recover.

Julian likened it to agile development in general but I think it applies equally to what I’m talking about here today.

With big-bang changes, what happens when we’re in the deepest trough of the curve and an opportunity arises? It is much more difficult to change course. With small changes we can put the latest experiment on hold to capitalise on that opportunity. When the wind changes on our projects, say when someone leaves or half the team is ill with a winter flu bug, we can quickly respond to those changes.

Acknowledgements: Thanks to Andy Palmer for reviewing this article and providing the snappy title.

Taking repetition to task

This originally appeared on my old blog in March 2010.

Others have talked about the virtues of stories as vertical slices of a problem (end-to-end capabilities) rather than horizontal slices (system layers or components). So, if we slice the problem with user stories, how do we slice the user-stories themselves?

If, as I sometimes say, acceptance tests (a.k.a. examples/scenarios/acceptance-criteria) are the knife with which we slice a story into even thinner vertical slices, then I would say my observation of ‘tasks’ is that they are used as the knife used to cut a story into horizontal slices. This feels wrong…

Sometimes I also wonder, hasn’t anyone else noticed that the idea of counting the effort of completed tasks on burn-down/up charts is counter to the value that we measure progress only with working software? Surely it makes more sense to measure progress with passing tests (or “checks” – whichever you prefer).

These are two of the reasons I’ve never felt very comfortable with tasks, because:

  • they’re often applied in such a way that the story is sliced horizontally
  • they encourage measuring progress in a less meaningful way than working software

Tasks are, however, very useful for teams at first. Just like anything else we learn how to do, learning how to do it on paper can often help us then discard the paper and do the workings in our heads. However, what I’ve noticed is that most teams I’ve worked with continue to write and estimate tasks long after the practice is useful or relevant to them.

For example, there comes a time for many teams where tasks become repetitive. “Add x to the Model”, “Change View”… and so on. Is this adding value to the process or are you just doing it because the process says you should do it?

Simply finding that your tasks are repetitive doesn’t mean the team is ready to stop using them. There is another important ingredient, meaningful acceptance criteria (scenarios / acceptance-tests / examples).

I often see stories with acceptance criteria such as:

  • Must have a link to save the profile
  • Must have a drop down to select business sector
  • Business sector must be mandatory

Although these are “acceptance criteria” they aren’t what we mean by acceptance criteria in the context of user stories. Firstly, they are talking about how the user interacts rather than what they need to achieve (I’ve talked about this before). Secondly, they aren’t examples. What we want are the variations that alter the behaviour or response of the product:

  • Should create a new profile
  • Profile cannot be saved with blank “business sector”

As our product fulfils each of these criteria, we are making progress. Jason Gorman illustrates one way of approaching this.

So, if you are using tasks, consider an alternative approach. First, look at your acceptance criteria, make sure they are more like examples and less like instructions. Once that’s achieved, consider slicing each criterion (or scenario) horizontally with the tasks rather than the story. Pretty soon, you’ll find that you don’t need tasks anymore and you can simply measure progress in terms of the new capabilities you add to your product.

Updated 30-02-2010: I’ve inserted a new paragraph as the opening paragraph referencing an article on slicing user-stories to add some background to the vertical slicing metaphor. I’ve provided a link but I’m not sure who first came up with the metaphor.

From Scrum to Kanban – good and bad reasons to switch…

This originally appeared on my old blog in February 2009.

There are, IMHO, some good reasons and some bad reasons to consider switching from Scrum to Kanban… or for considering Kanban over Scrum as a starting point for ‘going Agile’ (so to speak)…

‘Good’ reasons for considering Kanban are…

  • Wanting/needing more visibility of specific development process constraints (bottlenecks) than Scrum gives you (Scrum shouts “there’s a problem!”, Kanban points at where the problem is)
  • Kanban can avoid waste of stories not filling a Scrum sprint (although finishing ‘early’ can allow teams to make improvements they might not otherwise have afforded themselves)
  • Kanban can focus teams on vertical stories from the outset whereas new Scrum teams seem to start with horizontal slicing.

‘Bad’ reasons to choose Kanban over Scrum are…

  • Wanting to say you are “Agile” without really changing your development process
  • Because using Scrum is exposing rigidity and brittleness of software that is the output of your development process and wanting to hide that behind Kanban words like cadence
  • Hiding impact of speculative design behind Kanban work-items when it fails in Scrum because the work never seems to fit into a Sprint, spilling the story over multiple sprints

(by speculative designs I mean implementing architecture that is more than is necessary for current valued-work-item)

For a team that has legacy development practices, producing legacy code for which it simply isn’t realistic to do incremental and iterative development but wants gradual and continuous improvement… I think Kanban is perhaps a better place to start. Your first ‘work-item’ may take 3 months… but it’s an honest 3 months! The trick is to make continuous improvements to gradually increase the tempo of your delivery.

If a team needs to suffer the pain – that comes from seeing that no matter how hard you try you simply can’t fit the implementation of even the smallest feature into one month – before it realises it has a problem… Then maybe Scrum is the better place to start.

Whichever you choose, I hope you choose the right approach for you, for the right reasons 😉

MARTA – Risk Management… beyond mitigation

Originally posted on my old blog in November 2009:

In a previous rant about the misuse of the term mitigate in the context of risk management I listed the following strategies (I call them MARTA) for managing a given risk:

  • Mitigate – Reduce the severity of its impact
  • Avoid – Don’t do the thing that makes the risk possible
  • Reduce – Make the risk less likely to happen
  • Transfer – Move the impact of the problem to another party (e.g. insure such as paid insurance or outsource with penalties for failure)
  • Accept – Do nothing or set aside budget to cope with the impact

I recently found myself having to explain this and used the analogy of crossing a busy road with fast-moving cars. What’s the risk? Well, you might get hit by a car.

This will probably be more useful if you take a moment to think of a busy road with fast moving traffic that you know of and then use each of the above strategies to identify different ways of managing the risk. What factors would be significant in deciding on which strategy (or combination of strategies) was the way to go?

Ok, now that you’ve had a chance to think about it, here is what I came up with:

  • Mitigate – Walk down the street until I can find a section of the road where there is a 20mph speed restriction. (This is mitigation because I’m not necessarily making it any less likely that I’m hit, but if I am hit the ‘impact’ is reduced – i.e. I’ll probably live – albeit with injury).
  • Avoid – I could simply not cross the street, by deciding that whatever is on the other side simply isn’t that important or I could use an underground subway (which of course has other risks associated with it depending on the area you’re in).
  • Reduce – Find a stretch of road where there are fewer cars – reducing the probability of being hit by a car.
  • Transfer – Get someone else to cross the street, maybe someone more skilled at crossing the road than me.
  • Accept – Now, if it was a busy street, I wouldn’t ‘accept’ the risk. But, if the road allowed for lots of visibility and there were very few cars and there were speed bumps slowing the traffic down to 10mph then I might just accept the risk.

The person I explained this to found this to be a useful exercise in understanding my views on risk management – beyond mitigation. Hope you find this way of explaining it useful too.