I was in a planning meeting with my project manager and several of the devs. “What happened?” the project manager said. “Why did this one story take so long?”

“There was some functionality we needed and didn’t know about,” I replied. “We managed to get it in before the deadline, though.” The business had been quite happy with that, and they were notoriously hard to please.

“If they’re going to change their mind like this,” the PM replied, “we’re going to have to introduce some kind of change control.”

“Please don’t,” I begged. “If you do that, the business will spend more time investing in getting things right to start with.”

“Exactly.”

“But they’ll still get it wrong. No amount of planning would have spotted that missing piece before we showed it to them! When they get it wrong now, though, they’ll encounter the change control and they’ll want to spend even more time getting it right first time. And they’ll still get it wrong, but now we’ll have made it more expensive for them to be wrong. We’ll have a formal process which means it takes even longer for us to find out what’s missing, by which time us devs will have to work to remember the code and the change will take longer. It will slow us down. So they’ll see that, and spend even more time trying to get it right, and before you know it they’ll be planning whole projects up front.”

We have a word for that. It’s called Waterfall.

That desire to control change creates a reinforcing feedback loop, in which the cost of change makes us want to invest up-front, which makes the change expensive later on, which makes us want to invest up-front, and so on.

In this case, it would have been pointless, except as a way of shifting blame and risk back to the analysts (and this was an internal project). The cost of change was quite low; we had clean code with a good suite of tests. It was only the cost of discovery, and the implementation that followed, that was really expensive.

Don’t confuse the cost of discovery with the cost of change.

Discovering something later on only costs more than planning for it if you’ve made a commitment to something else.

In fact, if you don’t plan for it, it can cost less. The newly-discovered knowledge will be fresh in everyone’s minds. Because the ideas haven’t been known for long, nobody’s mentally committed to them either, which makes them easier to question and clarify.

This is even more important when there’s a chance that the analysis might be wrong (and there’s always that chance; we learnt this from Waterfall). If you plan for something that you later have to revert, you’ve introduced a cost of change right there. Perhaps the cost is just changing some documents. Perhaps the developers have designed for the plan, and built on top of the thing which needs changing.

But we need to do some planning, right? Otherwise the chances of us being wrong and building on top of the wrong thing are even bigger, and there’s even more chance that we’ll have made commitments the wrong way. So how should we plan?

I’ve got few more guidelines I’d like to share. Here’s the first:

Keep the cost of change low.

This is more important even than planning, because there’s always a chance that we’ll get something wrong.

This is what we’re aiming for: the ideal, low cost of change on an Agile project.

The first thing to notice about this is that the cost of change is not zero. That’s going to become important in the next section, and it’s what drives the team’s desire for change control and starts kicking off that Waterfall loop.

The second thing to notice is that this bears little resemblance to actual, real Agile projects.

On a real Agile project, it’s likely that we have fluctuating levels of stress, concentration, experience and desire for feedback. All of these – or lack of them – will lead us to occasionally write code that is, shall we say, less than ideal.

It takes discipline to write code that’s easy to change. On a real Agile project, we tend not to do it all the time. Oh, we might say we do, but we don’t. Not always. And if we do, our team-mates don’t. The real skill isn’t in writing clean code – it’s in cleaning up the horrible mess we made the week before. And it takes even more discipline to do it afterwards, especially if you’re under pressure to just hack the next working thing in too.

If we don’t clean up and keep that cost of change low, we’re making a commitment to the wrong thing. The longer that commitment stays in place, the higher the cost of change will become. We’ll find ourselves on that Waterfall cost of change curve, and the longer we’re on it, the more expensive it is.

I’ve found the skill to clean up afterwards is even more important in high-learning projects, where a lot of the technology or domain is new, at least to the team. There’s no point in writing tests up front for a class when you don’t even know what’s possible, or what other frameworks and libraries will do for you, or what the business really want. In those environments, rather than TDD or BDD, teams tend to Spike and Stabilize. The spikes aren’t really prototypes – they’re small pieces of features, often with hard-coded data behind them, designed to get some feedback about techology or requirements. Dan North, who gave me the term, might write more about this later if we ask nicely, but for this post, we can simply bear in mind that the skill to stabilize later – ensuring that the cost of change is lowered – is often more important than the skill to keep the cost of change low up-front.

Because we get it wrong too.

Assume you got it wrong.

Human beings are hard-wired to try and get things right, and to pretend that they did even when they didn’t. I love this list of cognitive biases on Wikipedia. These are just some of the ways in which we get it wrong and don’t even notice.

If we assume that we got it wrong, then we start to look for feedback, and quickly. This is difficult for most human beings. We much prefer to get validation than feedback; to be told that we did it right, rather than finding out what we did wrong. Our brain gives us these little kicks of nice chemicals when we learn that we did something right, and it feels much better than the other kind.

If we can remember, though, that we probably got it wrong, our focus will change. Instead of trying to invest in good requirements and nice code, we’ll try to find out what we got wrong in the things we’ve already done. Of course, we need to invest in stabilizing what we’ve done, or the cost of change goes up, and that will make it more expensive later if we find out we were wrong, which is the assumption we were trying to make in the first place… ah, the paradox!

There’s a fine balance to be struck between getting quick feedback – often itself an expensive proposition, given the business of most domain experts – and getting it right up front. So where does the balance lie?

