Forem: Jez Halford

You have the power!

Jez Halford — Sat, 27 Jan 2018 11:11:06 +0000

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”?

All-powerful bit-flipping super gods? What happened?

API not finished? Code a stub. Test for the new schema and use the existing behaviour until it turns up. Understand the domain logic, learn that the value we want is “false” 90% of the time and just hard code “false” for now.

Front-end not ready? Add a feature flag. Release the new API anyway, because the front-end can just ignore it for now. Version your API. Just go over to the front-end team and get your hands dirty.

Push forward, any way you can. Blockers are all in your mind. Smash them. Work around them. Get creative. Bend those machines to your iron will.

I understand it’s hard to do. I’ve used plenty of those kinds of excuses myself. But the problem is really just the way we think about things. Everyone knows software is never finished. But individual features are never finished either.

There’s always a temptation to delay merging and releasing until everything is perfect. But our idea of perfection is always changing, just like everything else.

So: embrace the chaos, get stuck in and get busy changing stuff. We can always change it again tomorrow. That’s what we do.

Jez Halford is a software development consultant helping teams to deliver better software, more frequently. Visit jezhalford.com to find out more.

Measure what matters

Jez Halford — Sat, 27 Jan 2018 10:38:55 +0000

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.

But developers (and indeed most other people) hate being measured. It suggests a lack of trust. It suggests that you think they’re lazy. That’s an unhappy situation for anyone.

But I’ll let you into a secret. The accuracy of your measurements probably don’t actually matter anywhere near as much as you think. And that’s because the time things take to be delivered — actually, properly done and working — is almost certainly far longer than you’d guess.

30 days? 60 days? 80? 100? It’s not uncommon. From first idea to last deployment is often a frighteningly long time.

Of course, this isn’t the case for all teams. If you’re already delivering complete features (be honest) in a few days, then measuring and improving is a different matter. But given a scale of tens-of-days, getting your team to log time down to the minute starts to look a bit crazy.

So, as a start, just take notes. Once something is committed to, write down the date. Then once everyone agrees it’s done, write down the date again. In a few months, you’ll probably have a reasonable picture, and hard data you can use to estimate future features, and test the effectiveness of improvements. All without jeopardising your teams’ trust.

Jez Halford is a software development consultant helping teams to deliver better software, more frequently. Visit jezhalford.com to find out more.

Why it’s hard to get stuff done

Jez Halford — Mon, 15 Jan 2018 09:15:33 +0000

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. Our work ends up looking something like this:

All those exes represent half-finished stuff that we leave hanging around. With any luck we might finish one of those things, but it certainly looks like we’re starting more than we’re finishing, doesn’t it?

If we continue to start more than we finish, we’ll find that things pile up. And before we know it we’ll be over-run with half finished bits of work that cloud our view of what’s important.

That’s when we start fire-fighting, and desperately picking off bits of work for whoever shouts loudest.

This is a horrible way to live our lives.

This situation is something we all need to work hard to avoid. The solution is simple to describe, but hard to do. Just finish something before you start something. Stop jumping between work streams and focus on something to completion.

The hard part is that might mean working on nothing at all until your blocker is resolved. The best teams learn to recognise these situations, and come together to overcome the problem as quickly as possible. By focusing on clearing road blocks in this way, you will ultimately finish and deliver something.

And one thing delivered is absolutely better than ten things half finished.

Jez Halford is a software development consultant helping teams to deliver better software, more frequently. Visit jezhalford.com to find out more.

Why your software doesn’t work

Jez Halford — Fri, 05 Jan 2018 15:54:23 +0000

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. Her bank, her employer, business, and so forth.

It turned out to be a huge pain, because very few of those organisations provided a way to make this kind of change easily. Their software didn’t easily support it.

But why not?

As you’re probably aware, most software developers are male. It’s an unfortunate situation and something we need to work to improve. But that’s the situation we’re in. Consider this train of thought, in the typical developer’s mind:

“People will need to edit their profiles”

…

“I should make it easy to change your address, in case people move house”

…

“How often do people change their names? We can probably de-scope that if it won’t fit in the sprint”

And so, newly married women have a problem on their hands. Now I don’t imagine for a moment that our example developer was aware of the relatively common scenario that he missed. I just didn’t occur to him. Worse still, even if we brainstormed for half an hour and tried really hard to think about edge cases, there’s a pretty good chance that changing your name would still end up a low-priority feature, if we even think of it at all.

