Leanpub: Publish Early, Publish Often

The Principle of #smallbatches

Think of #smallbatches like The Force. You have to use The Force. You also have to use small batches! Use them everywhere and with wild abandon.

The Principle of #smallbatches originally comes from Eric Ries’s The Lean Startup. But recently for me, it’s exploded into the underpinning of nearly every successful element to Agile, mature software development and life in general. If you want to just get stuff done, you are doing yourself a favour by breaking large items down into small pieces and then completing those in batches. Why? Well, I’m really glad you asked.

Because Small is Fast

It’s not rocket surgery. The smaller a task is, the faster one can complete it. Done? Move on?

No, it’s more than that. Humans have a natural tendency to be driven about things in a decaying exponential fashion.
human drive decays exponentially

You get excited to build this feature and then by day 3 you hate it! It’s not only not motivating but you avoid it, watch YouTube and sometimes even try to hand it off to your fellow developers. The longer a task takes, the higher the likelihood that it will end up being loathed by the one completing it. This is not how you get love into your code. Keep things small and they will get done quickly. People need inspiration, and developers particularly need to see progress and continual momentum. Small helps you get there.

Because Small is Easier

Want to get something done? Make it easy.

“Oh but Matt, life is not easy. Some things are complicated and tricky and you can’t live all your days in fairy-tale-agile-land and expect to be able to decompose everything into small, easy tasks.” Um..
Yes you can.

It’s not easy making things easy, just like it’s not simple making things simple. But I’ll teach you how and you’ll begin to see the invisible lines where things can be divided, cut in half and broken into smaller chunks. Let someone else do it the hard way.

Because Smaller is Clearer

Or rather, having something with less breadth makes it easier to define clearly.

Clarity and quantity have a kinda logarithmic relationship I’d say. So it stands to reason that with less, making something clear and easy to understand becomes an easier task. You will see below that our Features are so small, the scope can usually be captured in a few bullet points.

Because Small == Low Risk

Using the #agileforteams process, you will learn to deploy Features into PROD (production environment) as small, thin vertical slices of value. That means that each Feature offers the end user something real and useful. It might not be the finished workflow or complete behaviour, but we phrase Features as something completely integrated so that it at least adds some value. This is the test for the lower bounds of how we define “small”. It’s too small if it’s no longer delivering value to the user. Sometimes this can be as small as a new select list on a form, or a new piece of copy in a footer. If that copy in the footer gives the user some needed context that improves the experience then it could be adding value and so it’s big enough. This sets the bar very low and allows us to cut things up many, many ways.

Pushing small vertical Features into PROD is a low risk exercise. Now provided that you have an automated build pipeline, a staged-deployment strategy and other development best-practices like automated testing and production monitoring, etc (I’ll help you get there too), you should not feel hesitant about putting small things into PROD. A small change into PROD can be rolled back (or forward!) quickly and easily. If it’s wrong, the impact surface is less. The risk is less. Integrating and deploying many changes and days worth of work at once is risky and dangerous. Free yourself and your managers from anxiety by using #smallbatches to reduce risk.

Because Small gives you Fast Feedback

We’ve talked about feedback and feedback loops and this is entirely enabled by keeping things small. If you’re heading off in the wrong direction because the scope wasn’t clear enough, or you’ve made the wrong assumptions or you’re just building it “how I think it should be done” then you’re going to spend less time on that wasteful activity if the average Feature size is smaller.

This happens less with Pair Programming (pairing) as the other party usually detects the deviation to “wrong town” much sooner given they’re watching you type. But even if you don’t use pairing, you can expect members of your team to churn on something that later turns out to be the wrong choice a lot less often.

The other (more important?) feedback that you receive faster by having things small is the feedback from the customer or Product Owner. Often large whole features are broken down into smaller (yet still value delivering) features and delivered to the customer for their validation. It’s this fast customer feedback that keeps your team on track and the smaller the tasks, the less time you waste in the wrong direction.

For the model aircraft aficionados of you out there, you can think of it like a PID loop that is “tuned”.

Small often removes dependencies

