Book now

Two ways to react

Every organisation that makes software, makes mistakes. Sometimes, despite everybody’s best efforts, you end up releasing a bug into production. Customers are confused and angry; stakeholders are panicking.

Despite the pressure, you knuckle down and fix the bug.

Now it gets interesting: you have to deploy your fix to production. Depending on how your organisation works, this could take anywhere between a couple of minutes and a couple of weeks. You might simply run a single command, or you might spend hours shuffling emails around between different managers trying to get your change signed off. Meanwhile, your customers are still confused and angry. Perhaps they’ve started leaving you for your competitors. Perhaps you feel like leaving your job.

With the bug fixed, you sit down and try to learn some lessons. What can you do to avoid this from happening again?

There are two very different ways you can react to this kind of incident. The choice you make speaks volumes about your organisation.

Make it harder to make mistakes

A typical response to this kind of incident is to go on the defensive. Add more testing phases, hire more testers. Introduce mandatory code review into the development cycle. Add more bureaucracy to the release cycle, to make sure nobody could ever release buggy code into production again.

This is a reaction driven by fear.

Make it easier to fix mistakes

The alternative is to accept the reality. People will always make mistakes, and mistakes will sometimes slip through. From that perspective, it’s clear that what matters is to make it easier to fix your mistakes. This means cutting down on bureaucracy, and trusting developers to have access to their production environments. It means investing in test automation, to allow code to be tested quickly, and building continuous delivery pipelines to make releases happen at the push of a button.

This is a reaction driven by courage.

I know which kind of organisation I’d like to work for.

Agile / Lean Software Development

Comments (5)

Permalink

Thinking outside the shu box

I just got back from the fantastic Lean Agile Scotland conference, where I spoke about why agile fails. I’ve been doing a lot of travelling this year since The Cucumber Book came out, consulting and training different companies in BDD. A pattern I keep seeing are companies who adopted agile a few years ago but have hit a glass ceiling. This talk was a chance for me to reflect on why that happens.

One point I made in the talk was about cargo cults. The term ‘cargo cult agile’ is used to laugh at teams who go through the same ceremonies – daily stand-up meetings, planning poker meetings, story points, velocity etc. – yet in some very fundamental ways, they just don’t seem to be succeeding the same way as organisations who get it. I see this frequently, but I don’t think it’s particularly funny. I think it’s a sad waste of human potential.

I’m curious to understand why it happens.

There are various models for how we learn things, and one of my favourites is Shu-Ha-Ri. This model comes from Japanese martial arts and says that in order to really master something, we need to progress through three stages. The first stage, shu, is about learning the basics. Here’s a quote from Aikido master Seishiro Endo:

In shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forbearers created. We remain faithful to the forms with no deviation.

That’s shu: absorbing the basic mechanics by repetition, without really understanding why.

The next stage is ha:

In the stage of ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process the forms may be broken and discarded.

Imagine that? Broken and discarded! This is the point where we start to ask why; where we start to understand the value of the practices we’ve been using and have enough experience to make decisions about when they’re actually valuable, and when they could be getting in our way.

The final stage, ri is transcendence:

Finally, in ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires, unhindered while not overstepping laws.

I think that sounds like fun.

Anyway, my point is that cargo-culting is just what happens when your team is stuck in the shu stage. If you’ve been on some basic agile training, you might have been led to believe that’s all there is too it; unless you’re aware that the other stages of learning exist, how could you aspire to reach them?

This morning I was asked a great question about the talk: How would I help a team that’s stuck in a cargo cult shu learning stage? I felt like it deserved a blog post, and that’s why we’re here.

My first step with that team is to understand how well they’d really learned the basics. Have the team been given enough support to really get to grips with the tougher agile practices like retrospectives, TDD, or pair programming? What problems are they suffering from and how can they be traced back to core agile practices that the team need more expertise in?

Then it’s time to help them learn and practice those basic techniques. Coding dojos are a great way to practice TDD in a fun environment, for example. Coaching willing members of the team how to facilitate effective retrospectives and helping make sure that actions coming out of those retrospectives are followed up helps to start building the culture of empowerment the team need to become confident enough to move beyond the shu learning stage.

It’s also important to have conversations with management to ensure that the team are being given the space to learn. I often see teams who are driven so hard by the demand to deliver features that they simply don’t have the time to invest in self-improvement. Once a product owner is made aware of this situation, and the benefits of having a higher-functioning team, they’re usually keen to make this investment.

Agile / Lean Software Development

Comments (1)

Permalink

Our Consumer Culture and What it Means for Software Craftsmanship

We have an old Kenwood Chef A701 that’s hardly out of use in our kitchen. A few days ago, the gearbox went. I bought a reconditioned one on Ebay for £23, and this morning I made the time to do the repair.