These are unconscious assumptions. They’re logical leaps that we make without realising it. It’s hard to avoid them, and they’re everywhere. Remember the face recognition software that didn’t work for black people? Unconscious assumption.

How many unconscious assumptions do you suppose are built into software that deals in complex business logic, where the developer only thinks they understand the domain? This problem is everywhere.

But you can’t just tell people “think harder about your assumptions”. The point is that these are assumptions we don’t know we’re making.

So, we need to build testing these assumptions into the fabric of how we deliver software.

That’s the point of agile. It’s the point of demos, and workshops and involving the client at every stage.

But we’re not doing it enough. We need to deliver in ever smaller increments. Build. Deploy. Verify. Build. Deploy. Verify. Over and over until we get it right.

Can’t do that? Can’t get a build in front of your client and have them tell you it works within a reasonable time frame? Then before you build anything else, get yourself into a situation where you can, avoid unconscious assumptions and build software that works.

Jez Halford is a software development consultant helping teams to deliver better software, more frequently. Visit jezhalford.com to find out more.

Seven Deadly Wastes: Don’t Over Think It

Jez Halford — Mon, 27 Nov 2017 11:10:56 +0000

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. But nice isn’t always what the customer wants, and it isn’t always what solves the problem.

I’m a big fan of building software in lots of small steps. Build the smallest thing, ship it, and improve it. This approach is great because it keeps you grounded to the users’ needs, and it also helps you avoid wasting time on over processing. It maintains focus.

So, stop thinking about it, stop polishing it, just ship it.

Going Faster: Weekly ideas on speeding up your software team by Jez Halford, a software development consultant helping teams to deliver better software more quickly.

There’s more from Jez on Twitter, Mediumand jezhalford.com

Seven Deadly Wastes: Waiting

Jez Halford — Tue, 07 Nov 2017 12:22:28 +0000

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. That means that if it takes you ten days to deliver a new feature, it’s probably only been the focus of someone’s attention for a day-and-a-half.

But why does all that waiting around happen?

If you package your features up into larger releases then the ones finished first will have to wait for the ones finished later.
If you hand-over responsibility for the work between multiple teams or individuals then it will wait for them to become available.
If you start work before it really needs to be started then it will wait for stakeholders to be ready for it.
If you start work without understanding it then it will wait for you to clarify what you’re supposed to be doing.

All of those scenarios are probably familiar to you. They’re unbelievably common across the software industry. But they are wasteful practices.

While it’s very hard to eliminate waiting entirely, it’s relatively easy to start to reduce it. All you have to do is decide to work on one thing at a time.

That doesn’t mean work on one thing until you get blocked, and then switch to something else. All that will do is create inventory waste. Instead, it means pursuing a single item of work all the way to completion, ignoring all other distractions.

At first this will probably be hard, and you’ll need to be pragmatic about how you define “completion (you’re not going to and eliminate large releases over night). You’ll spend a lot of time waiting. But because now you’re waiting along with the work, you’ll start to notice.

Gradually, this approach drives change in your team, in your process, and in your wider organisation, so that people are empowered to finish what they start without so much waste. It can be a long road, but even a tiny reduction in waiting waste can have a huge impact on your productivity.

Going Faster: Weekly ideas on speeding up your software team by Jez Halford, a software development consultant helping teams to deliver better software more quickly.

There’s more from Jez on Twitter, Mediumand jezhalford.com

Seven Deadly Wastes: Motion

Jez Halford — Mon, 30 Oct 2017 13:21:19 +0000

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.

People gathering around a problem? That’s motion.

Of course, unexpected things happen, and we need to be able to deal with them. But we can take steps to reduce the impact they have.

One way you might already do this is with a daily standup meeting. This is a regular session every day during which we try to head off problems before they hurt us. If we didn’t have the daily standup, we might end up having two or three ad-hoc meetings throughout the day instead. The standup has therefore helped us to reduce motion.

Sprints are another means of reducing motion waste. We schedule a regular time to plan a small chunk of work in detail, and we hope that reduces the potential for chaos down the line.

Another option to explore is policy. Policies are simple sets of rules that tell us how to deal with certain situations. You probably have plenty of polices in your team already. Policies are things like “when we find a bug it gets prioritised by a product owner before developers look at it”.

Policies like that help teams to work autonomously, because they don’t have to ask someone what to do in a given situation. They reduce motion because they stop us from having to run around looking for solutions.

