Blockers are all in your mind. Smash them.
If you’re reading this, I imagine you’re some sort of software developer. A programmer, an engineer. A coder. What made you want to be a one of those?
For me, it was the idea that I can make a computer do anything I want. I imagine it might be similar reasons for other people. Within our digital domain, we are all-powerful bit-flipping super gods.
But here’s the interesting thing: sometimes I think we forget that.
Have you ever said something like: “That feature isn’t finished yet, because I’m waiting for the other team to finish their API”?
What about: “We can’t release this feature because we already merged the other feature, and that isn’t ready yet because the front-end team haven’t finished their bit, so we’ll just have to wait”? …
How long does it take you to deliver a feature into production, from inception to shipment?
If you can’t easily answer that question, it’s time to do some measuring. You can work to improve this metric over time, but unless you already know it, you’re just making wild guesses.
It’s easy to get hung up on how to find out this figure. One common method is to ask all your developers to meticulously log every moment of their time against whatever feature they’re working on.
Another option is to hire a crack team of project managers to log and catalogue everything that happens. …
Do you ever find you’re swamped by thousands of tiny things that stop you from ever making any real progress?
In software this sort of thing happens pretty often. Perhaps more often than in other industries — we’ve even come up with a handy name for those awkward niggles. “Blockers” are our catch-all excuse for not moving forward.
It can be tempting to leave it at that, and work on something else. When we encounter a problem we side-step it. We must “make progress” on something else, while we wait for the problem to resolve itself. …
Have you ever built some software that turned out not to be very good at what it was supposed to do? You’re not alone. More than half of all software projects end in failure, and I’d bet that plenty more end up as half-baked solutions that work some of the time.
Why are we so bad at this stuff?
Well, I have a theory. And it turns out it’s not really our fault. Sort of.
I got married a while ago, and my wife, Jodie, took my surname. That meant she had to spend ages changing her name with loads of organisations. …
Going Faster: Issue 17
The Seven Wastes are an idea from lean manufacturing, and I’m exploring how they relate to software development. Last time was over production, and this week I’m looking at the last one: defects.
It’s no great revelation to say that bugs slow us down, but they might slow us down more than you realise.
Say we catch a major defect during the final testing of a new feature, just before it’s due to be released. We all pat each other on the back — thank goodness we caught that! Good job everybody!
But now we have to rework the feature to remove the bug. Effectively, we’re back at the start. We need to go back and modify our code, test our feature (more effectively this time), run through any acceptance tests and whatever else we might do. If we’re unlucky we’ve also pushed our schedule back a bit too. …
Going Faster: Issue 16
The Seven Wastes are an idea from lean manufacturing, and I’m exploring how they relate to software development. Last time was over processing, and this week is over production.
Over production is, very simply, building stuff that isn’t needed or that nobody uses. Here’s a fun tweet that suggests some organisations will build anywhere from six to hundreds, or even thousands, of bits of software that all solve substantially the same problem.
But that’s not the only problem. Within any single piece of software there’s generally some features to be found that no one ever uses.
Clearly building and maintaining those applications and features is a waste of our time. But just how much time can we waste on it? …
Going Faster: Issue 15
The Seven Wastes are an idea from lean manufacturing, and I’m exploring how they relate to software development. Last time was waiting, and this week is over processing.
Over processing can be summarised as working too hard. If you’ve ever built in a caching layer “just in case”, if you’ve ever implemented an entirely image processing library just to churn out a few thumbnails, if you’ve ever spent days drawing diagrams and agonising over the problem, then maybe you’re over processing.
It’s the kind of thing engineers love to do. It’s gold plating, it’s making it nice. …
Going Faster: Issue 14
The Seven Wastes are an idea from lean manufacturing, and I’m exploring how they relate to software development. Last week was motion, and this week is waiting.
How long do you spend waiting for things? Well, that’s not actually important. A better question is: how long does your work spend waiting for things?
From the point you start work on a new item, to the point it is delivered to a customer, chances are it’s only actively worked on for around 15% of the time. …
Going Faster: Issue 13
The Seven Wastes are an idea from lean manufacturing, and I’m exploring how they relate to software development. Last week was inventory, and this week is motion.
Motion is the movement of people or things around work. This is why car factories use moving production lines — it’s much easier for the person who bolts on the wheels to stay still, and have the cars come along on a conveyor.
Reducing motion waste is all about reducing unnecessary movement. Of course, software isn’t a physical thing that we can gather around and look at. Or can we? If your team finds an unexpected situation (perhaps a production bug, or a realisation that your project is going in the wrong direction) then you probably gather everyone together into a meeting to look at the problem. …
Going Faster: Issue 12
The Seven Wastes are an idea from lean manufacturing, and I’m exploring how they relate to software development. Last week was transport, and this week is inventory.
Inventory is any product that hasn’t yet been delivered, so in manufacturing that’s components, materials, and unfinished products.
In software the closest match to inventory of that kind is work in progress. Put simply, that’s work that we’ve started but haven’t yet finished.
Work in progress is considered waste because it has no value. Until a feature is shipped and in front of customers, it might as well not exist. It isn’t doing us any good. So, lean manufacturing tells us, we should work to reduce our work in progress as much as possible. Practically speaking this means that, ideally, each person on a team should be working on only one thing at a time. …
About