Kenwood Chef

As I tinkered away with my screwdriver, I reflected on how grateful I was that the designers of this machine had made sure it could be maintained by an idiot like me. I actually made our A701 by cannibalising two broken machines, and I have always been delighted by how easy it is to work on.

Perhaps it’s my confirmation bias, but it seems that machines like this no longer tend to be designed with maintenance in mind. In our consumer society, we’re encouraged to throw things away rather than repair them, and globalisation ensures that is often the apparently rational economic decision to take: paying a local repair man to fix your DVD player will cost more than popping down to Tesco and buying a new one. Thank goodness for those cheap Chinese factories, eh?

If we don’t design our manufactured goods for maintainability, perhaps it’s no wonder we often feel like we’re swimming against the tide trying to persuade people that it’s important in software.

Agile / Lean Software Development

Comments (5)

Permalink

Hi-Fidelity Project Management

If the only metric you use for measuring and forecasting your team’s progress is their iteration velocity, you’re missing out on a great deal of richer information that, for just a few extra minutes per day, you could easily be collecting. This is information that the team can use during the iteration to help spot and fix problems that are holding them back.

If you’re using scrum, you’re probably familiar with using a Release Burndown chart to track the team’s progress, iteration by iteration, towards a bigger goal:

Release Burn-Down Chart

Here we can see the team’s velocity appears to be slowing down. They might still release at the end of Sprint #9, but there’s a chance, if the flattening trend in their velocity continues to worsen, that they may never finish the project at all.

We have enough information here to know that something may be wrong. We can use this information to warn stakeholders that our release date may be at risk of slipping, and may also start looking though the backlog of stories for things we can drop.

The problem with these responses is that they’re purely reactive. Assuming there is a systemic cause at the root of this slow-down, we’re not doing anything to deal with it and get the team back on track. We can go and ask the team what they think might be wrong, and try to help them correct any problems they can identify. This can often work, but sometimes the team may not have the experience or perspective to be able to see what’s going wrong.

Another problem is that we’ve had to wait until the end of the iteration to get this information. For an organisation that’s used to going into the darkness of 9-month waterfall projects, getting iteration velocity figures once a fortnight can see pretty decent. An awful lot can happen inside an iteration though, and having that summed up by a single number loses a lot of important detail. Like the signal on an old short-wave radio, this is low-fidelity data.

One crucial piece of data that’s hidden within the burn-down chart is what I call the rate of discovery. The whole point of agile development is that it’s iterative: we build and ship something, get some feedback, learn from that, build and ship some more, and repeat until our stakeholders are happy with it. If we’re doing iterative (as opposed to repetitive) development, we’re going to discover new user stories as we go through the project, perhaps even as we go through the iteration. This is a good thing: it means we’re listening to our customers. We need to make sure our project plans can handle this as a matter of course.

Going back to our release burn-down, we want to separate the rate of discovery from the rate of delivery. A great way to do this is simply to flip the vertical axis of the chart, and use a Release Burn-Up instead. On here we can start tracking two lines instead of one. First we draw the number of completed stories (or story points), and then stacked on top of that, we draw the number of stories still to do. That includes any story not yet done – whether it’s in the backlog or being worked on in the next iteration.

I love these charts – they seem to easily map to people’s understanding of the project. When you explain that the area underneath the bottom line represents all the features that have been done, it’s easy for anyone involved with the project to quickly understand what it means. In the case of the chart above, we can identify that while the team are delivering at a pretty steady rate, they’re discovering features at a steady rate too. They’ll probably need to de-scope if they want to meet their release date.

We can add extra fidelity to this chart in two dimensions: We can collect samples more often, and we can collect details about just how done the stories are as they move from ‘not done’ into ‘done’. Let’s start by collecting more detail about how done the stories are. Imagine our task board looks like this at the end of an iteration:

One story (Story A) is done, and 8 other stories are not done. As we track these counts over time, we can draw one line on our Release Burn Up chart for each category of ‘not done’ and stack the lines:

This chart has another name, Cumulative Flow Diagram (CFD). We call it this because as stories flow from ‘not done’ to ‘done’ across the task board, we’re drawing the accumulation of that flow on the diagram. There are lots of things we can gleam from this diagram.

If we look at the example above, we can see that work is stacking up in the design stage of our process. Because our CFD chart highlights this, we can put more directed effort into relieving the bottleneck on the designers, perhaps by adding an extra analyst to the team to run ahead and do some more detailed analysis of the upcoming stories in the backlog, or by helping the designers to break the existing stories up into smaller ones that are easier to understand.

You can wait until the end of the iteration to count these numbers, but why stay ignorant? If you collect this data every day, you’ll get quick feedback about where bottlenecks are appearing in your team, and be able to try small tweaks to correct them.

