One of my favorite aspects of Agile is that it is designed to deal with uncertainty by accepting that uncertainty. Given that what we often do is to take teams of people that have not worked together and ask them to build something they have not built before with tools or technologies that are unfamiliar, it’s not really surprising that all software schedules are inherently risky, but my experience with early stage companies has also taught me that often the market risk is actually more significant than the execution risk.
Anticipation is building as our team has reached the point where the product we are building is actually starting to do something interesting and useful. The rest of the team has been reasonably patient as we have adjusted scope and schedule a couple of times to try to get the functional footprint right and to adapt to changes in business tactics, positioning, and partnerships. But we have ridden through the worst of those bumps and I’m now confident that we can see our way through to a product that we can ship with reasonable predictability in both scope and schedule.
During the lead up to our first comprehensive scenario being demonstrated, it was fairly easy to keep the dreamers at bay. All product owners seem to share this trait – as soon as the team is hunkered down to productize what has been produced, they start to imagine what else they should try to squeeze in before the product ships. If there is a necessary role for “adult supervision” between product owner and scrummaster, this is it. We know from experience that minor scoping decisions come and go with regularity and are rarely if ever important in the long run, but nobody EVER forgets when you blow a ship date or go for long periods without shipping something.
So, despite all of the hard work left to do, we’re already starting to talk about what is next. ”We need a product roadmap! How soon can we start to form specific plans so that we can tell people what will be coming in V2 and V3 and when they will be ready?”
Sound familiar? It should – it happens everywhere and is very natural. However, there is something important to remember when you are finishing V1 of a new product: no matter what you think you know needs to be done next after V1 ships, you are wrong.
North Shore, MN
This simple fact actually led us to establish a rule around this – teams that were finishing a V1 project are not allowed to be assigned to other projects until after the first couple successful implementations of the product in the field. Why did we do this? Because we had too many situations where we would ship V1, assign people to other projects, then the product would get sold and we would start to get our first real information about what the market really wants. Lo and behold, the resources were gone, so now this information disrupts all of these other efforts and commitments as portions of the original team are reassembled to try to address the product deficiencies as rapidly as possible.
I think getting that V1 product market tested is THE most important thing a company can do, and using the development team to accelerate that deployment process makes more sense than anything else they could do with their time. As mentioned earlier, there is a very natural tendency to want to keep the team busy and maintain momentum by moving right into developing whatever features did not make the V1 cut, but if you do this you will almost certainly regret it. The real critical path to sales is widespread acceptance by the market, and while developers often will not admit it, there is always more they can do to make sure that the feature set that they have is well documented, well understood, and successfully applied.
While I’m also finding it tempting to start the look beyond V1, it was refreshing to have this conversation with my customer. They are worried about making sure that the feature set for V2 is carefully spec’d out months before V1 actually ships. Starting that process now will inevitably distract the technical team with questions that are out of scope for their current work, but more importantly it would start us down the slippery slope of thinking that once these additional ideas are understood, that it would make more sense to just postpone shipping V1 until they can be included. As Voltaire said, “The better is the enemy of the good.”
I’m convinced it is healthier for all involved to avoid having too much product backlog – I understand the value or roadmaps and of selling the future – every software company does that to some degree. However, the more you do it the more you mortgage that future on behalf of specific customers when the market might try to take you in other directions. It’s a delicate balance to maintain, but there is a real risk in making such commitments, especially during the development of V1. Direct that energy to commercializing and promoting what you are building in V1 instead and you will find there is less stress within the organization.
