One of the most important concepts within agility is about running experiments. According to the dictionary an experiment is a scientific procedure undertaken to make a discovery, test a hypothesis, or demonstrate a known fact. An experiment is a wonderful thing, since it is focussed to outcomes (learnings). The worst thing that can happen, is that your experiment did not lead to your expected outcomes, so you actually learnt what is not working (in that particular context, at that particular time). And many agilists love experiments specifically for making a discovery, since you are certainly going to learn something new there.
So we are done for today’s post. Just do experiments. Period.
However…
Throughout many agile engagements I discovered that there are typically two drawbacks to consider, that could withhold you from you (or your target group) to really learn something. In this post I will address these, so you can use them next time to experiment within your experiments (pun intended). The first is about feeling safe to really experiment and the second is about abusing an experiment to push forward a way of working or an opinion.
Before we do that, let’s first have a look into the wonderful value an experiment can bring to us, so we know where we want to be if we are running experiments. Experiments within the agile space are mostly used to make a discovery (since we know that we don’t know) or to test a hypothesis (since we are not sure). In all cases it is helpful to clearly define what you are looking for, so you can check out at the end if your experiment has lead to the expected outcome or not. With all of that you get the wonderful bonus of having learnt something for free. And that touches one of our intrinsic motivators: mastery. So you will end up with at least some positive feelings.
What about feeling safe to experiment then? I have been in many companies where a strong focus on output exists, with the believe that more output implies more profit, implies more bonus. And to survive as a company you need to be more effective and/or efficient than your competitors. Since these elements are more strongly addressed within agile contexts, many companies have chosen to implement something in that direction or at least relabelled things to look agile. And it may sound too obvious to say that just changing labels does not automatically change the recipe and thus the taste (output). If within your environment a strong focus on output exists, often supported by a good old (directive) management style, people do not feel safe to run experiments. You can easily discover that by used wording like “we don’t have time for that”, or “we need to check with X, Y first” if an experiment is proposed.
In that case it is needed to challenge this underlying problem first, so people can really feel free to experiment and learn. And those learnings will lead to becoming better. Funny enough the latter will most likely lead to creating more profit as well, since if you use your learnings to stop doing things that are not supportive and start doing new things that are supportive, it helps a company to thrive. You need however to invest first (time), though on the long run it is typically better.
A second thing that happens quite often, is calling pushing your opinion an experiment. That happens within the agile community a lot, since we are firm believers that our opinions are always right (don’t we?!). And if you are shaping your opinion as an experiment, it is actually not an experiment. So where an experiment can be used to “demonstrate a known fact” (see the definition), it can certainly not be used to demonstrate your opinion. The complex world we are living and working in, is defined by the fact that we actually don’t know everything, so we should be prepared for the unknowns. And if you sell your knowledge about the subject matter as being the one and only truth, next packaging it into an experiment to convince others to try it out, you are still selling your opinion. This behaviour can be easily discovered by telling about something new (a framework, a method, a practise), immediately followed by a sentence like “Let’s run an experiment about this”.
Of course there is always a thin line between being a teacher, being a mentor or just being a coach. And of course, it is quite valuable to share your opinion about agile topics. I would however say: just try not to sell it as an experiment if you are not really want to get people who need to run the experiment on board first. So checking that out by e.g. “How would you feel if we would try X or Y out?” is a good step forward. I have noticed that if you do not ensure that the experiment is really owned by ones that need to run it, there is a big chance that they will do whatever you have asked once, and next forget about it.
Your subject matter actionable knowledge can be valuable as well, as long as you don’t call them experiments and you are really aware of the fact that they may be less effective.
How do you evaluate the effectiveness of your experiments?
Did you ever run into a comparable situation? And you want to exchange? Just explore a bit through my website and just contact me.
Previous post: Agility and frameworks
