Inertia Is Bad: How to Generate Momentum in Your Agile Program
In a large program, you know how hard it can be to get things moving. Not everyone has access to the same tools, you can’t find a time to meet, what works in this location doesn’t work in another—even if that other location is just on a different floor, not across the world. Inertia is not your friend.
To prevent inertia in your agile program, here is a little trick to gain momentum and help people discover the value of the small-world network. This also works if you have too many people on your program, and you need something for them all to do.
Ask everyone to start an iteration with one objective: to learn how to work together. They should learn what done means for the program, how to ask questions of each other, if the iteration duration is the right length—and whatever else they need.
At the end of the iteration, with any luck, you will have some features complete, an updated picture of the architecture, and some questions answered. You will have started to build a little momentum, and you will have bought yourself some knowledge. And if you have an already existing product, maybe you will have paid off a little technical debt.
Even if you don’t have anything done, you will have learned why. You and the entire program can spend the next iteration fixing those impediments. Now, isn’t that a better use of your time than a "sprint zero" where you don’t deliver features?
I am opposed to a formal sprint zero in a program. It increases inertia and decreases momentum. Do you need to write stories? Fine, allocate time in the first two-week iteration and write stories. Timebox your story-writing to no more than four hours—any more time and Parkinson’s Law goes into effect.
Your iterations shouldn't be longer than two weeks because you have all these teams, and your run rate is high. You may think you need more time because you need to determine the architecture, but you can't possibly determine the architecture in advance on a large program and be correct. You need to be agile and lean, implement features, get some feedback, and learn.
The larger your product, the less work in progress you must have. Otherwise, your cumulative flow is off the charts and you have no idea if you can ever release. There is no reason your program cannot release every two weeks unless you create technical debt.
Releasing every two weeks will help you create momentum, obtain feedback, and make sure your program is not going off the rails. It’s a terrific risk management tool.