Motion waste is often hiding in plain sight. But finding it, and fixing it, can be an incredibly effective way to speed up your team.

Going Faster: Weekly ideas on speeding up your software team by Jez Halford, a software development consultant helping teams to deliver better software more quickly.

There’s more from Jez on Twitter, Mediumand jezhalford.com

Seven Deadly Wastes: Inventory

Jez Halford — Mon, 23 Oct 2017 12:21:50 +0000

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. That maximises our productivity while minimising our waste.

But why does it matter?

Unfinished software is far more harmful than it might at first seem. How often have you encountered one of these situations —

You can’t release urgent feature X, because half-finished feature Y is already merged in, and you haven’t shipped that yet.
You know that important thing is in your git stash somewhere but can’t remember where.
Someone asks you to release features in a different sequence to the one they were developed in, and you end up in merge-hell.
You can’t ever seem to focus on a single problem for more than an hour before something else urgent comes along.

These are all examples of work in progress slowing us down.

The simple answer to this is to simply not start anything new until you’ve finished what you’re currently doing. Life is of course, rarely that easy.

It might be helpful to use a physical Kanban board to visualise your work in progress. Seeing the volume of tickets a team is working on can really help hammer home the complexity for managers.

Kanban can help us in other ways, too. In short, you represent your process as columns on the board — to do, in dev, in QA, etc — and move cards between them for each work item. You then set limits for how much work each column is allowed to hold at any given time. By sticking to those limits, we can force ourselves to move stuff out of the way before we pull more things in. If you get really good at it, you can fine-tune those limits to maximise your flow efficiency and deliver really quickly.

It’s also important to try to ship things as often as you can, and in the smallest increments possible. It’s far easier to make one small change to production than it is to make a huge raft of changes all at once. Yet so many of us still go weeks, even months, between releases. It always seems harder, but once you get to grips with changing things little and often, it’s always far less work.

In my experience, inventory is one of the most common wastes encountered by organisations of all sizes. It’s easy to overlook, and it can have a huge impact on your productivity. But fortunately it is also quite easy to reduce, once you recognise it.

Remember: stop starting and start finishing!

Seven Deadly Wastes: Transport

Jez Halford — Mon, 16 Oct 2017 09:52:33 +0000

Going Faster: Issue 11

This week I want to revisit an idea I blogged about a while ago, and about which I’ve recently been speaking at a few conferences: the seven deadly wastes.

There are seven things that slow your software team down, and learning to conquer each of them is the key delivering faster.

The seven wastes come from the principle of of Lean Manufacturing, an idea with its origins in the Japanese car industry in the middle of the 20th century. That may seem a long way from the software industry of today, but the lessons are just as applicable to modern software development. By eliminating the seven wastes from your process, you’ll soon find your delivery times improve.

The first of the seven is transport.

Think in terms of hand-overs between teams. If your developers must pass work onto a test team (or individual), and it then moves to another person’s responsibility for acceptance or sign-off, and then again for release, you have transport waste. If you’ve ever engaged in “feature-tennis”â€Š–â€Šwhere an item is bounced back and forth between development and QA several times, then you’ve experienced severe transport waste.

One way to reduce handovers like that is to foster a spirit of collaboration. Encourage developers and testers to work together on a problem, and build a shared understanding of the solution.

Another form of transport waste comes from moving code around. Deployments, branching and merging are all forms of transport. Clearly some are necessaryâ€Š–â€Šyou need to be able to deploy thingsâ€Š–â€Šbut reducing the cost of that deployment is vital. If it takes more than a few minutes then it will have a significant impact on your productivity.

Identifying and reducing instances of transport in your process is a great step towards going faster. Next week, I’ll look at the next waste: inventory.

Going Faster: Weekly ideas on speeding up your software team by Jez Halford, a software development consultant helping teams to deliver better software more quickly.

There’s more from Jez on Twitter, Mediumand jezhalford.com

Going Faster: One step at a time

Jez Halford — Wed, 20 Sep 2017 07:58:07 +0000

I think building software is much more about how we move a system from one state to the next than many of us realise. When we write a new feature, we check out our code, modify it, and then build a new version of the software that incorporates our changes. It’s tempting, therefore, to think of our software as a series of still images, jumping from one snapshot to the next as we make changes.

But we’re never building isolated snapshots. We’re always moving from one picture to the next. We have users, data and state that needs to maintained between releases, and that means we need to put some thought into the process we’ll have to go through to move our software into its new shape.