Don’t sweat the petty stuff.

If it’s easy to change, don’t worry about it. Analysts, learn what’s easy to change. Typos, colours, fonts, labels, sizes, placement on the screen, tab order, an extra field… these are all usually easy to change, and do not normally need to be specified up-front. Even if you have a particular style you want to see on a page or form, this can usually be abstracted out and changed later – just let the devs know that you want that consistency at some point.

It’s more important for us to know the rough shape of what you want to see, and the flow and process of that information. We don’t want to know every field on an order item. We just want to know that it needs to be sent to the warehouse and stored locally because you’re going to check the money in the till and count the stock. The fine detail of that is pretty easy to change, so we can get feedback on it later. Getting the fine detail right would definitely be an investment, and we might have got the big picture wrong.

Deliberately discover things you’ve never done before.

Dan North wrote an excellent post on Deliberate Discovery, and I’ve been using it to manage risk on my projects for a while now. It’s one of the most important tools in my toolbox, along with Real Options to which it’s strongly related, so I want to cover how I use it here.

I really like using Cynefin to help me work out what to target for discovery. We treat a lot of software as if it’s complex, and we talk about self-organising teams and high learning environments, but in reality there are huge chunks in most applications which follow well-established rules, have been done a thousand times before and probably have libraries or third-party apps to do the job for you. They’re not complex. They’re complicated. They require the application of a bit of expertise, and are likely to be done right and never changed again. User registration and logging in are great examples of this. You don’t need a big, thick document to describe them. The fine details might change, of course, but we already know not to sweat the petty stuff.

It is OK to plan some aspects of a system as if it’s Waterfall – for instance, deciding up-front whether you want to use your own login or let Google authenticate. Even better than requirements documents, and quicker, is to say, “It’s user registration. Make it work like Twitter’s, but we also need the user’s loyalty card number. We should offer to send them a card if they don’t have one.” Dan North calls this pattern “Ginger Cake” – it’s like a chocolate cake, but with ginger. He even cuts and pastes code. And it’s OK! Honestly, it is! This code is also absolutely prime for TDDing – if you actually have to write it yourself, that is, since it’s been done before so someone’s probably written something to do it for you already. You can also give this code to junior devs, for whom it’s new, and guide them in TDDing, making it perfect pair-programming territory. Everything you have ever been told about Agile software development applies particularly in this place.

Fortunately, most applications have a minimum set of requirements that they share with other, similar applications. David Anderson calls these commodities – table stakes that you have to have just to play the game – so *most* code in an application will end up going this way.

The places in which we’re most likely to get it wrong, and need fast feedback, are places where we’re doing something new. They might be technological, particular to a domain, or just things that the team themselves have never looked at. My favourite book for understanding risk is “Waltzing with Bears”, which starts the first chapter with, “If a project has no risks, don’t do it.” It’s these new, risky aspects of the project that differentiate it from others and make it valuable in the first place!

For new and risky aspects of a project, the best thing to do is assume you got it wrong, and work out how quickly you can get feedback on how wrong you are.

Any new or unknown aspect of a project will need to be changed.

I was chatting to one of our analysts. “I can see this feature is in analysis at the moment,” I said. “Does that mean it’s the next thing we want the developers to do?”

“Oh, no,” the analyst said. “It’s only there because the analysis is quite complex. It’s all new stuff, so we’re having to be careful with it and it’s taking a bit of time. Once we get the analysis done, the development should be very easy, so we’ll do it later.”

“Oh, the development will be easy, I’m sure… but wouldn’t you like to find out what you did wrong now, rather than later, while it’s still fresh in your mind?”

The analyst smiled. The company was very much more used to Waterfall, and the idea that it was OK to get it wrong was something very new.

It’s OK to get it wrong, as long as you get feedback quickly, while the cost of change is still low. By working out which parts of a project are unknown or new, and targeting those first, we make small investments while the cost of change is still low.

Keep your options open – do the risky stuff first and keep tech debt low.

Anyone who’s run into me at conferences will know how much I love Real Options, and it’s really at the heart of the cost of change.

The only reason change costs more is because of the commitment that we already made. Chris Matts describes technical debt as an “unhedged call option”. He says, “You give someone the right to buy Chocolate Santas from you at 30 cents each. That’s fine, as long as the price of chocolate stays low. As soon as it goes up, you still have to pay to make the Santas, and now you’re in trouble and your company is going bust, because you didn’t give yourself the option to get the chocolate somewhere else.”

Similarly, technical debt is absolutely fine until we’re called on to act, and act fast. At that point, we’re in trouble. This is the biggest reason for keeping the cost of change low – because it gives us the option for change, later. It’s a frequently-cited reason for replacing legacy projects – and, bizarrely, often forgotten when the pressure mounts and the business want their replacement app.

This isn’t helped by common practices of estimation and the associated promises, which often lead to that pressure building up in the first place. Rather than making these promises up-front, why not try the risky bits first? I often hard-code data so that I can get feedback on a new UI early, or I spike something out using a new library or framework, or connect to that third-party application just to see what the API is really like to use, or have a chat with the team writing that other system we’re going to need in June, so I can find out how communicative and receptive to feedback they are. Doing this means that we give ourselves the most time to recover from any unexpected discoveries, and we can worry about the more predictable aspects of a system later.

