Experiment to prevent rigor corpus - part 2 of 4
These five steps get you ready to start the experiment cycle. This is only done once with a team, although anything decided here can be adjusted as needed.
This is a series of four related posts:
- part one introduces the experiment
- part two shows 5 steps to implement
- part three discusses challenges
- part four illustrates the documentation
Step one: Talk with those who would be participating. Describe the process and the end goal with them. They need to commit to participating in this process. Your efforts will be hobbled if you cannot get a buy in. You can proceed on your own and attempt to make change. Without everyone bought in, implementing change is harder. It is also much better to have sounding boards for your ideas.
Step two: Talk with your boss. We need our leaders to be comfortable with us making change without them. We do not want to have to seek approval. That slows things down and brings in the component of “what will our boss approve”… which has its own emotional truck load of assumptions and beliefs. Some bosses are control freaks. They demand to approve every change. The reasons for this may be justified, but in many cases it can be that they simply do not think those under them will think everything through enough. And this happens. But it is not due to underlings being dumb, they do not have the same vantage point or experience as the manager.
Step three: Work with your boss and your team to establish guard rails for change. You agree up front on what is okay and not okay to modify. With one team my agreement was: “you can modify anything that is internal to the team, if it crosses into another department or how they interact please include me.” For those that read my post on Fear, this was not about that. This check-in was about the vantage point. I had fostered enough trust with my team that it was a discussion and not an approval.
Step four: Establish the cadence. Set aside recurring time to talk about experiments. This can be at whatever interval makes sense as the balance will be unique to you. The more frequently you meet, the less chance of needing an emergency meeting but the more time that may be wasted. If you go too far between, you may forget to talk about things that have come up, or fail to make adjustments to an experiment soon enough. This can be part of an existing meeting (like an agile retrospective) if you are disciplined enough to time box within that meeting.
Step five: Brainstorm a list of potential pain points. This gives you a pile to work through over time. You will add to it over time. This also primes the machine, so to speak, to start the cycle.
The experiment cycle
At each interval, you will run through these steps.
Step one: Review any in-flight experiments. Follow the process to expand, continue, or halt depending on the circumstances.
If you want to add an experiment, continue with the following steps.
Step two: Choose a pain point or need from the list that the team agrees will give the most benefit and is possible to solve.
Step three: Brainstorm changes that can fix the problem. Remember to start small. It is much easier to measure impact if you only change one aspect at a time. Smaller changes are also smaller risk.
Step four: Document out the change using the experiment document. This will cover the what, how, and who aspects of a change.
Repeat.
How to review an experiment (good or bad)
Always have the experiment document in front of you. This is a living document over the cycle. Take notes, make adjustments, etc. This is for you.
Careful here. There is a tricky mindset that creeps in that most experiments should go great and if they don’t there is an issue. Since you know your environment and the work, it should be rare one ends in disaster. The key thing to remember is that you are making a change and observing the results. You should have a sense of curiosity not fear.
I recommend following the retrospective approach to this:
Discuss aspects that are going well, including any unexpected side effects. Note if any can expand further as they seem to be going in the right direction. Major expansions should be rare and often their own experiment after.
Discuss aspects that are going badly, including any unexpected side effects. Talk about deploying countermeasures to reduce the pain.
Discuss any other changes the experiment has fostered. These may be neutral, but collecting data is what this is all about.
With the above in hand, review the experiment plan. Decide if you should continue or stop the experiment at this point. If you are going to continue, plan any alterations and add them to the document. It is your responsibility to stop the experiment if it is unlikely to succeed. It is better to stop and rethink the approach than to keep a change on life support.
The inevitable failed experiment
This happens. I have found that in the majority of failed cases an experiment results in little change and not a large negative impact. When you decided to shutdown an active experiment there are only a few things to do.
Capture lessons learned, good and bad. Add them to the document for future reference.
Discuss if iteration is possible. Can you salvage the learnings from this experiment into a new design? If so, record that and discuss it at the next meeting.
Clean up. Depending on the nature of the change, you could have work sitting in a now-defunct work flow. You will need to conclude or migrate this work before walking away.
Don’t feel bad. You tried to make things better. This time it did not work out… that is to be expected. Focus on what you learned.
The celebrated successful experiment
Well okay! You have an experiment that made things better for you and those around you. You should be pleased, but not overly so. The satisfaction should come from what you have learned.
Discuss and record what you learned. Update the document.
Determine if you want to implement this as a permanent change or not. In some cases, you may have just wanted to learn something. In other cases you may want to introduce this as part of a larger initiative.
If you are moving forward, someone needs to brief the boss. A temporary experiment is one thing, a permanent change should be communicated.
Clean up. Depending on the nature of the change and how you move forward, you could have work sitting in a now-defunct work flow. You will need to conclude or migrate this work..
Promote the success. It never hurts to show people that you are doing good things in a unique way.
In the final installment I will propose a document structure and provide some examples.
