Experimentation is the key to learning and continuous learning is the core of Agile and iterative methods.  A wise man once told me that we know the least about our product and the optimum process to build that product when we first start. I could never (or never wanted to) argue that point. When we are at crossroads facing an unknown path, experimentation lets us understand which avenue is best. 

Experimentation means to find that path wisely. Don’t get into analysis paralysis. Here are some suggestions to make your experiments a success:

1. Make your experiments iterative so that the lessons from the initial ones can be used to plan and create the next ones. 
2. Make your experiments short and tactical so that you can learn quickly about what works, and more importantly, what doesn’t work. 
3. Finally, and most crucially, an experiment that fails is just as important as one that succeeds.  The answer will guide you on how to proceed from that point. Don’t be tempted to think that a set of experiments that ‘fail’ aren’t a success. The experiments simply yielded an answer. 

If you have more suggestions on how to conduct a good experiment in your environment, feel free to post them in the comments. In addition, if you’ve learned something that changed the way you work through experimentation, please share it with us.

All projects have at least one thing in common at inception: uncertainty. This may be uncertainty over how best to use a new technology, how to design a new feature, how to learn a new development language or even how to create a new process that will work better for us. Throughout planning, we may be able to identify many of these points of uncertainty but one thing is for certain: these points of uncertainty are some of the main causes of risk within a product development life-cycle.   

The best way to mitigate risk is to take uncertainty out of play. However, the way this is accomplished may mean the difference between a successful project or a gigantic failure. When faced with uncertainty, it is incredibly easy and tempting to fall back to the traditional methods of dealing with that uncertainty:

1.  Make unfounded assumptions and forge ahead confidently, never looking back.

2.   Deny the uncertainty and forge ahead confidently, never looking back.

3.  Brow beat your developers until they say they have a solution (which is all you need to hear as a Manager) and forge ahead confidently, never looking back.

Please comment if any of these methods ever consistently worked for anyone. I’d love to hear from you. 

These methods all center around getting some plan down on paper after some small initial discussions, set it in stone and forge ahead assuming nothing will change. This path is almost certainly ineffective because we have not understood the problem and have no strategy to find the answers to those uncertainties. Why do we do this? Haven’t we learned from the past? Unfortunately, learning from past experiences would mean going against  certain aspects of many organizations’ development culture and uttering the three most appalling, dreadful and hideous words that a developer can say: “I don’t know.” 

We as developers have a stigma around those words. In some organizational cultures, they are taken as a sign of intellectual weakness among peers. In others, it is an expectation from the management that if you are a subject-matter expert, you know what you need to.  The fear for most is hearing those three words thrown back in your face at the dreaded performance review.   If you have other reasons, please let me know.

The truth is that some of the smartest developers I know, the ones I most respect, often say those words and say it proudly. In a true Agile culture, it is not only OK to say those words, it is expected.  It is a sign of greater intelligence. Better to establish we don’t understand the right path than pull something out of thin air (or some other, more undesirable place – use your imagination), even if you are almost certain to be wrong, just so you can appease your peers or manager.

With that said, simply stating “I don’t know” isn’t good enough. It should be followed by “Let’s conduct an experiment.” An experiment in its simplest form is the process of answering a question. “Is design A better than design B?” “Should we build it or buy it?” “Should we use this form of visual management over our previous one?” Whatever needs to be done to answer your question will be your experiment.  It does not have to be long, complicated or over-analyzed. It just has to be enough to either get you to an answer or to unveil the next step toward the answer.

The only way to mitigate or eliminate risks is through gaining knowledge. One of the best ways to gain knowledge is through experimentation. An experiment is simply a way to an answer to our unknowns. Those answers could mean the difference between project success and failure.

I would love to hear more on and discuss more about experiments you have conducted to overcome uncertainty. Please feel free to post in the comments.