Once we’ve got spikes out of the way, adding tests to act as documentation and examples for any legacy code we’ve created, cleaning it up so it’s self-commenting, ensuring that architectural and modular components are properly decoupled, etc., all help us to stabilize the code. At the same time, the effort involved in creating stable code is itself an investment. If there’s a good chance that the code might be wrong, it could be worth getting feedback on that – knocking up integration tests, showing it to the business, testing it, getting it live – before it’s made stable.

That way, the commitment made is small, and the cost of change is low.

Just remember to clean up and keep it that way!

Update: Dan is currently writing about Spike and Stabilize and Ginger Cake as part of his “Patterns of Effective Delivery”. If you’re interested in finding out more, you might like to watch his Roots talk on the topics.

The second time I did it wrong, it was because I forgot about the first time.

The third time I did it wrong, it was because I was really tired.

The fourth time I did it wrong, it was because someone else told me to.

The fifth time I did it wrong, it was because nobody lets anyone do things right around here.

I had come from Thoughtworks, a company whose tools and processes are mostly driven by Extreme Programming, aka XP. In that respect, most of what I learnt and coached was very similar to Scrum, albeit with different words. We called them iterations instead of sprints, and had stand-ups instead of daily scrums. We had planning meetings, but we didn’t make commitments – just estimates. We had collaborative code ownership and a focus on delivery instead of a cross-functional team, which meant that we ended up with flexible and blurred roles anyway. We had the same problems – getting people co-located, helping business stakeholders become more comfortable with the risk and uncertainty of software delivery, and changing the culture and the infrastructure of the organisations in which we worked. We also had a number of technical practices like unit testing and continuous delivery that aren’t really prescribed by either Scrum or Kanban, but which both put forward as a Really Good Idea.

In the last few years, I’ve been privileged to be part of the Kanban community. I don’t consider myself part of the Scrum community as such, but I’m part of the larger Agile movement and strongly aligned through my background in XP.

In this post, I’d like to cover some of the differences I’ve seen between Scrum and Kanban, and add in some insights from the Cognitive Edge training I’ve done using Cynefin and complexity thinking. This isn’t going to be a full description or comparison, but it should hopefully provide some food for thought, and allow people to see some of the different tools available from both approaches.

Disclaimer: I haven’t explained every term I’ve used, or every practice I’m referencing. I’m assuming familiarity. If you don’t have it, you can to run a search on anything I haven’t linked. I’m also using the terms “Scrum” and “Kanban” as aliases for the community and / or leadership, and I haven’t made much distinction between Scrum.org and the Scrum Alliance. This is deliberate, and I welcome feedback.

Scrum and Kanban have more similarities than differences.

Both methodologies put people and their interactions at the heart. Both have a clear focus on value, fast delivery and the continuing growth of the team and its ability to achieve those valuable deliveries. Both contain mechanisms for feedback and improvement, allowing processes to change according to context. Scrum used to have a very prescriptive format – not dissimilar to XP – but this has been flexed in recent editions of the Scrum Guide, as alternatives to some of the practices have emerged. It’s not even beyond the realms of possibility that some of the alternatives have emerged from the Kanban movement!

Also recently, Scrum has started to evolve from being a set of processes to being a very loose framework in which processes can themselves evolve. Used this way, it joins Kanban as a meta-process, from which the real process emerges and continues to emerge.

IMO, both are infinitely better than that broken model called Waterfall, and both are better than having no process at all.

Scrum isn’t about the Scrum Meetings, and Kanban isn’t about the Kanban Signal.

Both methodologies are named after just one small aspect of their whole. In Scrum, the scrum meetings allow the team to share learning and information about how they’re doing and to make decisions about what to work on next. In Kanban, the kanban signal – showing that someone is free to help move a piece of work closer to delivery – provides a similar focus point. Scrum teams frequently use a card wall that’s similar to that of a Kanban team. Kanban teams frequently have daily meetings like Scrum. To an outside observer, the differences could seem so small as to be irrelevant.

Kanban measures lead and cycle time, Scrum measures velocity.

Both Kanban and Scrum have their origins in “Lean” thinking. We like to think of “Lean” as the set of principles behind the Toyota Production System – the process by which Toyota builds and churns out its cars – but both methodologies have an implicit recognition that software development holds more similarities with product development than a production line. In Toyota, kanban cards are used to help eliminate large amounts of spare parts and other inventory building up; providing a buffer which lets work flow through the system. Both Scrum and Kanban value this flow. Kanban suggests limits on the amount of work in progress, allowing constraints to be addressed. Scrum encourages collaboration, causing less work in progress. Scrum uses the proxy of velocity and estimation, which can help to prevent metrics around productivity becoming targets. Kanban uses lead and cycle time, tying its measurements to valuable targets that are hard to game.

Scrum starts with the right context; Kanban improves the existing context.

I once asked a Scrum practitioner, “What do you do if you don’t have a cross-functional team and you’re not co-located?” He told me that that’s the hardest bit of Scrum – starting from the right context. I realised that these difficulties, once overcome, also provide significant value. Just starting from the right context might be a good idea!