This is not always the case, but many times, we’ve found that by breaking large items into smaller pieces where we can express the value of each component independently, tight coupling becomes less tight. Some things still make sense to be done in a certain order. eg. The first part of the signup form should have the email. Later stories can capture less critical user data, but if the email is the user’s key in the database then there really can’t be a story which delivers a valuable signup form without the email field.

Often the Product Owner can worry about things like this, instead of the team, and maintain implicit dependencies using the order of items in the backlog. This often alleviates the need to use first-class dependency features in tools. It’s just another thing not to use unless it delivers more value than it costs.

So how do you get to Small?

Half, then half again is a great read but I want you to take this away: you can always make something smaller than you think.

You want to break things down by identifying the most important elements first and then seeing how small you can make those while they still make sense and deliver some value. You’re not necessarily cutting the rest (although, that’s often a great idea!) but you start to draw lines around sub-parts and these boundaries help you to find your collection of small Features that make up the whole.

It’s another human-centric activity to coach a customer or Product Owner through practising #smallbatches. It’s not something folks immediately grok. If I can teach it to you, then you can teach it to your teammates and then they can coach your customers and stakeholders through it too. Sooner or later you’ll naturally see those magic lines of separation and be breaking things down into small parts all day long.

How-To: Cutting something up

I recently helped a customer cut up a large block of work into small pieces. It wasn’t easy but we did it in about 45 mins together in a small meeting room and at the end, the feedback about the process was very positive. Remember: agile is a human-centric set of activities and often you have to introduce newcomers by way of taking them on a journey. It’s a hand-holding exercise of sorts. People learn best by doing. The least scary learning by doing is doing with a friend.

Here is a really bad drawing of this screen we had to build. It was a dashboard designed to quickly radiate a whole heap of context so that a controller could make decisions based on the visible context.
really bad drawing of a dashboard

This was a semi-interactive dashboard so there was some “behaviour” but the important thing is that there was a lot here. We need to go from a lot, to many pieces of a little. Here we go:

I first introduced this idea of cutting up the work to Kim simply by explaining that it will allow our team to capture the whole requirements easier and deliver it to her faster. Now when I said “faster”, I clarified by saying that the total work might not be done faster than traditional (non-agile) methods, but that she’d certainly see the beginning of the work much sooner than a big-bang approach. Kim was fine with this and excited to see something sooner versus everything much later.
Next we discussed priorities. “What is the most crucial part of this dashboard?” I said. I asked Kim to tell me which half of the dashboard she’d like if she could not have the other. I clarified by explaining that she would certainly have the other half, but the question is designed to be an aid for identifying priorities.
After cutting the dashboard into 2 parts, we then focused on the most important part and tried to cut it in half again. This discussion eventually led us to not only a subset in the data which would eventually be shown in this table, but only some of the columns and none of the interactive behaviour. Having the scope reduced in terms of source data as well as UI was great because it reduced the total amount of work from a number of fronts. Sure it was a vertical slice that would touch the database, domain and UI, but each of those was less work than it could have been.
We continued this process and I think we came up with about 8 Features for the first part of the dashboard. These 8 didn’t cover all of the things Kim wanted, but it was enough for us to get started and would create a good boundary for the first phase so we could get feedback from other users.
Agile includes a theme called Just In Time (JIT), loosely based on Just In Time Production, which says that we don’t need to plan everything: but just enough for the present and near future. The distant future will likely be different by the time we get there, so planning for it now is just more waste.
The first Feature was probably the largest in this group since it included the “first time effort” of a number of things we’d never done before. It was started and delivered in 4 days so I think that’s pretty good for something that was cut in half a couple of times. On reflection, I think there were aspects of that first Feature that could have been split out even further, into separate Features, so it could have been smaller. But I’m happy with how it went. You learn and then you adapt.

I want to sell you an idea first and then show you how to achieve it. This is why I explained all the benefits of #smallbatches first and then explained how it’s done (and there’s more examples to come). It’s not easy. Breaking things up and making it part of your team’s customer interaction and standard practice takes work, time and practice. But it’s worth it! Just like many of the following tools and techniques are worth it. You need to decide for yourself however. Use the How-To: To add or not to add steps above and weigh the benefits and the costs. In my experience, the benefits and joy of having things small far outweigh what it takes to get there.