I once asked a business analyst, not knowing his role, what he did. From under his arm he produced a specification. Our conversation then went along these lines:

‘How long did it take?’
‘Three months.’
‘When was it completed?’
‘Three months ago.’
‘When will it be implemented?’

At this point the business analyst looked at me strangely.

Clearly, the specification was never going to be implemented. Yet he still carried it with him, probably every day.

All that time and effort was clearly wasted. So we looked a bit more closely. We examined the lead and cycle times of the development process at this company. Taking all types of activities into consideration (major changes, small change requests, and near-ubiquitous defects) the average cycle time was 16 percent. What does this mean? If an activity takes 100 days of elapsed time from start to finish, only 16 days were actual days of work. This means the activity was in a queue somewhere, waiting to be processed (more likely waiting for someone), for 84 days.   Batch_Size And the worst case scenario? Only two actual days of work.

The Work was Lying Around 98% of the Time

That project was lying around in a half-finished state for 98 days. How frustrating!

Do you remember the last time Facebook changed and re-launched their user-interface? Probably not. But maybe you will remember what followed: a flood of comments from users complaining about the change. Note that this change is singular—a single big change.

People don’t actually like change, despite the fact that it is always happening. Big changes are bad. Small changes are easier.

It is a given that specifications are part of the legacy of waterfall software development. When we still had silos. When the business analysts would ‘throw’ the specifications to development over a wall or fence, so to speak.

Nearly all of us know that specifications:

  • Introduce a big change.
  • Take time to complete.
  • Are often not implemented (waste).
  • Are usually difficult to understand.
  • Are inconsistent.
  • Are rarely read (let’s face it).
  • Allow developers to choose which parts are done first.
  • Allow the solution to be built horizontally in layers, like back end first, then middle tier, then finally front end. This pushes both delivered value and risk to the end of the project.
  • Define the solution. Inherently, specifications forget why the result is important for people, so we lose the project’s sense of purpose.

Specifications result in inefficient ‘big batch’ work.

This was all caused by the desire to plan, keep to the plan, and resist change.

We always misled ourselves to believe that if the specification gets signed off, then the plan will succeed.

If things changed, we knew that the specification may also have to change. And we all know how unsettling and expensive that can be, so we wanted to resist the potential of change even more.

If we had that nice big batch of work signed off, we wouldn’t have pain later. We could get on with the work. Please leave us in peace!

Yet when we resist change, we end up delivering something that the client, customer, or business doesn’t need. Which, again, is simply waste. But this time, it is waste on a grand scale. We all know that more than 50 percent of the features in software are never used. Huge percentages of projects fail.

Not only that, but if something important comes along, it is highly likely that the big piece of work has to be put on the side. All the effort up until that point is then wasted. No value was delivered. It is like a 1000-kg bomb exploding. The collateral damage is significant and spreads across several blocks of a city.

What does this really cost? When considering all the projects and products in the world, over the last decade, it probably adds up to the GDP of a small country. Or of Apple.

So, rather than having one big thing, the specification, that leads to a big, unsettling change, let’s consider having lots of small things. Let’s also consider the entire value chain. It’s a phrase we hear occasionally, but what is it? The value chain is the sum of all the actions and work that make something valuable to someone. Simple.

‘Yes’, I imagine you’re saying, ‘but Waterfall is a process, a value chain. At the end, I have value.’ I agree, but does it work? No, not really. We resist embracing change. We push lots of risk to the end and hope to deliver ‘value’ to the client only at the end, by which point she needs something else.

Instead, we need to constantly deliver value and eliminate risk as early as possible. That includes technical risk and user ‘acceptance’ risk.

Think Small

What we need is the same value chain, but the work within is in much smaller chunks, or batch sizes.

We need smaller batch sizes so we can start work, not get interrupted, and finish as quickly as possible.

I love the expression ‘start finishing, stop starting’.

But even if the small batches are interrupted, at least the amount of wasted effort is limited. In this case, it is just a small grenade exploding. The collateral damage is limited to the immediate vicinity.

Yet these small batches must deliver complete mini-solutions. These are, of course, our user stories. (And, by the way, technical user stories are just as important—don’t get hung up on having ‘only user stories’.)

By breaking our work into small bits, we get things moving through our value stream much more effectively. The people in the value stream are much more efficient too. And, if possible, we deliver value to the customer early and frequently.

Small Allows Your To Learn

One last thing. Remember that Facebook story near the beginning of this post? Well, changes are still taking place rapidly and relentlessly, but because they are not done as one ‘big bang’ batch, no one notices the changes. Not only that, but Facebook can A/B test changes, constantly learning and adapting to what their users like and want. This would not have been possible with big batches.

As we know, the devil is in the details. But the detail of user stories will be your saviour, producing greater effectiveness, efficiency, transparency, and value.

And our lead and cycle time ratios will start to improve. This increase is measurable, and guess what? Things that get measured get done. For example, Etsy deliver 30 “innovations” a day. How many are you delivering?

Ah ha, so you want game the statistics by making the “innovations” even smaller, to improve the ratios and measurements.  Well, I personally would be very happy with that. It is exactly what we want you to do!

And You? Have a Think about These Questions. (Book 15 minutes if you want to discuss)

  • What are your lead and cycle times?
  • How big are your batches?
  • How could you make your batches even smaller?
  • How would you recognise that your batches are too big?