Sharing Risk With The Team

Many of the teams out there are building stuff that has never really been built before. They are using technologies that are unfamiliar to them. They are working on code bases they didn’t originally create and dealing with customers that don’t really know what they want.

Agile can be a great approach for dealing with this kind of uncertainty. Agile methods encourage you to build a little bit of the solution, to learn incrementally what it will take to build the emerging product, and to get continuous feedback from your customers along the way.

The challenge is that most customers want some idea of what they are going to get for their money. Even in cases where they aren’t sure what they want, and even in cases where the team doesn’t really know how to build it, they want some assurance they are going to get something useful.

Agile teams try to use relative estimation, measure velocity iteration over iteration, get good at making and meeting two week commitments, and hopefully get predictable over time.  The idea is that the team will build trust with the customer and deliver the highest value features possible.

But what happens if you just have no idea of what it is going to take to build the product?  What happens if velocity never stabilizes?

What if you are working in an entirely new problem domain with a bunch of new technology. What if you’re working on a legacy product that is full of technical debt where everything you build seems to have some unintended consequence you have to deal with?  What if you just can’t make and meet a commitment?  How do you even begin to get traction?

Here is my assertion…

If you are in a situation where requirements are unstable… and the underlying technologies are unstable… just accept that there is no way you’re going to be able to run a predictable project. It doesn’t matter if you use traditional methods or agile methods… acknowledge that you have no idea what it is really going to take to build the product.

So what are you going to do? Failure is not an option… doing nothing is not an option… but hope is not really an option either. Let me give you a few things to noodle on when dealing with situations with profound uncertainty…

From a team perspective… you have to intentionally design and run experiments intended to de-risk the project as fast as possible. Until you come to some sort of agreement about how you are going to build the product… until you actually discover HOW you are going build the product… time and cost estimates are a crap shoot at best.  Even relative estimation is meaningless.

From a customer perspective… you have to recognize that you are investing your money in a very risky endeavor.  You are basically entering into a place where you know what you really want, and the team you have to do the work doesn’t really know what it is going to take to get the job done.  You are betting that the team can deliver something that you’ll be able to use, with no assurance they actually can.

To mitigate this delivery risk, customers tend to ask for fixed time, fixed cost, and fixed scope projects. Even though they likely won’t get what they want when they need it, it will be someone else’s fault.  Developers, on the other hand tend to want to shift the risk to the customer by asking for a time and materials agreement… one where they deliver the most value possible given the time and money the customer is willing to spend.

Neither approach is a very effective strategy for running a predictable agile project, and in the end… no one get’s what they need to be successful. I believe that the ultimate answer lies in being able to acknowledge the situation we find ourselves in and acknowledge that we just don’t know what it’s going to take the solve the problem… we have to acknowledge that shifting the risk to the other party doesn’t really help.

In the end, our mindset had to change. We have to learn how to share the risk.

It starts with a willingness to invest in smaller increments, to make smaller bets.  We have to be willing to invest in discovery… to be willing to invest in a set of experiments with the return being nothing more than a learning outcome. If you’ve learned what you need to learn… agree to make the next investment increment. If you haven’t, either make the decision to go forward anyway or kill the project.

At the end of the day… it’s really about accepting reality and dealing with it.  We don’t know and no amount of up front discovery is really going to help us know.  Rather than pretend, constrain the investment and work to narrow the cone of uncertainty to the point where you’re willing to make the bigger investment.  If you don’t know… and you can’t find out… stop pouring good money after bad.