On the other hand, Kanban is neutral regarding context. Of course we think that being co-located is a good idea. Of course we’d love to have multi-skilled, flexible, collaborative professionals. If only this was as common in the industry as we’d like. Kanban’s focus on metrics and its measurements of lead and cycle time might make the impact of not having these apparent, so it’s a good place to start. (I used to think it was only suitable for highly skilled, disciplined, advanced teams, but experience and experimentation has taught me otherwise).

Kanban visualises what’s happening; Scrum visualises an ideal.

This is one of the biggest differences for me. The extent to which Kanban visualises reality is extreme enough that the board might not even have linear flow. Whatever the process policies are – whether helpful or otherwise – Kanban focuses on making them explicit, so that they can be addressed and improved. If the team happen to work with five different phases, this is reflected. If the team write technical stories, they go on the board.

In contrast, Scrum teams tend to set up a visualisation of an ideal process, helping teams to adopt that process. Done prescriptively, Scrum provides a “big bang” starting point. Because it consists of step-by-step practices, it’s easier for beginners to adopt. That could be Scrum’s blessing – but it’s also its curse.

Certification and early adoption.

Scrum has certification. Kanban doesn’t.

Yet.

In the early days of Scrum, there were few enough trainers and experienced Agilists that no matter who taught Scrum, it was done pragmatically. Early adopters tend to experiment, and those experiments led to a better understanding; to a focus on people and interaction, rather than process. Unfortunately the “Scrum Master” certificates are easy to get, compared to any other discipline that asserts a quality of mastery or independence. The training provides simple practices that are relatively easy for teams to adopt. Scrum is taught by a wider group of people, and the quality control over that teaching has become harder to maintain.

As a result, Scrum has been widely adopted and is considered pretty mainstream – the default Agile methodology – but the certificates associated with it provide a level of confidence that the training generally doesn’t support. I’ve met a couple of excellent Scrum trainers, but I’ve also seen “masters”, armed with their certificates, instituting mini-waterfall and silo’d teams as they replace those parts of Scrum that aren’t prescriptive, or that they don’t understand, or that they can’t achieve within a context that they can’t change.

Any examination or certification body suffers from a paradox: while the people who rely on those qualifications need them to be rigorous, the people teaching and taking those qualifications would much rather they were easy. The Scrum Alliance and Scrum.org between them have both helped to set up and reinforce the desirability of their certifications, and I can only imagine the difficulty that their leaders face in balancing the financial incentives involved against the good of the IT community and industry.

In contrast, Kanban is still in an early adopter phase. We’re still working out, as a community, what’s possible. Most Kanban practitioners and coaches are bright, experienced, willing to experiment, desiring of feedback and able to share and learn from each other in a relatively small community. Scrum no longer has that luxury. We don’t know what will happen if and when the Kanban community treads the same path, but we do have the advantage of being able to learn from what’s happened with Scrum.

You can also bet that the leaders are being watched carefully by the rest of the community to see how they meet this challenge. So far I think they’re doing an excellent job. So far there are no certificates available. So far.

Some thoughts spurred by Cynefin.

The Cynefin model of complexity thinking teaches us that in a complex environment – one in which cause and effect can only be understood in retrospect, and which includes most systems with people in, as far as I can tell – we should increase the opportunities and incentives for interaction, so that the practices best suited to the context can emerge.

Waterfall treated software development as complicated, using Cynefin’s domain definition; as though each project was a thing that could be taken apart into many pieces, analyzed, then put back together as a whole. Unfortunately the ability of human beings to make mistakes, combined with our inability to either effectively communicate our intent or see into the future, has meant that this was always doomed to fail. (Most successful Waterfall teams, who complain to me that I label it unfairly, have not practiced it in a pure form, and have included elements of iteration, feedback and common sense. When these are lacking, any methodology is doomed to failure, but Waterfall above all others doesn’t mandate or even leave much room for them.)

When we look at applying Scrum prescriptively to a Waterfall team, we’re looking at pushing forward increasing levels of interaction in a context in which interaction is easy – where teams are co-located, have all relevant skills, are willing to collaborate and can share learning. Scrum’s acts of estimation and breaking stories into tasks force team members to talk to each other. The act of commitment which Scrum recommends in planning meetings causes a team to discuss their concerns frankly. The cycle of feedback and retrospection allows the team to discuss whether they’re delivering value and how to do it more effectively.

But Waterfall is no longer the context from which we always come. Many Agile adoptions aren’t taken up by teams doing Waterfall; they’re taken by teams who have abandoned their process altogether, and are talking and sharing their learning in order to work out what to do next, while having no metrics against which they can improve or track their progress and risk.

The context in which Scrum starts is not often possible. We’re not always co-located – many start-ups and companies now allow developers to work from home, and the industry still seems to suffer from a delusion that offshore work is cheap to obtain. We may not have multi-skilled people – it takes some time to learn skills. In both the environments which are already more collaborative than Scrum, and the ones which are a long way from being able to do it successfully, Kanban can be useful.

I fear that this may include the majority of environments and the IT industry, and that’s why I choose to hold myself closer to the Kanban community than the Scrum one. IMO, Kanban works in a larger set of contexts than Scrum does, even though for a subset Scrum might achieve results faster.

They’re still more similar than they are different… and I still like XP too.

Of course, we don’t know what we don’t know, so feedback is still important. We’ve got a good chance of discovering what someone else knows, and has perhaps forgotten to tell us, if we start questioning the ways in which our understanding might be wrong.

