Bring your Product Owner to BDD Kickstart for free!

BDD is powerful stuff, and it’s much more powerful when your product owner understands the benefits.

We love having product owners at BDD Kickstart. The first day is all about the collaborative aspects of BDD where we learn how to break down and describe requirements using examples. We find that product owners really enjoy it.

That’s why we’re announcing a special promotion for our next public course in London. Use the discount code “BYPO” when booking your three-day ticket, and we’ll throw in a free ticket worth £450 that you can use to bring your product owner, project manager or scrum-master along to day one.

These tickets are limited, so book now before they sell out.


Comments (0)


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)


The Real Point of Planning Poker

It’s funny, you’d think, from reading about planning poker that the purpose of this exercise is to come up with accurate estimates. I think that’s missing the point.

The estimates are a useful by-product, if your organisation values such things, but actually the most important benefit you get from planning poker is the conversation. As part of the exercise, you explore the story as a team, and uncover any misunderstandings about the scope and depth of the work to be done to satisfy the story. The result of this exploration is a shared understanding of what the story means.

There are other ways to have this same conversation. My favoured practice is to hold a specification workshop where the team explores the scenarios that a user could encounter when using this new functionality. These scenarios are a much more useful product, to me, than an estimate. They give me a starting point for writing my automated acceptance tests, and they also give us all a concrete reference point as to the scope of the story. If my organisation needs estimates to be happy, we can count the number of scenarios to give a realistic feel for the relative size of the story.

Agile / Lean Software Development

Comments (5)


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)


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)


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)


Where Scrum Gets Dangerous: Potentially Shippable? Make Sure You Mean It

Scrum tells you to build ‘potentially shippable’ changes to your product (let’s call them ‘User Stores’) in fixed-length iterations. By estimating the relative complexity of delivering each of these changes using arbitrary units (let’s call them ‘Story Points’) you can measure how much estimated complexity was turned into ‘potentially shippable’ software over a fixed duration.

So far, so good. Where could it possibly go wrong?

Continue Reading »

Agile / Lean Software Development

Comments (1)


Retrospective: The Clue is in the Name

I facilitated our regular end-of-iteration retrospective last week, and although the feedback from the team was positive, I was left with a feeling that something wasn’t right.

With our second major live release looming large on the horizon, I focussed the session on the theme of ‘Success’. My aim was to give the team a blueprint for a successful iteration to keep in mind when things were tough, and to help ensure that we were all pulling in the same direction by agreeing as a team what constitutes success for us.

Continue Reading »

Agile / Lean Software Development

Comments (0)


Kanban for Software Explained

Karl Scotland has posted a great description of how his team solved some issues they were having within their Scrum team by moving over to using a lean-thinking or Kanban system, based on a short buffer or Queue of Minimum Marketable Features (MMFs). It’s probably the clearest explanation I’ve seen yet of why and how to employ this emerging technique, and Karl certainly makes a compelling case for considering this as a progression for teams who are experienced with Scrum and need to be able to adapt rapidly during the development of a story or feature.

One of my key questions about Kanban is how it’s possible to predict long-term delivery dates for specific features, and although Karl goes some way to answering those questions, it looks as though you need, as well as a mature agile team, a fairly mature and trusting organisation to make this work.

I guess you also need to be working on a product that’s already in production and being updated regularly.

Agile / Lean Software Development

Comments (1)


Safety in Numbers

How important is it to measure how long something took?

Well, so the received wisdom goes, by comparing how long it took you to complete your a task against the estimate you made before starting it, you get an idea of how good your estimate was. So far, so good.

But what if your estimate turned out to be wrong? What are you going to do about that?

One of the culture shocks I think scrum introduces it the idea that we almost always just look forward. I don’t care how long you’ve spent on a task, I just want to know how long you think it will take you to finish it, based on what you know right now.

Tomorrow, if you turned out to be wrong, that’s OK. All we need to know is how much longer it’s going to take to get it done.

Except it’s not OK.

Because if your task, which you originally estimated would take 2 hours has taken you two days, and it’s still not done, then something is impeding you.

Fortunately in a team practicing scrum, we have a daily 15-minute meeting where impediments like this are made visible to the entire team, and someone takes away the action to resolve the impediment.

Rather than having to retrospectively scan reports of esimates vs actuals in a spreadsheet, the problem can be highlighted as it’s happening, and hopefully resolved.

Agile teams also have a second line of defence against more stubborn impediments: The retrospective.

With these two facilities in place, it becomes unnecesary to track the details of estimates vs actuals. The administrative overhead on developers is reduced, and they can get back to writing solid code.

Some people find this difficult to accept – there’s a familiarity to the recording of the numbers. We’ve allways done it. It makes me feel safe. Somebody will ask us for them.

If someobody asks you how good your estimating is – show them your burn-down chart.

scrum burn-down chart

It’s bloody obvious from the shape of the chart if your estimating is any good. And if they want figures, measure the difference in area beneath your real curve (blue line) and your ‘ideal’ diagonal curve (red line). Every hour above the diagnoal line is an under-estimated hour. Show this to your team. Get them to look at it and reflect on how realistic they’re being when they estimate tasks.

If somebody asks you why your estimates were too low – listen to people. Look at your impediments log, and the write-up of your retrospectives. You need a culture where impediments get surfaced quickly from the team, where it’s OK to say things aren’t going well, and where problems raised get solved and cleared out of the way.


Comments (0)