Building a new system from scratch is hard. There is research and experimentation to do and hurdles that can blow apart the feedback loop you use to measure velocity and fuel progress toward your first release. This can be frustrating for project managers who want to convey progress, as well as developers who are trying to make stuff happen down on the ground.
In many cases, we just resign ourselves to the fact that initial progress will be slow, and we accept that things will just…take a while.
But what if we need to deliver a working prototype after, say, only three iterations? We won’t have any usable velocity data to hone our scope to meet this initial deadline, so we’ll have to suck it up and hold our nose to the grindstone, right? Or can we do better?
Identify Big Hitters
The first handful of features often involve large setup tasks that need to be conquered before we can say, “Hello world!” for the first time. Adding an application framework or creating a CI build are some of the tasks that may fall into this bucket.
Too frequently, teams try to hold stakeholders at bay by telling them that those first five points are “just going to take a while,” and they hope the stakeholders will be patient. But if proof is needed to keep higher-level management at bay (especially to secure funding for the remainder of the project), then it’s time come clean and sell the necessity of what you are adding to the project.
Identify Common Dependencies
To identify an initial MVP, your project lead or other stakeholders may want to shuffle the order of things or drop some features that are deemed unnecessary.
This can be problematic if you are weighting a particular task due to the extra work involved in the first time you touch a certain area of the application.
If the developers expand a feature X to include an extra chunk of work (we’ll call it K), but then feature X is eliminated, the effort/estimate for K is also gone. But what if feature Y is still in play, and it also requires K? It will end up taking the hit from the extra time associated with K.
You can avoid this problem by tracking and identifying all common work properly. That way, when things are shuffled around, you don’t lose any effort you invested in your original work order.
Use Spikes for Education and Buying Down Risk
The start of a project may involve some big decisions such as deciding between different web frameworks. While you can read up on them until the cows come home, taking some time to get a real taste of each of them before making a call is a better approach than, “We’ll make a decision a month from now, after we stew over it.”
When you’re in a time crunch, a key to making spikes worthwhile is to allocate a number of days to each spike and dive all the way in. The goal is not to tread lightly, but to immerse yourself in making something out of the pile of stuff in front of you.
Make sure you know what you need to get out of the spike, including what you are quantifying across the different options you are considering. Ending up with good data and something you can present to others is crucial to building their trust for the remainder of the project.
Account for Risks Remaining
In the end, there is always risk going forward. If the unknowns cannot be quantified, make sure your stakeholders understand how much variance a given risk or risks may present to the project. You may want to schedule some more spikes down the road to further educate yourself and the stakeholders so you can reduce risks and plot a solid plan forward.
All of these issues can be conquered by being honest about risks and deciding upfront how to mitigate and/or accept them as a team. We are all in this together, and getting on the same page about challenges can decrease stress, increase creativity, and create a realistic and successful path forward for your team.