Embracing Wrongness with Acceptable Uncertainty

Plans are useless, but planning is indispensable.

– Dwight D. Eisenhower

Fuzzy Road Map?

One of our favorite principles for Agile software management is Acceptable Uncertainty. It takes a couple of hours to describe completely, but here are the parts we like best:

  • We don’t have to fully define something until we are closer to building it – long-term road maps are useful, but they are also wrong five minutes after you release them. What works better is a ‘fuzzy road map’ where items that are a long way off are very loose.
  • We don’t know all the answers. We build and we measure the results. We sometimes build multiple competing concepts and test to find the best ideas.
  • We collect and compare information where it is available, and speak with stakeholders and customers to make informed decisions.
  • We take action quickly and refine as we go instead of waiting to master a problem before we move.
  • We are willing to fail and to throw away work to get to a better answer.

It turns out you can waste a lot of effort building big, fully-detailed requirements and project plans; with a complex system waterfall planning is more like a specialized form of fantasy. Some decisions that should be late-breaking are forced too early with detailed up-front planning, and you end up missing deadlines because of hidden and unplanned-for complexities.

 

Free Your Teams

Admitting you don’t know all the answers relieves a lot of pent-up pressure with high-performing developers and managers that hate being wrong. It gives them permission to try things and make adjustments instead of committing to a guess.

But this isn’t a free pass to just ‘wing it’. You still need to plan, you still need to have goals, and you still need to be critical about whether you are making progress on your goals. You have to test and do all the other things you need to build reliable products. With acceptable uncertainty you give smart people the ability to legitimately put off making decisions that they know will likely change – instead it becomes OK to just put something in as a sketch, as a placeholder, and then go back and reevaluate when the work is closer and you know more. The closer you are to building that feature, the more detailed it becomes. Iterating the planning on a feature allows people to think more deeply about a problem before they have to build it, and that’s better too.

Acceptable uncertainty gives teams the flexibility to reverse course or just tweak their direction as new information, or competitive reality, intrudes.

 

 

Listening to CustomersSend-up-feedback

We have to make a lot of assumptions when we build software. We decide between hundreds of small alternative behaviors while putting something out there for the public to see. We don’t assume we’re 100% right about all those decisions. We concede that sometimes we’re going to fail at the design level, so we user-test with real people, and we try out new features ahead of time on ourselves. We also have a built-in feedback mechanism for customers to let us know when we made the wrong choice.

We take feedback we receive very seriously, and because of our continuous delivery model, we can quickly respond and push changes.

 

 

 

Interactive Intelligence PureCloudSM is our latest microservice-based customer engagement cloud platform, a subscription-based scalable system that also helps the rest of your business stay in touch through a rich corporate directory, ‘big data’ search, ad hoc and rules-based groups, chat, video chat, and document sharing features.

Randolph Carter

Randolph Carter

An industrial designer gone bad from years of UX architecture wrangling, Randy Carter is senior marketing content architect for Interactive Intelligence. He never stops thinking about how to help customers make their systems more understandable, more polite, and more useful.