Reflecting upon a project (still ongoing) that I did with ATeam last year, I realized a few things that I, as owner of the backlog, could have done towards a better result. The project’s been delayed quite a bit and while it’s owing mostly to almost the entire team working on it part time, I’ve had time to think about that one thing I could have done on my end to reduce the impact.
We started off the project pretty well. In fact, I’m quite proud that of all the providers our client had worked with prior to us, we’re actually the first that’s gotten to the point of enough usability to be at least partially deployed on their storefront.
Handling risk early
We managed to achieve what we have by addressing the riskiest parts early. Imagine having to cross a range of mountains but having the power to arrange them whichever way you want. If you’re smart, you’ll move the tallest one first, just to make sure you can do it. The rest should then be reasonably easier.
Through several discussions with the client, I surmised that the primary roadblock they encountered with a previous developer was a pretty fundamental one – getting all their current data from their Excel sheets into the new system. The provider wanted them to input the data into the program one by one. It was just too much work. What they needed, obviously, was an easy import tool.
Additionally, one big worry they had and were very vocal about was calculating prices, which was quite complex in this particular business. It was so complex, in fact, that I had to accept the project without fully understanding how all of the pricing worked. I clocked it up as a risk and pushed on.
So, being in my view the biggest potential reasons for the project to fail, I put both of these at the top of the backlog and went to work on them with the team at the very beginning, clarifying the details I didn’t fully get as we went along. And it worked. It took a couple more sprints than I expected to get both to a point of working decently well, but it did happen. And from that point on, it seemed like a clear path towards a successful project.
Losing sight of the prize
Eventually, the product backlog evolved, as product backlogs often do, and that really shouldn’t have been a problem with the agile process we were using. But once those two riskiest things seemed to be resolved, we started losing sight of the prize. Maybe it was laziness, perhaps the “high” that things were actually “getting done”, or simply fear of failing before we even got close. Whatever it was, we started to lean towards short-term wins over the long-term completion.
Sure, the mid-project sprints were being (almost) met. But our velocity started looking like this:
I now realize that after those first two major risks, we stopped chopping down on other uncertain areas. When a task in the backlog seemed difficult, we put it off to the next sprint and went with something else that could be more easily done. A task is a task, after all. Or so we thought.
What essentially happened is we ended up with this whole clump of uncertainty towards the latter part of the project – to the point where it’s gotten really hard to see how close we are to the finish line.
Fortunately, the situation we’ve found ourselves in is not as dire. All the uncertain (and perhaps impossible) things we’re facing either have a workaround, aren’t as important, or simply take a bit of time to resolve. It’s not hard to imagine how much worse it could have been though. If a key feature doesn’t work due to a minor yet impossible detail, that could have been the end of the road.
The trap of “agile”?
It’s easy to fall into this trap when working with agile. Some might even say it’s an intrinsic pitfall of the model. But the opposite is true. In fact, I believe an important part of being agile is being able to foresee a sufficient amount of the future to be able to realistically shape your next steps.
While agile does encourage small wins, it’s also about reducing risks – even those that might be some ways out in the roadmap. “Shaping up” means chipping away at uncertainty. One of the things I ask the teams I manage to take note of is the velocity trend within a particular release cycle. Velocity going down over a period of time is often an indicator that risks are piling up instead of being reduced. I, personally, would love to see a lot of spillover in early sprints as that’s a sign that we’re taking on the uncertain things first.
It’s easy to fall in love with progress – even the artificial kind. If you’re a scrum master, you might do well to value this, as the burndown chart is pretty much your most important compass. If you’re burning down your sprint fast, you’re probably doing well.
A product owner, on the other hand, needs to think differently. If something looks iffy in the the backlog, you need to move those up. The team might protest and you should hear them out. In the end though, if you don’t want the difficult parts to kill your project right at the finish line, you need to figure them out early, no matter how uncomfortable that might be.
The question is not just whether you fail or not – but would you rather fail early before you’ve done a lot of work, or at the end when there’s no turning back?
Speaking of ATeam, we’ve just recently launched our Facebook page. If you’re interested in updates on what we’ve been developing, go ahead and like us on Facebook to get our updates on your feed!
Dexter is an engineering manager at Synacy, a co-founder of ATeam Business Software Solutions, and founder of TechManagement.Life. He loves to share his experiences and thoughts on managing software teams and running businesses.
2 thoughts on “Deal With The Riskiest Parts First”