Posted by marty cagan on December 15, 2012

The past several articles have discussed the nature of Continuous Discovery and Dual-Track Agile. In this article I’d like to discuss another dimension of working effectively in an Agile environment, which is how we manage commitments.

In most Agile teams, when you mention commitments (like knowing what you’re going to launch and when it will happen), you get reactions ranging from squirming to denial.

It’s a constant struggle between those executives and stakeholders that are trying to run the business (with hiring plans, marketing program spend, partnerships and contracts depending on specific dates and deliverables) and the product team that is understandably reluctant to commit to dates and deliverables when they don’t yet understand what they need to deliver, and if it will actually work in terms of delivering the necessary business results, in addition to not knowing how much it will really cost because they don’t yet know the solution.

Underlying all of this is the hard-learned lessons of product teams that many of the ideas won’t actually work as we hope, and those that could work will typically take several iterations to get to the point where they move the needle enough to be considered a business success.

While in an custom software environment you might just be able to iterate until “the business” is satisfied with the software (or they just give up on it), in a product company, this won’t fly.

Now don’t get me wrong, many people have heard me rail against the perils of stakeholder-driven roadmaps. The recent article on The Opportunity Backlog was just the latest focusing on this problem. Good product companies minimize these commitments. But there are always some real commitments that need to be made in order to effectively run a company.

So what to do?

The key is to understand that the root cause of all this grief about commitments is when these commitments are made. They are made too early. They are made before we know if we can actually deliver on this obligation, and even more important, if what we deliver will actually solve the problem for the customer.

I’ve written earlier about this situation (see www.svpg.com/your-business-plan-is-wrong). In a Dual-Track Agile environment, the Discovery Track is all about answering these questions before we spend the time and money to build production quality products.

So the way we manage commitments is with a little bit of give and take. We ask the executives and our other stakeholders to give us a little time in product discovery to investigate the necessary solution, and validate that solution with customers to ensure it has the necessary value and usability, with engineers to ensure its feasibility, and with our stakeholders to ensure it is viable for our business (they can support this solution).

Once we have come up with a solution that works for our business, we now can make an informed and high-confidence statement about when we could deliver this and what type of business results we can expect. We can also decide if it’s even worth doing.

Note that our project managers are essential to actually coming up with any commitment dates. Remember that just because your engineers believe something might take only two sprints to deliver, what if that team is already occupied on other work, and they can’t start on this work for another month? The project managers track these commitments and dependencies.

So the compromise is simple. The product team asks for a little time to do product discovery before commitments are made, and then after discovery we are willing to commit to dates and deliverables so our colleagues can effectively do their jobs as well.