How often have you experienced a change that was made to your codebase, worked fine in testing, and then blew up spectacularly once it reached production? Often this kind of problem can be attributed to a lack of understanding of the state of the system in production.

The most common area where developers may have to confront this is database migrations. These by their nature are always changes rather than snapshots. Drop that column, create this table; our migrations are instructions for moving us from one state to the next. I find it helpful, though, to think of every aspect of every change in the same way. It’s the developers job not simply to write how the code should be, but to consider exactly how to get it there.

I try to think of each change as a patch: a set of changes that will take us from one situation to another. Do we need to clear a cache? Are we installing new packages? Is it necessary to restart some services? How will this affect our users at the moment it is released? It can be tempting to dismiss these problems as the domain of our release process, either automated away or frustratingly worked-through by the unlucky sole who must perform a manual release.

Once we embrace this kind of patchy thinking, though, we start to get better at it. Maybe we don’t need to flush a cache every time we release? Wouldn’t our users have a better experience if we could do at least some of our releases without downtime? Once you’re used to thinking in this way, it starts to become easier to deliver smaller and smaller units of work.

Consider a typical new feature that someone might want to build. It might need a new database table, plus some new API endpoints for our front-end to talk to, and then a new set of user access controls, and new user interface elements to use the feature. It’s easy to build all of that in one go, and then release it.

But consider how we might deliver that feature across several small releases. First we add the new table. Next we build and release the new API endpoints, perhaps one at a time. Now we configure new access rules, disallowing all but internal users. Next we push out the new UI and finally we enable access to the feature for our users.

By working this way, we dramatically reduce the risk involved in each release. We no longer need to cross our fingers and hope it works, because we can build confidence in the system’s stability during the course of building the feature.

This is an idealised scenario, of course. Sometimes you need to make changes to existing features, or manipulate data in a way that’s not safe to do without downtime. But even if we only build a small percentage of our features this way, we’re still chipping away at the risk of big releases.

Going Faster: Weekly ideas on speeding up your software team by Jez Halford, a software development consultant helping teams to deliver better software more quickly. Subscribe at tinyletter.com/goingfaster to get Going Faster in your inbox.

There’s more from Jez on Twitterand jezhalford.com

Going Faster: Who Does What?

Jez Halford — Tue, 29 Aug 2017 11:29:09 +0000

Hello,

This week someone asked me a simple question. “Who should create that ticket?” It’s probably a question that’s been asked many times before. Who creates tickets? Who updates your issue tracking software? Who writes test cases? Who sends release notifications? There’s endless questions to ask about who does what.
But I realised something. The answers to those questions should be obvious. There shouldn’t be the slightest ambiguity or doubt about which people do what work, because as soon as there is doubt there are questions, and once there are questions there are delays.

So, can everyone on your team answer those questions without a further thought? I’d be willing to bet that they can’t.

I think almost every software team I’ve worked in has at some point gone through a phase of documenting how they work, in an effort to avoid such questions being necessary. Often the trigger for this is a round of new hires. New people need to know how we operate, so we’d better write it down. Almost without fail this results in the first new-hire getting the job of documenting how a team works. On occasion I’ve been that new-hire, and let me tell you, it’s a horrible way to join a team.

The whole reason we want to write this stuff down is because it’s hard for new people to assimilate the information. It’s awkward for them to ask questions about everything and there’s every chance they’ll miss something important because they didn’t want to bother the more experienced team members. So getting the new person to document your process is an absolute non-starter.

Furthermore, I’m pretty certain that if you asked each existing team member to document your process they’d all come up with something slightly different.
So, what I would do in this situation is exactly what I do when I’m starting to help a new team to go faster. I get them all in a room and I ask them how a feature goes from idea to live-in-front-of-customers. We draw a diagram on a whiteboard, or we arrange post-its on the wall. This can take a surprisingly long time. People disagree on seemingly fundamental points (“Do we do QA after we merge, or before?” “We use git-flow.” “Well I don’t!” etc). Take the time and build a consensus representing what the team actually does, not what they’d like to do or think they should do.

Once you have it documented, turn it into a nice big diagram and stick it on the wall. That’s right, on the wall. Not buried away in some wiki somewhere, not on the shared drive, not anywhere electronic. On the wall. Wikis are where documentation goes to die. The wall is where it thrives.

