I bet right now, if you thought about it, you could come up with some change that would be great for your team or your project. And I bet you’ve been ignoring it because “it’ll never fly” or “management won’t go for it” or “people will think it’s crazy.” And they probably will think it’s crazy, if you suggest it as a “change”.
But you can convince your team to let you try anything if you pitch it as an experiment.
The crucial ingredients are:
- It needs a defined start and end date
- It needs to be measurable
- It needs clear success and failure criteria
Let’s take an example. Yesterday I posted about Fred, who only cares about providing value to other developers instead of users. My suggested solution was to lean into that and make that his full time role. What I didn’t say was that if you suggested changing Fred’s role, you’d freak people out. You’d get a lot of “uh, you want someone to work full time on stuff that our users don’t care about?”, etc. You know the drill.
So how about an experiment? Suggest letting Fred fill that role for only only a single sprint, and see how it affects velocity. More specifically:
- Hypothesis: moving Fred into this role will not lower velocity
- Start date: start of sprint
- End date: end of sprint
- KPI: team velocity compared to the average
- Success: velocity increases or stays the same
- Failure: velocity decreases
(This isn’t an ideal experiment because lots of other things can affect velocity for a single sprint. But it’s enough to get your foot in the door with convincing people the idea isn’t crazy.)
Most teams and managers will be drastically more willing to accept that. The best case scenario is that it makes the team more valuable indefinitely. The worst case scenario is that you’ve only lost a bit of velocity for a single sprint.
Changes are scary. They bring anxiety and regret. Experiments are comforting. They bring clarity. You can’t fail at an experiment, because the goal is to learn. As long as you learn, then the experiment is a success.
It doesn’t matter what you’re talking about. Process changes, technology changes, role changes, product direction changes, all of ’em. Next time you’re in a retro meeting and you want to suggest a change but you’re worried about getting shut down, call it an experiment. Lay out how it will be measured and when it will end. Then observe as your team magically agrees to give it a shot.
And if you do, tweet at me!
Mike Crittenden 