How Fast Can You Go (Safely)?
As technologists, our main goal is to produce the highest quality software in the shortest amount of time.
And a concept that I’ve started using is to describe velocity in terms of safety.
There is such a thing as moving too fast in the software and testing world. When we do this, we sacrifice quality, we put the product or the company face at risk, and we have a chance of burning out team members.
All of these can be avoided if we consider the Maximum Safe Speed.
What’s a Maximum Safe Speed?
Maximum Safe Speed (MSS) is how fast you can go at producing software, while still maintaining a high bar of quality.
It’s not really a number though, it’s actually more of a concept. And the focus is actually less on the speed, and more on whatever it is that’s slowing you down.
Instead of thinking of speed in terms of “what’s my velocity?” or “how many stories are we doing per sprint?”, think of it like, “what’s slowing me down?” or “what can I do to speed up?”
To explain this a little better, I’ll use the analogy of driving a car. A car has an MSS.
On a straight, open road with no wind and clear weather, new tires, no cops and a well maintained car, you can probably go as fast as you want. Your MSS is probably a lot faster than you’d even want to go in this case.
But if we start introducing variables, then we can get slowed down.
Is it windy outside? If it is, and you go fast enough, you might cause lift in your car and start losing contact with the pavement. You can quite literally get blown off the road if you go fast enough. So you’ll need to slow down–your MSS is lower because of the wind.
Is it raining outside? Water on the road decreases traction. In order to continue safely, you have to slow down even more to meet the MSS due to the rain.
Are your tires bald? Then you have even less traction, so to be safe you have to slow down even more.
Is your car well-maintained? We’ve all seen old beaters chug-chugging down the road and thought, “Man, that car probably can’t go above 40.” We intuitively know that cars like this would likely shake themselves apart if they went too fast. If the car isn’t well maintained, this decreases your MSS even further.
Are there too many other drivers? If there are other cars in the way, that slows it down more… and if there’s a chance you can stopped by a traffic cop, that slows it down even more…
Wow how do we get anywhere these days??
What this shows is, there’s a Maximum SAFE Speed that you can go in a car, depending on the conditions. SAFE. So while you can go faster, it becomes risky to do so.
How Does This Apply to QA?
In the QA space, there are many things that can slow us down. Ideally we should be testing, automating and shipping stuff all in the same sprint.
We should be. But… a lot of times that doesn’t happen.
I can almost hear you agreeing through the screen.
These things slowing us down prevent us from being as efficient–from going as fast–as we want to. They cause the “Maximum” in MSS to be low.
What kinds of things force us to slow down? Stuff like:
- Context switching,
- Lots of bugs,
- Repeated instances of the same bugs,
- Failed deployments to test environments,
- Maintenance of tools, test cases or test automation,
- Not understanding the product or changes to the product,
- Not being able to write test cases or test automation fast enough.
How Do We Know If We’re Going Too Fast?
When you’re going too fast in a car, you can feel it in your butt. You just know, hey, I might slide off the road or something, and I’m not feeling too great about this. I think I’m trying to go too fast. This affects the first “S” in “MSS”–safety.
There are symptoms of this too, which include but are not limited to:
- A growing backlog,
- Constantly broken automated tests,
- Team frustration,
- Aggravated customers,
- Smooshed QA timelines.
How Do We Increase Our MSS (and then actually go that fast)?
First, I mean, you have to get a handle on where you’re spending your time. If you’re not spending time adding value by either shipping or improving your product, chances are your MSS is already low, or in danger of becoming so.
A lot of teams–a lot of people really–don’t sit down and audit where they’re spending time.
And I guess this is where I put in the obligatory “How much time are you spending reading blog posts?” 😉 (which is why I edited it to be much shorter)
Work is generally done in chunks, like a day, or a week, or a sprint. So to answer this, we need more granularity.
Take a look at your day-to-day. If you can’t estimate, draw up a graph of how much time you spend, on average, on the “what’s slowing us down” bullet points further up.
Then, see if you can tell if there is evidence of the symptoms listed in the next set–symptoms showing that maybe you’re trying to move too fast.
Are you large on:
Context switching? Try setting aside blocks of uninterrupted time to get work done. Find when you do the best Think Work and block off that time. Communicate this to team members, you might just set a new precedent!
Lots of bugs or repeated instances of the same bugs? Perhaps beef up on unit testing, or refactor some code to make it less “cohesive”. Avoid writing code that breaks a bunch of stuff with simple changes.
Failed deployments? Keep the deployment pipeline free of glitches. It’s easy to let it get kinda rusty, but don’t let it, especially if you’re trying to set up a continuous delivery pipeline. Keep your builds quick, push-button, nice and sleek.
Meetings? While usually well-meaning, they do take time away from other tasks. Astonishing, right? 🙂 There are very few meetings you absolutely have to go to. Some of them can be “refactored” into a phone call, an email, or a drive-by. Just be careful not to cause your target to context switch 🙂
Maintenance? If too much time is being spent maintaining tools or test cases, it’s probably time to rethink what problem the tool is trying to solve. Maybe it’s time to switch tools.
Not understanding product/changes? If you’re spending a lot of time just trying to grok the product, it’s possible the product is too complex. Or maybe there’s not enough training. Be sure to smear the Brain Juice around to new members to get them up to speed quicker.
A growing backlog? This indicates maybe we’re biting off more than we can chew when pointing stories. Estimation is just that–estimation. And mowing through 50 points of stories doesn’t indicate how much value was added with the stories either–it could’ve been 50 points worth of maintenance, workarounds or even complete boondoggling. It happens. Does that backlog really need to be that big? Can things be combined with other items, or culled out entirely? Maybe.
Constantly broken automated tests? Automation code is still first-class code, just like production code. It should adhere to the same principles as good prod code does. If they’re breaking all the time, is there a pattern to the breakage? Is there an overall fix that can be done to address all of them? Is there a different style to try? Actually if you have a problem with this, contact me and we can talk about it. I might be able to help.
Team frustration? adj.: feeling or expressing distress and annoyance, especially because of inability to change or achieve something. This is the best tell of low MSS right here. Why can’t the team change or achieve something? If you answer this, you’ll probably answer a lot of other problems keeping you from being productive.
Aggravated customers? Are they aggravated because they continue to get crappy workarounds? Do we really understand what they’re asking for? Or are we literally giving them what they’re asking for, when what they need is a little different? Is quality down and they have lots of bugs? How can these be addressed?
Administrivia? If you’re spending a lot of time on just bookkeeping stuff, or “herding kittens”, this can take up valuable time. How much of this do you really need to do?
Smooshed QA timelines? QA always seems like it’s getting the short end of the stick. And when QA can’t do their job as well as they should, the product is almost always not as good as it could be. Which, then that contributes to everything else above. Instead of smooshing the timeline, can QA take on more of a “Quality Advocate” role (which is great because you can still reuse the same acronym and not change letterheads)? Can they work alongside devs, BAs and everyone else? Can they infuse quality practices into people around them, and enable everyone to contribute to quality? Short answer: Yep. It’s a cultural change but not impossible.
Where is Your MSS Suffering?
If you can identify pain points in your process that hamper you from moving as fast as you want (safely), you’re on track for great things!
Where can you make some changes that will help?
It’s incredibly easy to get lost in the details and get pwned by the very technology that’s supposed to be helping you work better.
And I can help you with that.
Would you like to find out more?