Flow and Work In Progress

Near the beginning of my career the lag between writing code and it being deployed in production was about 6 months. It could be 2 weeks before a tester deployed it to check it. Feedback was almost non-existant and you frequently had to investigate what you had written all that time ago (plus all the other changes the team had made to it).

We had what would be described now as long lived branches. One of my colleagues had to maintain fixes for bugs and feature parity across 7 active branches.

Today it is possible to have a small change be suggested in the morning, and implement it, then deploy it that afternoon. This is a 180:1 improvement in throughput!

Releasing every six months resulted in frantic planning and regression testing. This encouraged huge batches of work, with regression test cycles and lots of handovers.

Now we try and release as little in a batch as we can. If there is any risk it can be a single PR deploy. If bugs are found you can quickly isolate the cause and fix/revert.

There is now realistic feedback on changes.

We now try and strip every PR down to something that adds value to a system. It may take 3 of these before a customer sees a change, but the risk of merge conflicts has almost been eliminated.

The practical benefit is that you can experiment with small improvements and find out how to improve the system as a whole.

We also release far more features than in the 6 month cycles we used to have.

Leave a comment