These are two patterns which I commonly use. You’ll notice that they follow from the typical BDD scenario template:

Given a context
When an event happens
Then an outcome should occur.

Context Questioning

We can ask, “Is there any other context which, when this event happens, will produce a different outcome?”

It might be an additional context, or a context which occurs instead of the one(s) we’re considering. We can ask this question, or we can think of contexts ourselves and ask about those. For instance:

Given a client manager, Fred, has two clients, George and Henry
When Fred uses the application
Then Fred should only be able to see George and Henry’s accounts.

I ask, “Given I have no client managers, what happens then?” (I’m thinking of handling empty lists, because I’m a developer.)

The head of Client Management says, “What? Who cares? Why are you even using the application? Get on the phone and get some clients already!” (He’s thinking of his failing business.)

You can sometimes learn a lot about a business domain this way, even if the behaviour of the application isn’t going to change immediately!

Outcome Questioning

This is similar to Context Questioning, but instead, we ask,

“Given this context, when this event happens, is there another outcome that’s important? Something we missed, perhaps?”

Another way I like to ask this is, “If pixies were doing this instead of software, would it be enough? Or do they need to do something else, too?”

For instance:

Given the legacy system has a problem
When a trader stores a trade
Then the trader should be told about the problem.

I ask, “Is that all that should happen? I’d be pretty upset if I were a trader and this happened a lot.”

My business analyst (by which I mean, someone who can analyse the business) says, “Well, we’ll still have the details in the system, so you’ll be able to do it again later. Oh, yes! We need to store the trade in our system still, too, but make sure it doesn’t have a legacy system ID so that we can tell it didn’t go through.”

And that’s it.

There are lots of other ways to have conversations around behaviour. They’ll usually be trying to find missing contexts and outcomes – places where a new piece of behaviour happens. These also tend to be the things which business users, familiar with their domains to the point where they don’t think about it, forget to talk about. Developers are pretty good at spotting this, because they’re usually thinking through how they’re going to implement the problem, and wondering what goes on the other side of the “if… else…” statement (even if we’re not meant to be implementing yet, we already are in our heads). Testers are also very good, because they’re used to the kind of things people get wrong when they produce software.

This is why getting all three people – a tester, a developer and a business analyst – is so useful when we’re discussing scenarios. It’s also why it’s so important to have the conversations – because if you’re not having conversations, you’re not doing BDD.

A feature is something tangible that works and which we could potentially deliver, if it was enough to provide business benefit. Usually a bit of a screen or page, together with all the logic and validation associated with it, is a feature. A feature is the highest-level thing which a developer could work on without doing significant bits of analysis. It’s a part of an idea made at least concrete enough to imagine.

A story is a part of a feature on which we can get feedback from relevant stakeholders. For instance, we might code the UI, then the validation and messages, then an aspect or two of the behaviour behind the UI. Each of these would be a possible story. The only real reason for splitting features into stories is to get faster feedback and a better idea of progress.

A task is a part of a story which doesn’t allow us to get feedback from relevant stakeholders. If you can get feedback, it’s probably a story rather than a task, because it affects the UI in some way, or at least gives something that can be visibly verified and critiqued and which stakeholders care about. There are lots of UIs and lots of stakeholders and users, so “put logging in to help maintenance debug the situation where the elephant appears on the screen” might be a perfectly good story. Anything that’s just a part of a story is a task.

A task can’t really be tested either, even by a developer. You have no idea if a database has the right tables or data until you connect it to something. You have no idea if an interface to another system will work until it’s actually talking to that system. You might unit-test it, or run some queries, but it’s a level below the feedback and user testing available for features and stories. (There are higher levels of testing too, in which we can look for user capabilities and business outcomes, stakeholder goals, profit / loss, etc. – so you can’t really tell if *anything* works until you put it into production – but that’s a blog post for another day).

Why do some teams split stories into tasks?

A lot of Scrum teams particularly do this, because it’s traditionally taught as part of the Certified Scrum Master course. Hopefully good CSTs, and their CSMs, are teaching the benefits along with the practices.

It can lead to more accurate estimates. Splitting stories into tasks can help developers to think about the amount of work involved in a story, and find any pieces they missed.

It can help with collaboration. By splitting a story into tasks, developers can each take that task – usually a different horizontal slice – and work with minimal merge conflicts and just a bit of adjustment to get their piece working with other people’s. Splitting a story into tasks is useful for swarming, and a lot of swarming teams do this instinctively, even if they haven’t written the tasks down.

It can help senior developers mentor junior developers and verify that they’re taking a good approach towards a story. Some mistakes are worth avoiding.

They can be used as a measure of progress to someone tracking the team, like a PM or Scrum Master.

Why don’t other teams do this?

Some teams prefer to focus on delivering something on which they can get feedback, and find the tasks distracting.

There are also other ways of getting accurate estimates. Talking through scenarios can help with this. A lot of teams don’t use estimates anyway, preferring to stick to SLAs or their own instinctive understanding of how much work they can get done and whether they’re going to release on time. Anther purpose of estimation is usually so that the business stakeholders can have trust and confidence in the team, and there are different ways of getting the trust of stakeholders, too.

What bad things might happen if we split our stories into tasks?

