Fostering change using experiments over opinions
Change is important. Change is what keeps us motivated, helps us solve problems, makes us realise we messed up horribly (change back!) and generally makes for an exiting environment. There are a lot of things holding back change however. First of all, everyone has an opinion. On everything. Discussions on how to change generally cripple any actual progress.
Secondly changes are often made a very big deal. Big changes are uncomfortable. Big changes make people work against you or the idea regardless of it being progress or not. So what we need is small changes. Continuously. Sounds almost agile :)
Experiments!
During a talk we saw (probably at PHPBenelux 2015) Mathias Verraes enlightend us on the value of experiments over opinions. Mathias writes about this in detail here. These experiments sound like a very good match to the observations above.
At procurios our scrum teams fairly quickly saw the stroke of genius in this simple yet effective idea. Teams started ending their retrospective with an attempt to define small controlled and cheap experiments to improve on one or more challenges that resulted from said retrospectives. It didn't take long for the research and development team to follow suit. Currently even organisation wide adaptation is a fact and we have several organisation-wide experiment running (and already dropped/graduated).
Rules
These are the (more important) rules as we use in my team. But most teams have a very similar set of rules.
- An experiment must have a clear goal
- An experiment must be specific. We should determine *what* we will do to get to our goal
- Each experiment that has not yet graduated to common practice is evaluated each retrospective
- Everyone may veto any experiment. One single person can stop an experiment.
- Costs of experiments, be it in time, money, effort, etc. must be very small.
- Experiments must be visible. This helps us remind ourselves.
All in all this works pretty well. We've really adopted a "let's not talk about this anymore, let's just try X" mentality. The set of rules is particularly nice because it helps on-boarding people who initially are more inclined to explain why our idea won't work. It will not take them much effort and they can veto the hell out of it if need may be. This tends to make sure even the most sceptical at least try.
The experiment board of our team. The low amount of failed experiments suggest we're not active enough yet :)
An example - Kanban principles on our scrum board
We noticed that our team is very good in producing and developing but that we lacked in the testing part. We were also not really helping our product owner accept stories. We do this obviously, but late in a sprint and not often enough. After the doing column our board features a merge column (literally, a merge request is present in gitlab), a testing team column (developer X made something so Y, Z and A test it), a testing customer column, an accepted and a live column.
As an (for now very succesful) experiment we limit merge, testing internally and testing customer to 1 active item. The accepted column has a WIP-limit of 3. That means that each time someone finishes a task it is very likely the only thing one is allowed to do next is push a task down the line into accepted. This works very synergetic with the fact that no one is allowed to test his/her own work.
Results are great. Last sprint we had exactly half of our weekly velocity tested, accepted and live in the customers implementation by wednesday (we do 1 week sprint, you do the math :D ). In the old situation we would often go from 0 to 100 on friday (or the monday thereafter).
This is just one example, but we tackle each challenge with the same system and it helps us a lot. Do you experiment at your own company? Did it help you and what are the best results?
After about 10 years of professional development at both