Sad Stories

How are you measuring the quality of your product management? Is it:

• How accurately you adhere to Scrum? 
• How close your velocity matches your SLO? 
• The number of bugs fixed in this sprint?

None. of. this. matters.

A surface level review of these metrics would seem to matter to folks desperate to boast about their Agile compliance, while failing to remember the first edict of the manifesto:

Individuals and interactions over processes and tools

A recent tweet reminded of this:

Wow! I reported a unicode issue affecting URLs to 2 different commercial software companies. One responded in 4 days indicating it'll be fixed in a yet-to-be released new version (which requires more $$$); the other provided a working patch in less than 3 hours.

— James Moberg (@gamesover) June 18, 2019

While I can't comment on what specific bottleneck is separating these two companies, I understand (all too well) the side-effect of throwing everything into a Scrum bucket. After interacting with several Agile product teams behind the corporate curtain, it became painfully clear that their ludicrous turnaround times were a direct reflection of their adherence to scrum.

They played their hand in a conversation similar to this:

~~

Me: We've got a request from legal to update the link in the footer. Can you help us with this?

The Product Team: You bet, we'll write up a story. Should make it into the next sprint.

~~

Wait...what?

Does changing a link require a story? It does if you see every request as a story in the context of your sprint backlog.

There Are Other Ways To Agile™

If you've been charged with DOING THE AGILE to please corporate compliance (but in reality need to manage your product effectively), you need to be able to set aside a class of requests that are simple enough to sidestep a story -> queue into the backlog -> sprint life-cycle. Consider an alternate reality, where a different measure of health is more appropriate:

Here's how I'd measure the health of any tech company:

How long, as measured from the inception of idea to the modified software arriving in the user's hands, does it take to roll out a *1 word copy change* in your primary product?

— Jeff Atwood (@codinghorror) October 25, 2018

For my own product team, the solution was not Scrum, it was Kanban:

• No "pre" queue forcing a waiting period (eg. the backlog that preceded the current sprint): tasks constantly flow into from the request pipeline to development.
• Certain tasks can be marked urgent, but I'll decide what constitutes an emergency.

To implement, we use Trello, Butler, Zapier, and Gmail:

• Customer requests come to me via email, with the details / assets attached, ready to go.
• I eyeball to verify it is, in fact, valid work to be done, then forward the email directly to the Trello Kanban board.
• A Butler rule parses new cards (via email) for certain attributes, labels them, assigns a customer email address, all of which preps the card for development (this is where I'd intervene and mark urgent, if necessary).
• Available team members scoop up the task, execute, review, and push into the "Done" lane when complete.
• When a card reaches the "Done" lane, a Zapier automation is triggered, composing & emailing a response to the customer, letting them know the task is done.

Corrello reports that over the last six months, 50% of our "copy update" requests have been fulfilled in 1 day. No sprints. No stories. No backlog. And yes, we're still Agile™.

Happy Stories

Stories aren't appropriate for all requests...and it is saddest story of all to hear that you're forcing them to be. Stop the madness. Adopt this personal motto of mine instead:

"Not everything can be done quickly...but the things that can be done quickly will be."