A good physicist knows that every gravitational mass has an associated escape velocity. The escape velocity is the speed which an object needs to have to get away from the mass’ gravitational field. In layman’s terms this simply means that it takes a bunch of energy to fire a rocket off a planet’s surface and get it out into space and the stronger the gravity, the more energy you need.
The heavier a planet is, the more rocket fuel you need to carry to get up and into space. However, the more rocket fuel you carry, the more you need to carry just to lift the extra fuel you’re carrying. Unfortunately there comes a point when, like an overfed Christmas turkey, your rocket needs so much fuel to get away from the planet that it’s too heavy to lift its own bloated self. BTW if this all makes sense then feel good because it really is rocket science.
The same phenomenon is true for projects. The larger your project is, the harder it is for you to actually release a product from it. The more features in your backlog, the more of a struggle it is to wrestle the final product to freedom. This you already know. What you may not know though is that there’s a point where a product becomes so bloated that it may never escape the project’s gravity.
Every project has “churn”. This is the rate at which the project and the requirements change. No sooner have you written down a list of features than some portion of them will change. Priorities, requirements, previously undiscovered dependencies - all of these cause churn.
Despite its name, churn seldom means change and more often means growth. The rate at which this happens depends on the size of the project. The bigger the project, the more things there are to attract change and growth.
Unfortunately while your project churns faster and faster, the rate at which you can actually get it done is constant. You can only do so much in the day and if you’re not careful your forward progress gets drowned by the rate of change. Like a bird flying into a strong wind you will slow down and may even start to move backwards.
actual progress = velocity - churn
Teams assume that their velocity is equal to the number of points the engineering team work through each week. Wrong. Engineering velocity is just your airspeed and airspeed is not the same thing as ground speed. What matters is not how fast you’re flying into the wind but how fast you’re actually travelling towards your destination.
A team’s actual velocity is equal to the engineering velocity (jobs done per week) minus the amount of new jobs added (churn). Churn is approximately proportional to the size of the project- the bigger it is, the more that will change.
Project duration = Project size / (velocity - (churn rate x project size))
So for faster projects you can either reduce churn (bad)
The old school way to accelerate your ground speed was by reducing churn and having a feature-freeze. Feature freezes remove churn but at the cost of flexibility and reactiveness. This is not what you want. Building a product tells you what that product actually is. Seeing people use it tells you what needs to be changed. Adaptation is good and you need the flexibility to change so simply locking down features is going to grind you into some rigid hulk that no-one wants.
…or you can reduce project size (good)
Rather than reducing the rate at which you change things, you can instead reduce the overall mass of things available to be changed. The smaller the project, the less scope there is to churn.
“But we need to build lots of things!” you say. Fine but only ever build small, entirely self-contained versions of the big story. Don’t be afraid to change stuff or to make things that you’ll later have to dismantle. Make each sprint, each release, self contained and effectual. Always have a usable product and have each release add a new chunk of self-contained product to it.
Some teams get confused with this and assume that a massive project squeezed out like a sausage and crimped off in two week chunks is the same thing as a series of two-week projects. It’s not. Large projects will beget large amounts of change, they will beget discussions in meetings, changing requirements and constantly updated (and outdated) specs.
Truly small projects are self contained and work as-is without needing anything else that’s still in the pipeline. Small projects don’t even have stuff in the backlog. You write that when the time comes.
Stay away from a project’s Schwartzschild radius
If you keep chucking stuff at a planet it eventually turns into a star. If you keep chucking stuff at a star then it eventually gets so big that it collapses in on its own gravity and forms a black hole. A black hole is so called because nothing can move fast enough to escape its gravity. Not even light. The distance away from the black hole where this phenomenon begins (the edge of the black) is called the Schwartzschild radius.
Some projects have a Schwartzschild radius of their own. They are so big and so doomed that there’s a critical distance within which people and resources will never be seen again. Steer clear of these, they’re bad news and Accenture’s doomed multi-billion pound rewriting of the British, NHS computer system was one of them.
Conclusion: for faster, more pleasurable projects, stay small
Most teams think that they’re throttled by their engineering teams but in truth, engineering is seldom the bottleneck and the degree to which you can control engineering velocity is extremely limited.
Since you can’t do much about engineering and you don’t want to freeze features, the only way to speed up your project is to make it smaller. Not globally smaller but just divided into genuinely self-contained small digestible chunks. Tear up your backlog, keep an entirely separate wishlist and stay speedy.
(Disclaimer: the bit about Accenture may just have been an excuse to use the term Schwartzchild radius in a blog title).