Agile / Lean Software Development

Comments (1)

Permalink

Don’t Confuse Estimates with Commitments

Estimate: an approximate calculation of quantity or degree or worth

Commitment: the act of binding yourself (intellectually or emotionally) to a course of action

  • Estimates are not commitments.
  • Plans based only on estimates are bad plans.
  • Commitments based only on estimates are at best foolish, at worst dishonest.

Estimates are certainly a useful tool for making realistic commitments, but there are many others too that are equally, if not more, useful. Working at a sustainable pace, measuring data about past performance, and facilitating the genuine consensus of the whole team when committing are the way to make plans that can actually be achieved.

Agile / Lean Software Development

Comments (4)

Permalink

My Real Options Story

A few weeks ago I bumped into Chris Matts and thanked him for the ‘Real Options’ session he’d lead at SPA last year. I promised write up this little story about what I took out of it.

When I got back from the conference, my team were at a point where we had to chose between two competing technologies to build something. Looking at the two options, we really didn’t know which one to go for: they both had advantages, and at that time they were both unknowns to us. Wearing my new ‘options thinking’ hat, I realised that we didn’t need to choose at this point: in fact, making a punt right now would be downright irresponsible: we didn’t have enough information to make the decision properly.

So instead of using my ‘gut feel’ to pick one of the competing options like a real hero would, I did a much more pragmatic, but less intuitive thing: I decided we would do both, until it became clear which one was the right one to pick.

We were lucky that our constraints at this point were time, rather than cost, so we could afford the luxury of having two streams of work going on in parallel, knowing that one would eventually be thrown away. Obviously the hidden deliverable even from that throwaway stream would still be a developer or two who understood the problem domain really well, and with a new technology in their toolbox to use in the future.

A week later it was much clearer which of the options we should pick, and the other workstream was stopped. And everyone lived happily ever after :)

Update: If you want to know more about real options, read Chris’ article on InfoQ here.

Agile / Lean Software Development

Comments (1)

Permalink

Slides from XP Day Talk

I’m just back from this year’s XP Day, London. Thanks to everyone who came and packed out the room to hear Rob and I talking about our experiences evolving our team from Scrum to Kanban. The slides are here.

There’s also a great transcript of the talk here on Tom Hume’s blog. Thanks Tom!

Agile / Lean Software Development

Comments (0)

Permalink

DRY up your Cucumber Steps

Update (13th Jume 2012): This is an old, old post that still gets a lot of hits. I don’t recommend this practice anymore. Instead, I recommend composing Ruby methods that carry out these actions. For more details, please see The Cucumber Book.

A while back, I asked the Cucumber team for the ability to call in the steps of one scenario from another.

The canonical example of this is the ‘log in’ scenario:

Scenario: User logs in
  Given there is a User whose username is "matt"
  And I follow "log in"
  And I enter "matt" in "username"
  And I enter the User's password in "password"
  And I press "Log In"
  Then I should be logged in
  And I should see the text "Hello matt"

Phew. Now obviously I don’t want all this noise in the scenario every time I specify behaviour that requires a logged in user. I want to write something like this:

Scenario: User views their dashboard
  Given I am logged in
  And I follow the "dashboard" link
  Then I should see "This is your dashboard"

Thanks to the fabulous creativity of the Cucumber community, this is now possible. It’s also highly recommended, as it’s a great way to help you keep your step files tidy and DRY of excess duplication.

Given /I am logged in/ do
  steps %{
    Given there is a User
    When I follow "log in"
    And I enter "#{User.first.username}" in "username"
    And I enter "#{User.first.password}" in "password"
    And I press "Log In"
  }
end

I’m doing this more and more now – writing simple ‘building block’ steps and assembling them to make steps that read nicely and make sense to the stakeholders.

Agile / Lean Software Development

Comments (13)

Permalink

“Total Programming” and the XP Team

Pair programming brings a great many benefits to a team that’s truly mastered it.

Those of us who are lucky enough to have experienced working on a really effective XP team know about that almost magical thing that starts to happen when the barriers between different members of the team break down, egos and code ownership are cast aside, and the team starts to evolve the codebase as one, mighty, coding machine. It’s truly a joy to be a part of, or even just to watch.

dutch-team-78

Continue Reading »

Agile / Lean Software Development

Comments (3)

Permalink

Is the Value Fetish Killing Agile Teams?

Last weekend I was at CITCON Europe, a great opportunity to meet some of the leading minds in the agile software movement. One intriguing new term I heard a few times was “value fetish”. Let me try to explain what I think it means, and discuss the implications for agile teams.

Continue Reading »

Agile / Lean Software Development

Comments (7)

Permalink