Last week, we reported on the wastes that are attributed to having a Product Backlog. This week, to keep it interesting, we'll report on the wastes present when a Product Backlog is absent.
I have been working with a group adopting Agile practices in their organization. They happen to be a services group - one that builds internal software for other groups (not necessarily software groups) within the organization. One of their main problems happens to be that they have not been successful in getting all of the stakeholders to agree on the priorities of their requests - each group sees its request as being important. And, by the way, they want all of the requirements done.
This scenario is not an uncommon one in the industry: a development group has multiple clients and each client has its own priorities. Unfortunately, many such groups are unsuccessful in creating one backlog because of the difficulty of getting everyone on the same page. So they have an internal prioritization and have frequent interrupts depending on the size of the fire that needs to be put out and the volume of the speaker on the other end of the line.
After a good discussion the team realized that every team really does have a backlog - even if it is not explicit. There is only one order of execution of tasks, even if there is no physical, visible, backlog - that is, there is an implicit backlog in each and every project (Agile or not) that is determined by the execution order.
They have decided to be explicit about their backlog and make it visible to all their clients. They are expecting their clients to become interested in getting involved in the maintenance of this backlog over time as they see the team executing to the project.
There are, of course, other ways to go about this. For example, a report from the BBC team at Agile 2007, expressed their experiences with multiple backlogs and their attempt at one product owner. Clinton Keith wrote up a good summary of the problems and one set of solutions with this approach. Mike Griffiths describes how a Project Management Office (PMO) can interface with multiple Agile projects via their backlogs.
Do you have an implicit backlog between your multiple projects because it is just too difficult to have one and only one backlog? Is it wasteful? How have you addressed the issues?
Community comments
Wastes in Implicit Backlogs
by Bruce Rennie,
Re: Wastes in Implicit Backlogs
by Amr Elssamadisy,
Re: Wastes in Implicit Backlogs
by Deborah (Hartmann) Preuss,
Multiple backlogs
by Jim Standley,
Re: Multiple backlogs
by Amr Elssamadisy,
Re: Multiple backlogs
by Deborah (Hartmann) Preuss,
Wastes in Implicit Backlogs
by Bruce Rennie,
Your message is awaiting moderation. Thank you for participating in the discussion.
Well, without too much deep thinking it seems to me there significant risks to an implicit backlog.
1. Waiting
It seems like it would be possible, even likely that someone, somewhere in the organization is going to be made to wait while the priorities are sorted out and agreement reached.
2. Rework
I've noticed that most development organizations don't like to wait or don't like the idea of teams waiting. Nature abhors a vacuum and all that. Someone is going to get waiting teams to do something and that something may or may not useful. If it's not, rework is likely.
3. Motion
It seems likely that operating with an implicit organizational backlog could result in a lot of extra work in the form of frequent efforts to hammer some agreement on what to do next.
Anything else?
Multiple backlogs
by Jim Standley,
Your message is awaiting moderation. Thank you for participating in the discussion.
I saw one project handle this by allocating story points to the different customers. You get 50 this release, you get 100. (They can easily compute the shares from their historical velocity by the customer's funding contribution.) Prioritize however you like within your allocation and that's what we work on.
Re: Wastes in Implicit Backlogs
by Amr Elssamadisy,
Your message is awaiting moderation. Thank you for participating in the discussion.
Yes. That is what I was saying. By *not* having a backlog, you have one anyway. It is dangerous. So go ahead and create a backlog.
Re: Wastes in Implicit Backlogs
by Deborah (Hartmann) Preuss,
Your message is awaiting moderation. Thank you for participating in the discussion.
> anything else?
Well, politics comes to mind. You know, where everyone thinks THEIR work is at tht top of the queue and IT is left (inappropriately) to play arbiter.
i.e. not only:
> ... the team realized that every team really does have a backlog - even if it is not explicit.
but also, the organization needs to realize that they are the authors of their own dissatisfaction, if theiy are not providing clear information to teams about organizational priorities.
I've seen enormous waste of time and energy due to political wrangling. When the organization doesn't realize it is responsible for priortization, it looks like this spinning is caused by IT (because that's who's visibly dancing at the end of the string).
Re: Multiple backlogs
by Amr Elssamadisy,
Your message is awaiting moderation. Thank you for participating in the discussion.
So an explicit backlog was created and each client got a number of 'points' to add to the backlog?
Is this per iteration or some other granularity?
How well did this work for you and were there any problems?
Thanks for sharing!
Re: Multiple backlogs
by Deborah (Hartmann) Preuss,
Your message is awaiting moderation. Thank you for participating in the discussion.
I have written a series of user stories for collaborative prioritization of work. I have looked for software to do this, but found nothing I could use securely over the web. What software I did find fell into the category of "participatory budgeting".
The stories: a product management team needs to do distributed product management - let distributed customers decide what gets developed first, to stop playing telephone.
1. 20 customers each get, say, 100 points/dollars/bananas
2. They see an online the list of all possible features we could develop for them, and can add their own. They know full well they can't get all of them.
3. The list is prioritized (top of list = highest priority)
4. The customers come online in real time at the same time and bid for features.
5. They should soon realize they'll get what they want more easily if they pool points with other customers. Haggling starts (ex: on the phone or IM)
6. They start changing their bids to take advantage of this strategy
7. They finish and we now know what to develop!!
8. It would be good to know who voted for each feature, so we can continue discussing with them as we develop.
9. Later: We will want to remove the top X items from the list, add a few new ones, sometimes change the priorties, and do this all again in a few months.
Someone spoke at a conference of doing this (probably without tool support) but can't track them down.