Splitting stories into tasks might indeed distract from delivering something on which the team can get feedback. When a developer sees a list of tasks in front of him, he tends to work through those tasks methodically. He might not notice that, for instance, the team isn’t going to deliver *any* stories this week.

Using tasks to estimate team progress can also be misleading. If all the developers end up working on their own stories, the PM might see lots of tasks being done. If none of those stories are ready for the showcase, though, the team won’t be able to get feedback from their stakeholders – and might end up building the wrong things altogether! Also, the Pareto Principle suggests that 20% of the causes are responsible for 80% of the effects – or that the last 20% of the story might take 80% of the time. Often developers will start with the easy bits and leave the hard things until last.

People seeing the tasks can use them to micro-manage the team, asking who’s working on which task, or even assigning particular tasks ahead of time! But anyone with a manager or Scrum Master who does this has bigger problems than the task-splitting, I think.

Why do you absolutely hate people splitting tasks then putting hourly estimates on them?

First and foremost, this harks back to the old myth that time = work done. Even if developers are only held to be productive 50 or 60% of their “ideal” working day, the focus is still on the number of hours spent, rather than useful software being produced. It’s perfectly possible to spend hours on something that doesn’t work. A team which signs off all its tasks is subtly encouraged to say that they’re “done” without checking that the software they’re producing is useful.

What about the developer who plays with something else while turning over a problem in the back of his mind, then delivers an ingenious solution in 2 hours? Or the developer who wants to try out another way of solving the problem which might involve a steep learning curve, but which would benefit the project in the long run? By pinning these developers down to their hourly estimates, insisting on a certain timescale of productivity, we encourage them to tread the path they had in mind when they made the estimate, even if a different idea occurs to them at the time. Since human beings get a kick out of being right – suffering horribly from confirmation bias and the preference for validation – just the act of estimating the hours will pin them down subconsciously. They may not even think about the problem or have the new idea! Hourly estimates can stifle innovation, and the less wriggle room there is, the more innovation will be stifled.

Finally, it encourages micro-management. A project manager who sees a developer working on some tasks that should have taken 8 hours, but have taken all week, might wonder why that developer is taking so long. However, uncomfortable enquiries will only cause the developer to pad their estimates next time – and work expands to fill the time available, so the team will eventually slow down.

Should we do it or not?

If you think splitting stories into tasks might be helpful, try it. If it doesn’t help, stop. However, please resist the urge to put hourly estimates on them – or to ask that your team does so.

The story is used in Scrum and other methodologies to suggest that only “pigs” – the people whose bacon is on the line – should have the right to speak in stand-ups. This deliberately excludes management.

Yesterday, Dean Leffingwell spoke on the subject at Agile 2011. He pointed out that the practice calls out the chickens as the “bad guys”. “Wrong!” he says. “These are the people who run the company.” Quite aside from some cultural implications of calling people “pigs” – it doesn’t go down well in countries which consider pigs to be unclean, for instance – excluding management from stand-ups can be disrespectful at best, and damaging at worst.

I finally decided to be done with the Chicken and Pigs analogy and practice after a roleplay organised by Derek Wade, in which the manager had something very important to share – something that would have reduced the stress the team was experiencing, as well as the workload, the weekend’s overtime, and the risk to delivery that was approaching our fictitious team.

The manager started to speak. “I…”

“You’re a chicken,” the Scrum Master announced. “Next!”

Let’s not.

I’m told that it’s too late to get the Pask sorted out for this year – we’re Agile, but not that Agile! Please keep nominees in mind, though. Many members of the committee are talking and are keen to keep the award in some form, so chances are it will be back next year. Watch this space.

It’s that time of year again that the Pask committee meets at the Agile 20XX conference to vote on the nominations which have been made.

The committee is mostly made up of people who’ve already won the award in previous years. We won because of our ideas, because we’re good at spreading them, because we made a difference, because we were under the radar… but not because of our organizational ability! So please forgive this very late post.

We are still collecting nominations (email pask-nominations AT agilealliance DOT org) and will be voting at some point during the week.

A number of people have suggested that the Pask Award doesn’t matter. I thought I’d share some of the things which have happened to me since winning the award last year, so that you can understand exactly what it is that’s being given away.

The Pask Award

It’s always wonderful to be recognised for your work. The award also comes with quite a hefty bit of money – enough to pay for a couple of international conferences, and then some. There’s no trophy, but you get to tell people that you won the award. Your parents will be dead chuffed. You can stand on stage and recognise all the people and communities who’ve helped you. And that’s just the award itself.

The Side Effects

The number of people following me on Twitter doubled overnight, from 500 to 1000. Then it kept climbing. I am now followed by over 1,600 people. That’s enabled me to spread a lot of other people’s messages, too.

Because people have started to know my name, I’ve started getting more offers of work. I’ve had requests for help from the USA, from all over Europe, from India. (Some of them have even offered to pay me!) I’ve been able to raise my rates a bit, and I’m getting all kinds of interesting opportunities which I didn’t have before.

Then, there’s the conference invites. Lots, and lots, and lots of invites to speak around the world. I’m sorry to those people that I’ve had to turn down – I am simply getting so many invites this year that I can’t do all of them, especially if they’re at the same time as others.

