business – Codemanship's Blog

Supermarkets are famously cashflow businesses. They don’t buy a million bottles of shampoo and stick them in a warehouse to sell throughout the year. They buy just enough bottles for the week, and those bottles will find their way on to shelves and into shoppers’ baskets very quickly.

Their supply chains are what they call “just-in-time”. The product goes from the supplier’s factory to the supermarket checkout as quickly as possible. Their systems and processes are streamlined to make lead times short.

The amount of money a business has invested in, say, stock or parts or ingredients is called “working capital”. Businesses of all kinds seek to minimise their working capital and to maximise their cashflow so there’s enough money to “keep the lights on” while they realise the return on their investment.

Software development’s an investment that our customers hope to see a return on in a similar way. And the flow of that return can be crucial to keeping the lights on. I’ve seen a lot of start-ups fail, not because what they were creating had no value, but because they ran out of cash to pay staff and creditors before that value could be realised.

The working capital in software development – the shampoo sitting in warehouses, if you like – is all the work that the development team has done that has yet to make it into the hands of users. Software that can’t be used has no value. Let’s call it “work in progress”.

Development teams who care about keeping the lights on seek to minimise the amount of work in progress, and to maximise the flow of value out into the business. They don’t design and build 50 features and then release the software after 12 months. They design and build one feature and release that as soon as it’s ready to be consumed. From the factory to the checkout lickety-split!

And in the same way a supermarket’s supply chains are optimised to get the product from the supplier to the checkout as soon as possible, the best dev teams optimise their processes to make the lead times on getting feature and change requests into production as short as possible, and reliably as possible.

Just-in-time delivery processes have another major advantage. If your supermarket bought a year’s supply of a particular brand of shampoo, and halfway through the year a new brand is launched with a massive ad campaign, you’re potentially stuck with a tonne of bottles that are suddenly “so last year”. If you buy them one week’s worth at a time, you can switch brands and capitalise on the buzz.

The practices of code craft – Continuous Testing, Continuous Integration, Test-Driven Development, Refactoring, Modular Design – are enablers of limiting work in progress, shrinking lead times, maximising the flow of value and improving responsiveness to changing needs.

If you’re serious about building your team’s capability to rapidly, reliably and sustainably evolve software to meet rapidly changing business needs, my Code Craft and Test-Driven Development live remote training workshops are HALF PRICE until March 31st 2025.

An anti-pattern I see often in software development is an organisation taking an A team – highly skilled, highly motivated – and somehow managing to squeeze a D performance out of them.

The problem is almost always that they won’t let the A team bring their A game. The team are micromanaged, often with dysfunctional processes and practices and other constraints imposed on them by management.

As a trainer and mentor of dev teams, I sadly often hear complaints like “We want to write more unit tests, but our manager won’t let us” or “We’re not allowed to push directly to the trunk” or “They don’t let us talk to the end users”.

Now, I would say “Why did you ask for permission?”, because I’m that kind of a developer. I will assume I was hired because they thought I’d do a good job (although I have been hired specifically not to do a good job, but that’s office politics for you). So I’m going to try to do the best job I can, the best way I know how.

And that means I’m going to continuously test the code. I’m going to continuously integrate my changes. I’m going to talk to end users. A lot.

One common characteristic of high-performing development teams is they have a considerable amount of autonomy to do what needs to be done to get good results for their customers. And here’s where it gets a little tricky.

Most people in positions of authority don’t willingly give away decision-making power. They find autonomy threatening. For all the talk of “servant-leaders”, they’re rare in reality.

Most often, when dev teams have high autonomy, it’s not because it was given, it’s because it was TAKEN.

But there are two sides to this bargain. If we get to work the way we think we should work, we have to deliver the goods. Teams who don’t deliver – perhaps because they’re being micromanaged – tend to get micromanaged even more closely. It’s a paradox. We have to earn the trust to be given the trust to do what needs to be done to earn that trust.

Our confidence – now there’s a word! – that we can deliver, and our ability to assert ourselves within the process, is a key enabler of achieving necessary levels of autonomy. It’s a quality A teams need to play an A game. Sorry folks. That’s the reality.

The mirror universe version of all this is those developers who insist on doing things badly. The thing about D developers is they can often genuinely believe they’re playing an A game (when I was new to the industry, I was inexperienced enough to believe this, too – I just didn’t know what an A game looked like).

Skills and education are pivotal here, as is a more democratic approach to setting the direction within the team. As much as I’d love to believe that my strong leadership was what delivered, I have to remind myself that – in reality – it’s the TEAM who deliver, and they do it the best way they can agree on.

Tag: business

The A-Z of Code Craft – J is for Just-In-Time

The A-Z of Code Craft – F is for Freedom