That way, when a new person starts you can show them how you work in just the same way as you show them to their desk or show them where to get a cup of tea. Nobody needs to be in any doubt, and the constant presence of the big diagram on the wall means that people remember what they agreed to.

You might occasionally need to re-draw bits of it, of course, but that’s just fine as long as everyone still agrees on the process you’re using.
Hopefully you’ll find that you spend less time answering questions are more time delivering software to your customers.

There’s more from Jez on Twitterand jezhalford.com

Software’s Seven Deadly Wastes

Jez Halford — Thu, 29 Jun 2017 16:21:35 +0000

There are seven things that slow your software team down. Learning to conquer each of them is the key delivering faster.
The seven wastes come from the principle of of Lean Manufacturing, an idea with its origins in Japanese industry at the beginning of the 20th century. That may seem a long way from the software industry of today, but the lessons are just as applicable to modern software development. By eliminating the seven wastes from your process, you’ll soon find your delivery times improve.
Let’s look at each of them.

Transport

This is the movement of materials from one location to another. It’s not hard to see how this slows manufacturingâ€Š–â€Ša factory split across two sites will obviously be difficult to runâ€Š–â€Šbut in software transport waste is generally harder to see. Think in terms of hand-overs between teams. If your developers must pass work onto a test team (or individual), and it then moves to another person’s responsibility for acceptance or sign-off, and then again for release, you have transport waste.
Reducing transport waste can be as simple as pairing testers with developers, but building a continuous integration (CI) system, or continuous delivery (CD) pipeline are also great solutions.

Inventory

This is undelivered stuff cluttering up the production line. Features that are started and then left behind by higher priority work are considered inventory, as are features that might be technically complete but which haven’t yet made it to customers. Carrying all this stuff along with you takes up brain space, confuses the picture and slows the team down. This can be an especially big problem if your branching strategy means you’re carrying lots of un-merged branches along with you.
The simplest way to reduce inventory is to just agree not to start things until you’ve finished other things. Each feature should enjoy a smooth progression from conception to delivery, and not stall during the process. Visualising your work on a Kanban board is a great way to see where you’re carrying inventory and help to reduce it.

Motion

Motion is the movement of people around the work at hand. This might be as simple as having to travel to another floor to find a meeting room, or search for a space in a hot-desking environment. It could also be more abstractâ€Š–â€Šthe delay caused by having to switch tasks too often, or deal with constant interruptions from other people and problems.
Motion is often caused by carrying too much inventory, so many of the steps above can help to reduce it. So can thinking about the physical environment, and agreeing fixed meetings rather than ad-hoc interruptions.

Waiting

Very simply, waiting is hanging around for delays. Waiting for an answer to a product question, waiting for an external system to be ready, or for another team to complete their work will all slow the process down.
You can reduce waiting by being careful not to start a feature until it’s well understood, and by ensuring any external teams or individuals have some slack in their schedules so they’re free when they’re needed.

Over Processing

In manufacturing this broadly refers to working too hardâ€Š–â€Šbuilding to unnecessarily fine tolerances or polishing things that will be hidden in the final piece. In software, this speaks to the YAGNI principle (“You ain’t gonna need it”). This refers to things like coding for imaginary levels of scale, building in useless caching or agonising over architecture for a simple product. A team mentality that favours frequent releases is your best weapon against such gold-plating, but be care must be taken to balance urgency of delivery with doing a job that’s good enough.

Overproduction

Put simply, this is building useless features. A figure often bandied around is that some 64% of built software features are rarely or never used. This comes from a limited study done in 2002, so the actual figure industry-wide probably varies. However, the absurdity of building things no-one will use is not hard to grasp. Careful product ownership and good user feedback can help combat this.

Defects

There’s an old story about a company that builds petrol lawnmowers. If the mower doesn’t start first time once it leaves the production line they simply throw it away for scrap. Spending time on fixing the defects doesn’t make economic sense for them.

Software is perhaps less cut-and-dried than that, but bug-chasing during development can certainly be a time sink. Automated tests are a good fix for this, but a good product owner can also reduce defects by making sure the requirements are understood first time.

The seven wastes will all manifest themselves differently in different teams, and the way you reduce each of them will be very specific to your situation. Keeping them in mind, however, is a really useful tool in your quest for faster delivery.

Going Faster: weekly tips for speeding up your software team. Subscribe at tinyletter.com/goingfaster

Jez Halford is a software development consultant helping teams to deliver better software, more frequently. Visit jezhalford.com to find out more.