Software development is like budget management, you have a finite resource (time) and a multitude of possible things to deliver during that time. Hopefully, you have a good prioritization process and all that is left is to make your best “guess” on what you will be able to deliver given the available time budget.
You don’t want to end up in a place where you underestimate the effort of every project and have a team that is working round the clock and always exhausted. At the same time, you don’t want to overestimate everything and later realize that the effort needed was way smaller, leaving your Engineering team bored to the bone. Teams tackle this differently, with Agile Estimations being one of the most popular and arguably the most controversial Agile concept, but ultimately what every team is looking for is to find that “sweet spot” where you are highly predictable as a team and still have enough space to be flexible when priorities change or unplanned work comes up.
In order to become predictable as a team, there are lots of tools out there that you can leverage that I won’t be talking about in this post, but I’ll be focusing on one of the toughest problems even the best software engineering teams face which is staying predictable in the face of extreme uncertainty. So how can you stay predictable and be confident in your ability to deliver complex projects on time?
One tool that I’ve found to be very effective in building that confidence and predictability is spiking!
What is a spike? A spike is an invention of Extreme Programming (XP) and is a time-boxed investigation to gain the knowledge necessary to reduce the risk of adopting a technical approach, better understand a feature, and increase the reliability of estimations. Scrum prescribes a way this could be achieved, but as I dislike shoehorning rules and processes, I always prefer to cherry pick and adapt processes and frameworks depending on the team I’m working with and I recommend you do the same. This has proven to be effective for me and I use this both for long running projects (6–12 months plus) and projects that run for only a few weeks.
The output of a spike is usually a technical design document outlining the key considerations, the findings and a recommendation on the preferred path forward. In most cases, this is accompanied by a working prototype of the technical solution depending on the problem space being explored. This artefact can then be circulated within the team and with relevant stakeholders to gather input and drive the final decision.
Once the spike iterations are done, it becomes clear what is achievable and how. This makes it easy to derive a delivery roadmap from the output of the spike and identify potential risks that could be mitigated before the project is well underway.
It’s important to note that every software project comes with it’s share of uncertainty and risk, it’s an intrinsic property of technology. Spending time trying to eliminate every uncertainty or risk is like getting on a hamster wheel, you will never see the end of that and if you do, boy you are onto some groundbreaking discovery!