Because of the conference invites, I’m getting to speak more, and spread the ideas from my communities, which leads to more Twitter followers and more exposure and more conference invites… I suspect the escalation from this has started to reach a natural limit, but again, I apologise if I haven’t quite been able to keep up. It really has been a little bit insane.

The Further Side-Effects

Because of the invites, I’ve become a better speaker. This means I can now spread the ideas more effectively. They weren’t all my ideas in the first place – many of them came from communities in London and around the world – so now people recognise that I can share ideas effectively. This means more people are now giving me lots of ideas to share! So I’m learning an enormous amount, too. I feel insanely privileged to have such excellent friends and colleagues.

In short…

My life currently rocks beyond my ability to tell it. I’ve been able to help other people’s lives to rock too. A lot of this is due to the award. Many thanks to those who nominated and voted for me, and to the Agile Alliance for continuing to make a difference.

The Gift

If you would like someone to receive a similar gift to the one that I’ve been given in this last year, enabling them to spread their knowledge and ideas to other communities that they wouldn’t normally reach, please nominate at pask-nominations AT agilealliance DOT org. You can see the kind of things we’ve been nominated for in the past. Mostly we’re looking for people who aren’t particularly famous or well known; who haven’t written books or run keynotes, who sit “below the radar”, and could benefit from more exposure – and who will benefit their communities in turn, passing on the opportunities and making the best use of the fame that comes with it.

Do you know of anyone who’s helped their communities? Who’s driven Agile forward in difficult or unusual circumstances? Who’s created an idea, or a community, or a tool, that’s truly revolutionary?

If so, don’t wait – post that email now.

We planned our way with maps we’d made already
Assuming the terrain would be the same,
Expecting well-paved roads to keep us steady
And any local creatures to be tame.
We loaded up our caravans and wagons
With good advice, best practices and tools
But didn’t spot the legend – “Here be dragons!”
So we got burnt, again. They say that fools
Rush in, and yet we count ourselves as wise,
We praise each other’s skill and raise a glass
To intellect – ignoring the demise
Of expeditions just as skilled as ours.
When they return, worn out, their pride in shreds,
We laugh and say, “A death march! You expect
Such things to fail.” And in our clever heads
It’s obvious – at least in retrospect.
The dragons of our ignorance will slay us
If we don’t slay them first. We could be brave
And work for kings who don’t refuse to pay us
When we’re delayed because we found their cave.

They say that matter cannot be created,
A fundamental principle and law,
While dragons keep emerging, unabated;
As many as you slay, there’s still one more.
Our ignorance is limitless – be grateful,
Or else we’d find we’ve nothing left to learn;
To be surprised by dragons may be fateful,
But truth be told, it’s best laid plans that burn.
We could seek out the dragons in their dungeons
And tread there softly, ready to retreat;
We could seek other roads, postponing large ones,
And only fight the ones we might defeat.
The world could be a world of dragon slayers
And stand as men and women, not as mice;
The joy that comes from learning more should sway us;
The fiercest dragons won’t surprise us twice.
Discover tiny dragons, be they few,
And all the mightiest, with equal praise -
Uncertainty’s our muse of all that’s new,
And ignorance the space in which she plays.

To explain, I’ll go back to the time when I first learnt BDD.

BDD started at a unit or class level

Dan North started doing BDD at a unit or class level, as a replacement for TDD – a mechanism for describing the behaviour of code and providing examples, without using the word “test”, because it turned out that this clarified a lot of the confusion (and I still find it much easier to teach TDD if I avoid the word “test”, whatever I subsequently call it).

It was only when Chris Matts said, “That looks quite a lot like analysis,” that Dan began taking it out to describe the behaviour of whole systems of code.

ATDD practices at the time weren’t all that solid

When I came across BDD (late 2004), I was working on a project which had been driven quite heavily with ATDD – at least to start with.

This project had 160 acceptance tests. They all consisted of lists of text boxes, button clicks, locating more text boxes and repeating until a particular outcome was reached. They were lengthy. They were rigorous. Unfortunately, at some point someone had introduced a dialog box into the flow, disrupting about 30% of these tests. There were another 10% also failing, possibly for similar reasons.

It took a couple of days for two of us to work through them, fixing the tests. We got most of them working, but not enough for anyone to actually care about them. The acceptance tests were making things hard to change.

BDD changed the landscape

Dan has since said that JBehave was “just a thought experiment”, and he didn’t really expect anyone to use it. (That’s good, because it JBehave 1.0 was pretty unusable, at least at a scenario level). It worked as a thought experiment, though, and lots of people started doing ATDD in a very different way – creating examples of how their system worked, and using those examples to explore the scope of their systems as well as the responsibility of their classes. Lots of people started working outside-in, from the UIs through which users experienced the system’s behaviour, to the controllers, the domain models, the utility classes, services, repositories, etc., until they finally had working software that tended to matter more to the stakeholders of the project than software had before.

Dave Chelimsky’s movement over to plain text really helped this movement to take off. When people think of “BDD” they often think of the frameworks which have copied this (Cucumber and JBehave 2.0 amongst them), even though this isn’t the complete story. They have certainly encouraged developers – famous for their introverted natures – to boldly go into the analysis space.

BDD enabled conversation

