Daniel Vacanti and Prateek Singh graciously invited* me to be on an episode of Drunk Agile: Episode 37 Johanna Rothman Part Deux More Bigger Aging.
(*Invited is their term. I sent them an email, politely demanding they discuss aging. Is it possible to politely demand? I tried. Only they can tell you if I was polite enough!)
We talked about aging (how long the work has been in progress) in these dimensions:
- The large and long-standing defect database.
- Long and large roadmaps.
- All those potential projects in the project portfolio. (We didn't address this as much because I wrote about this in Manage Your Project Portfolio. I didn't have questions.)
The aging issue I see with large and long defect databases is this:
Do we have any predictability about when we could finish any of the defects?
And the aging issues with the long and large roadmaps? We're asking people to commit to:
- Solving problems they don't yet know about
- Ordering the work by value, even though agile approaches hope the value changes.
- (Re)defining and (re)ordering the work again, and again, and again
Not only that, we endure cognitive load from the weight of all of this potential work.
Here's a lovely reframe: we're ignoring the perishability of all of this possible work.
Ask Yourself About the Perishability of Work
I started to get this transforming idea when Daniel and Prateek talked about perishability.
The more work we add to our queue of work, the less we know about its future value. Prateek said at one point (I'm paraphrasing), “Customers want the work now. They don't want to wait until later.”
The more options we have—especially options that are started but not done—the less we know about that option's current and future value. That's why agile approaches emphasize “finish something and get feedback on it.” The finishing matters. When we finish, we can see what we might consider next. (IME, it's a lot easier to see the next best option.)
All those long backlogs, queues, databases of possible work carry a cost. Not just cognitive load, but the cost of remaking the decisions, again and again.
That's why I added my little image of technical debt to this post. When we create these large databases of defects (inventory) and large and long roadmaps (more inventory), we choose to create a form of technical debt. That debt is management decision debt.
In the video, we offered several ideas, mostly about moving to rolling wave and just-in-time planning.
I learned a ton from our conversation. Thank you, Daniel and Prateek for our conversation.
You might like these blog posts, where I walked around the idea of aging but didn't explicitly address it: