How to Iterate Faster
Practical advice, both Strategic and Tactical
Strategy I: Focus on the Target
It’s easy to go fishing at the beginning of the project when the potential for unreallistic optimism is still high. Rather that aiming for constant velocity, a well-performing team makes the choice of sticking to their ruthless ability to cut cruft from their scope and only pursue one goal at a time.
Sprints are called sprints for a reason. It is the effort of an entire moving in towards the same goal.
Ever hosted an off-site? You put everyone in the same bus, on the same plane and host them in the same hotel to attend the same conference halls for the same meetings.
Sprints are exactly the same. You want everyone moving in the same direction aiming at the same target. 1000 different ways to achieve one goal rather than 10 people trying to deliver 100 tasks each. That is the heart of agile.
Now don’t get me wrong, I don’t advocate sprints. In fact, I would suggest you get rid of them. Failing that, my recommendation is to make them as short as possible, ideally 2.5 days. Don’t fall into the trap of thinking a sprint is a repeatable unit of meetings and deliverables. Sprints are about unknowns.
There will be chaos and re-negotiation. Prepare for it. Plan for it.
Strategy II: Your initial plan is Wrong
At the eye of a hurricane one may come to the conclusion that everything is calm and that it will always remain calm. Regardless of how good your initial plan at Day 1 is, compared to the final outcome of the project it is the worst possible choice of all alternatives that you will gain access to during the lifecycle of a project.
Having a plan is useful, but relying on the initial plan gives a false sense of confidence. The key is re-planning and having the courage to call out doing drastic changes to the plan.
This will involve meetings with stakeholders who need to be updated on your course-correction for any commitment you have made towards them. This can be stressful. But this will happen one way or another - at the time of need you have the choice whether that happens sooner rather than later (after the deadline).
Tactics I: Static is simple. Static is fast.
Avoid having a default stack. Node and Mysql? .NET and SQL Server? Chances are your default project setups drags in 30-100 modules and the neighbour’s mother-in-law’s kitchen sink. This will produce so much cruft in your project setup and migrations that you may end up wasting your most precious resource: Week 1.
Spend your first week deploying static artefacts, setting up your CI/CD pipeline. CI/CD nowadays is a few clicks on most Git providers. If you have wireframes and ideas, get them out in a static form, purchase the domain and test with real users. Don’t waste time over-perfecting a skeleton you’ll need 3-4 weeks down the line.
If you encounter project-critical news, you want to get rid of all assumptions as quickly as possible when the feature is in early stages.
“Remove the temptation of speculative abstractions early in the project.”
Tactics II: Question your stack-assumptions
You may start with a SQL database. Or worse - a containerised unmanaged SQL database. Unless you’re a well-established enterprise with strict provisioning governance, any needless infrastructure decisions will slow you down needlessly.
As long as you have 1 compute server (ie. your app/api server) and 1 database, you can host everything you may need on a single node with a local on-disk SQLite database.
For write-heavy operations you can offload responsibilities to workers and redis.
The difference in practical velocity is enormous and the ease of use, including developer experience non-trivially significant. Stay lean for as long as possible.
Allow the possibility of you throwing everything away of your releases don’t meet value criteria. If they do - it will be a small refactor. Above all else, remove the temptation of speculative abstractions early in the project.