Dear, Velocity. Can We Be Friends Again?
Remember taking your first Agile steps, diving head-first into Scrum, and somebody mentioned the term velocity? When I first heard it, I couldn’t help but think to back in the day, watching Speed Racer during Saturday morning cartoons. That cat had some serious velocity. But when you ask Scrum, Inc., they don’t reference the Mach Five at all. Figures. They say it’s “…a measure of the amount of work a Team can tackle during a single Sprint, and the key metric in Scrum.”
Sounds simple enough, right? So what’s with the pattern I’ve been seeing over the years with velocity? Is it just me, or is there a fundamental misunderstanding of how it’s supposed to be used? This hit home for me when I recently got pulled into a 4-person meeting about one of my “favorite” topics: metrics.
Some VP was tryna figure out how teams could get better at hitting deadlines, and proposed that leadership might need to further stress the importance of meeting those dates. Old school project manager tactic. He brought up burndown charts, burnup charts, and suggested that maybe we should track more metrics via custom fields in Jira.
“Whoah, hold up,” I said. “When deadlines are being negotiated, isn’t velocity being used to figure out if these dates are achievable?”
“Velocity? No, we don’t have that information,” he replied.
“Why not?”
My question was met with blank stares.
Whether you dig story points, issue counts, cycle time, or whatever, if you have no idea how much work teams can finish in a given time frame, are you setting yourself up for a world of hurt? What do you think the +/- is gonna be that developers are gonna get “asked” to work overtime, and weekends when deadlines creep up, because there’s still a crap-ton of work yet to do? Something I’ve noticed having worked in both agile-leaning, and agile wannabe organizations is the emphasis (or lack thereof) on the organization part of the equation.
In agile wannabe organizations (see: ScrumBut, Zombie Scrum, and Cargo Cult Agile), people tend to focus on doing what Agile says you’re supposed to do, without making real, impactful changes across the organization. Deadlines are still chiseled in stone, scope is ridiculous, and everyone marches toward an inflexible date. The ask for metrics, and reporting becomes the norm. Project managers hound teams to see their burndowns, ask developers to start tracking hours, and wanna know the percentage to completion, or demand that teams “get better at estimation.” To this day, I still cringe when I hear someone ask “Is it done, or done-done?”
On the flipside, in mature, or agile-leaning environments, people outside of development teams tend to know how much work that teams can consistently deliver based on their velocity. Like the folks at Scrum, Inc. said, they use that key metric to when negotiating deadlines, and in long-term planning.
“Velocity shouldn’t be beholden to deadlines, but the means to determine them.”
Sure, I get it. Sometimes organizations need to be driven by dates. Whether for regulatory, or compliance reason, deadlines can be a necessary evil. But one benefit of shifting to an agile way of thinking is so that you can hopefully deliver software quicker, and more often, irrespective of deadlines. Deploy to production once a sprint? Wow, that’s way faster than some mandated date that’s months off. How about release multiple times a sprint? Or what about continuously?
But what about long-term planning? Maybe you’ve heard something like this before, I did:
“Agile is about delivering in the short term. There is no concept of long-term planning.”
Before I went all in, and became real-life Scrum Master, my then manager steered me toward project management. At the time, it was one of the few available career paths available where I worked. So, I picked up a copy of the PMBOK, but the 756-page behemoth overwhelmed my right-thinking brain. It’s why the simplicity of Agile enthralled me so much. And from what I’ve experienced, the old-school project management way of thinking is why some folks wrestle with the concept of minimum viable product (MVP). Agile isn’t the antithesis of long-term planning. It’s a tool that has multiple divergent applications. If deadlines are part of the gig, it’s important to figure out what MVP means for you in forecasting, especially in an agile-leaning organization.
Think of it like this… if you’re responsible for setting, and negotiating deadlines, wouldn’t it be cool if you knew what the team is gonna build your software? Armed with that info, wouldn’t it be great to know how much work they could potentially deliver in a week? Two weeks? Six months? If you knew that information up front, rather than six months into the project, how confident would you be in that date you just committed everyone to? Velocity is one of those things that can help you figure out if you’re gonna be early, on-time, or late. If it looks like you’re gonna go over, then maybe it’s time to reshape what your MVP looks like.
Y’all know this, but I’ll say it anyway. Velocity isn’t set in stone; it should constantly change. As teams get better, issues come up, priorities change, or somebody goes on vacation, velocity should be adjusted on the reg based on new information. That’s this historical, and up-to-date data that can be used in long-term planning, and forecasting. This isn’t a new concept either. Ever watch the weather forecast? It has the word forecast in it.
“Meteorologists are able to predict the changes in weather patterns by using several different tools. They use these tools to measure atmospheric conditions that occurred in the past and present, and they apply this information to create educated guesses about the future weather. Always remember that a weather forecast is an educated guess.” — Chrissy Warrilow, Meteorologist
We’ve all been there. A deadline looms, there’s still a ton of work sitting in “To Do,” and somebody says that everything is MVP — which I find highly suspect. Maybe when we focus on transparency of the right things, like velocity, deadlines can become more realistic. At the organizational level, hard choices about what truly makes up MVP need to be made at the time of a deadline’s negotiation, rather than 6 months into a project. Maybe then developers won’t work 60+ hours a week, and management won’t spend sleepless nights, worried that deadlines might not be met.
With that, let’s take a step back. If your organization is handcuffed to deadlines, how about we use this key metric as it was intended? Maybe then, we can all be friends with velocity again. What’s your take?
