October 2020 - Velocity should be renamed "future tech debt"

Velocity should be renamed "future tech debt"

October 21, 2019

Velocity should be renamed “future tech debt”

Sense & Respond Press is excited to share our latest offering - Innovation Days. Innovation Days is a 6 month speaker series that brings experts to your office, once a month, to educate your teams on today's latest tools, techniques and ideas. We've put together a diverse lineup of thought leaders and practitioners to help your teams grow. Check out the full list of speakers here and read a bit more about it here.

Hey folks -

Two weeks ago I found myself at the center of a debate with a client about the benefits and drawbacks of managing agile scrum teams to velocity. My client was contending that productivity could only be measured and therefore incentivized if we counted how many story points, stories or features a team completed in each sprint. And, not stopping there, the client insisted that this measurement needs to

increase

with each sprint or, at least, trend upward over time.

I understand this point of view. It's the direct descendant of a manufacturing mindset applied to knowledge work. In manufacturing, the goal is to produce as many items as possible in a given time frame, as cheaply as possible. This is because the more inventory you have, the more you can sell, the more money you can make.

This is simply not true with knowledge work and it's even less true when it comes to digital product development.

After mulling it over for a while, I took to

and summed up my thoughts in the following 3 short tweets:

The only thing we are guaranteed to have if we incentivize our digital product teams to create more code is more code. That's it. There is simply no correlation between more code and more

. There is no guarantee we can sell that additional code, that it solves any more customer problems or meets the needs of the business. Think of Microsoft Word as the poster child for this example. How many features are in that product? How many do you use? I rest my case.

The code that we incentivize teams to create when we measure velocity is code we will have to live with

forever

. At some point in the future it will degrade, become obsolete and weigh down the overall system we're building. We will have to go back and refactor it, optimize it or sunset it. This is the textbook definition of tech debt -- a running list of technical optimizations teams have to execute in order to maintain optimal performance of digital systems.

If instead of "velocity" we called it "future tech debt" I wonder if we'd be so quick to incentivize its production.

And, it's not just tech debt that we add. We also add experience debt. By increasing the bloat of our digital systems with lines of code and features that don't necessarily deliver value to our customers we create sub-optimal experiences for our users. These customer experiences will also have to be updated and optimized ultimately adding even more work to the team's backlog that isn't moving it forward but rather correcting the mistakes of the past caused by misplaced incentives.

Finally, the biggest casualty of incentivizing teams to increase velocity is their ability to prioritize and do

. This is the (often) non-technical side of digital product development that helps teams learn which features and experiences

will actually deliver customer value

and how to best prioritize the time they have to work on an initiative. If a team is constantly chasing the delivery of more lines of code they will never prioritize nor be able to justify the use of time for anything other than coding. The customer-centric practices of product discovery end up prioritized out of every sprint along with the customer's true needs and pain points.

Look, it's easy to incentivize the production of code because it's easy to measure and compare it to previous sprints. What's more difficult is pushing aside the hundred years of manufacturing-based management incentives and reframing success for teams in terms of modern day knowledge work where the value of that work is measured not by the number of lines of code they write but by the

.

[Jeff]

@jboogie

Upcoming EventsNew Live Online Class offering -- Josh Seiden and I just completed our first Live Online Class - Product Discovery for Agile Teams. We've launched registration for the next cohort and it is already 50% sold out. This has been a fun, hands-on way to take a class with us from anywhere in the world.November 1 - Live Online Office Hours with Jeff Patton -- Spend 2 hours asking questions and discussing answers about product management, scrum, lean ux and agile with Jeff Patton and me. This low-cost block of office hours is our attempt to provide more face time to anyone struggling with these challenges. Best part? You can bring the whole team.SOLD OUT -- November 3 - Design Sprint & Lean UX 1-Day workshop with Jake Knapp - Barcelona, Spain - Jake and I have sold this course out but are planning more in 2020. We'd also love to bring it in-house to your teams in 1 and 2 day formats. Interested? Drop me a note.November 25-26 - Professional Scrum with UX 2-Day Workshop (Scrum.org Certified) – Madrid - The new certified PSU course Josh Seiden and I helped develop is coming to Madrid with me as one of the facilitators. 

As always, if you want me to work directly with your company on training, coaching or workshops on the topics of organizational agility, digital transformation, product discovery and agile leadership, don’t hesitate to reach out.Like this newsletter? Forward it to a friend.

Reply

or to participate.