Whether through frameworks, DSLs or just conversation, the biggest difference between BDD and ATDD was the way in which BDD enabled a common language between users and business stakeholders, because it supports Domain Driven Design’s “ubiquitous language” (forgive the rabbit-in-the-headlights look, it was my first ever video!), and provides its own ubiquitous language for software development – the language of examples and behaviour, rather than tests and acceptance criteria.

The second difference was the reusability of steps. This is something which a lot of BDDers are still struggling with, so we’ve still got a way to go here. (More on steps and business / system capabilities some other time).

BDD doesn’t just stop at scenarios, it goes all the way to the project vision

Finally, Chris Matts introduced Feature Injection, which takes BDD’s patterns all the way into the analysis space.

(I consider Feature Injection and BDD to be children of Deliberate Discovery (even though they preceded it), which is itself a child of Real Options. I summarise Deliberate Discovery as the act of wilfully addressing ignorance. Both Deliberate Discovery and Real Options have implications and uses beyond software development, and I heartily recommend coaches and managers to go read up on them. In fact, everyone who lives a life of any kind of uncertainty should go and read up on them. And if your life is staid and comfortable, maybe it will help you to step into those challenging spaces. Go do it anyway.)

Or at least, this used to be the difference…

So that’s the past. What about now?

Well, most people who do ATDD nowadays use the Given-When-Then template which Chris introduced (shout-out to Gojko Adzic for his work in this space). They use domain language in conversation with the business. They’re interested in discussing what software would actually make a difference, then capturing that and sometimes automating it, with a focus on working out the software which would matter.

I’m guided by Dan’s words to the BDD Google Group, which apply both to TDD and ATDD:

I think you can over-think these things.
I’d like to avoid “BDD is better than TDD because…” or even “BDD is
different from TDD (as originally envisioned) because…”

TDD is amazing. Its initial conception was to solve exactly what I’ve been
trying to do with BDD. Originally it was described as variable scope (i.e.
covering both the space of modern day TDD-in-the-small and what the ATDD/SBE
folks are doing in the functional testing space). It’s not the *only* way to
come up with good design, and neither is BDD. They’re just both useful to
have in your back pocket as you go around trying to write decent software to
solve useful problems.

They’re called different things

The difference is that one is called Behaviour Driven Development – and some people find that wording useful – and one (or two) is called (Acceptance) Test Driven Development – and some people find that wording useful in a different way.

And that’s it.

I’ll start by defining these two things as I understand them.

• A scenario is an example of the system’s behavior from one or more users’ perspectives.
• Acceptance criteria are a set of rules which cover aspects of a system’s behavior, and from which scenarios can be derived.

Here’s a scenario from the pet shop I use in my BDD tutorials.


Given a rabbit called Fluffy who is 1 1/2 months old
When we try to sell Fluffy
Then we should be told Fluffy is too young.


This is an example of the kind of thing a pet shop employee might encounter in the till software. It’s quite specific, containing actual data, and illustrates our domain nicely. We can tell quite a lot from this: that pets have names, that there are rules around the sale of pets, the units in which we measure the age of young pets, etc.

We can’t tell, though, what age we would be allowed to sell the pets. Is it fixed? For all pets? Let’s look at something else:


Given a baby animal is younger than its recommended selling age
When we try to sell it
Then we should be told it's too young.


Despite the Given, When and Then, this is not a scenario. It’s acceptance criteria – a full specification of this aspect of behavior – phrased in scenario form. A lot of the time, I see people write criteria like this, then become confused when they can’t treat it like a real scenario – discussing it in detail, deriving further edge cases, automating it, etc.

Talking through scenarios is, for me, the most important aspect of BDD. That’s how we discover whether we have a shared understanding or not; by using specific examples to illustrate our understanding or discover our ignorance.

When we’re discussing the scenarios, it isn’t always necessary to write scenarios for all the acceptance criteria. As long as the acceptance criteria are clear enough to derive the relevant scenarios easily, I recommend leaving it as acceptance criteria until the point where it needs to be automated. You can tell if the scenarios can be derived in just a few seconds of conversation. You don’t need to write down everything.

It’s also possible to phrase acceptance criteria in other ways:


We should be prevented from selling animals younger than the recommended age.


Now you can talk through the scenarios, and see potential other criteria which you missed:


Customers should be encouraged to return when the animal is old enough to sell.


As you’re talking through the scenarios, the information we need for automation will emerge, and a better understanding of the domain spreads amongst the people involved in those discussions (usually a dev, BD and tester):


Given rabbits can't be sold before they're 2 months old
Given Fluffy the rabbit is 1 1/2 months old
When we try to sell Fluffy
Then we should be prompted to tell the customer, "This pet is too young. Please come back in 15 days to collect your pet."


By talking about both acceptance criteria and scenarios, asking why, and using scenarios to illustrate the criteria, we find out more about our domain. We can also automate them later on, where they’ll help to provide living documentation and act as regression tests.

There’s one other difference between a Scenario and Acceptance Criteria or even an Acceptance Test. You can ask your business stakeholders, “Can you give me a scenario where that happens?” or “Can you give me an example?” I’ve found this often draws out more useful discussions than, “Can you give me acceptance criteria for this?” or “Can you help me work out how to test this?”

The language of BDD, and particularly its vocabulary, provide a ubiquitous language for analysis and development.

Now we’re talking.