I’ve been working at the intersection of the project portfolio and the product roadmaps. (You can tell because of the various posts about information persistence.) Here’s what I find when I work with my clients:
- They have years worth of projects in the project portfolio.
- They have years worth of ideas in various states of description in what they’re calling product roadmaps.
- They have years worth of defects in the defect tracking system.
All these possibilities create a cognitive load when people attempt to assess their work. Or, even find the ideas.
I’ve advocated the use of a parking lot for years. Some of my clients think they’re using a parking lot. But, they continue to assess the work in the parking lot.
No, the point of a parking lot is so you don’t have to look at it.
I’ve started to take a more aggressive approach. I suggested to a client that they delete—yes, erase from their project portfolio tool—any project over three months old. I suggested they limit all roadmaps to not more than three months. And, I suggested that they delete anything over three months old in their defect tracking system.
You should have seen their faces. Horror. Disgust. Fear.
One person grinned. I asked that person what she thought.
“Great idea. If we see those ideas pop up again, we can add them the way I add to my closet. I live in a small apartment. If I buy something new, I have to get rid of something old.”
Exactly!
The more stuff we have, the more difficult it is to manage all that stuff. Even if you use a parking lot.
A Cleaning Experiment
The other people in the meeting were a little dubious. I asked what they might consider as a small experiment. They decided on these actions:
- Copy everything so they had a backup of it. Nice way of managing risk.
- Delete, delete, delete.
- Work for a couple of weeks in the teams and for the product backlog. See what they finished.
- Assess the project portfolio with just the various projects in progress at the end of a month. See if they could stop anything because they’d done enough.
At the end of the first week, several teams had added back some of what they called technical debt. The POs—by agreement—removed some features so the teams could fix the problems. Much grumbling.
However, because the teams fixed their problems, their cycle time decreased. That meant the teams were able to make faster progress on the remaining features.
That work cycle: rediscover old problems, fix them, improve overall cycle time occurred several more times for each team. They used the experiment loop to see if they made more progress.
Most of the teams did. One team realized they had not thought enough about the order of the work. They had to bring work they’d originally thought was six months out back to the present. However, they discovered that just one week in.
And the project portfolio? The meetings were much faster. The decisions crisper, because they weren’t considering work not in this relative time period.
A month in, the project portfolio people discovered an opportunity. Because they hadn’t planned so far in advance, they were able to capitalize on that opportunity.
This has been my experience in my business and in several of my clients. It might not work for everyone. What have you got to lose?
If you’re not ignoring the parking lots, delete everything and start over again. If you can’t delete “everything,” use cycle time to consider not much more than three months of work.
Planning and replanning doesn’t get the work done. Execution gets the work done. Execution without cognitive load is much better than execution with that load.
See what you can do—maybe even experiment!—to clean your backlogs so you don’t have cognitive load every time you look at all the work.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Clean Your Backlogs Opinions expressed by Java Code Geeks contributors are their own. |
