I am a big believer in agile development. I just changed jobs, and I am now working for a company that coordinates big development projects for (rather large) groups of customer organizations. My job is to find the right contractors for the projects, and make sure that the customer organizations are as happy as possible, and control the process. There is nothing in the world that would make me happier, than if I could introduce Scrum or a similar agile method into this situation, making my company's main role the product owner. It would make sense on so many levels.

There are some issues though: Since Scrum is a rapid-response method, I wonder if Scrum is the right method for a place like this, where not one customer but a big group of customers have to be involved in prioritizing of the backlog from sprint to sprint. It takes place in a quite political environment. What pitfalls and possibilities do you see in a situation like this? Can this situation simply be handled by longer sprints?

There is a general understanding and empathy for the agile agenda in the company, but the issue I describe here seems to be a major obstacle.

I would really appreciate your input. I need good ammo for my agile preaching :o)


4 Answers 4


You present an interesting problem primarily because I have never heard of a company operating in such a way. Many companies have multiple clients, and many also have a single product that they sell to multiple clients with differing needs.

The fact that your organization simply allows clients to brawl it out in a gladiator pit over which features make it into the backlog sounds like a chaotic mess. Your company NEEDS a product owner who deals with the clients individually and determines what features and changes need to occur in the product to make the majority of clients happy the majority of the time.

The very thought of multiple product owners is inherently Anti-Scrum.

  • As mentioned, I would view my company as the product owner. That said, we still have to respect the business value of the individual customers and somehow arrive at the best possible solution for all of them, and I am nervous about how to navigate in those waters, and be able to prioritize new backlog items fast enough. I have to meet with representatives and verify business value at at different locations.
    – Morten
    Commented Dec 17, 2011 at 23:17
  • @Morten Welcome to the software business! If it was easy to mitigate different client needs in a single product then they wouldn't pay product managers the big money. If you are finding it impossible to do so then perhaps your situation calls for multiple similar products instead?
    – maple_shaft
    Commented Dec 19, 2011 at 11:57

For Agile to work best, there must be a single "product owner", a single person or team that is responsible for the generation and prioritization of requirements.

On my last Agile project, we had two product owners; two different companies who came to us as a pair and said they wanted new software to replace an application they were literally paying their competitors to use (we're talking hundreds of thousands of dollars a month in licensing fees). It worked as well as three corporate entities can work, primarily because there was a spirit of cooperation among all participants. Even then, there were problems; the requirements responsibilities were split between POs, and yet both companies needed to contribute to many of them. This resulted in differing quality of requirements depending on the PO that generated them, and often a long back-and-forth between the POs and BAs to iron out inconsistencies. The two POs also used the licensed application differently, with different configurations, and thus they had different expectations of how the same piece of functionality was supposed to work, based on settings they had long ago forgotten about from the original software.

You and your company face an even more difficult situation, in which the various stakeholders may be flat-out competing with each other day-to-day, and are biting and clawing beneath the surface for any relative advantage they can get. For one company to get a company-specific piece of functionality placed above another company's bit in the backlog is just such an advantage, and I wouldn't be surprised if one member of the organization tried to use this process to bury another member.

I would approach this situation in one of two ways:

  • Be the product owner for the group of companies. This means being the mediator, and possibly arbitrator, of disputes between the stakeholders with regard to prioritizing the backlog and creation of requirements. This would have significant value to both the stakeholders and the development firms you worked with; you become a "buffer" between the two sides, taking on the unenviable position of insulating the development effort from the politics of the requirements generation. To the stakeholders, you're a consultant and guide through the Agile process, smoothing out the bumps in the road so they don't derail the whole effort.

  • Arrange the development effort according to the stakeholders themselves. If there is a "common" set of functionality that most or all of the stakeholders can agree on, set up a large "core" team to build the basic software. Then, if one company, or even two or three, need it to work a different way for them and the group as a whole is unwilling to support the effort, you can set up or spin off smaller teams that can attack these additional pieces of functionality according to a separate backlog. These customer-specific teams are still subject to the critical path of the core backlog; creating company-specific functionality that is a change to the core feature will always be dependent on the core feature being implemented first. Definitely make sure the additional functionality is integrated in such a way that the project still passes the core ATs; those are the ones for which you and the developers will be getting the lions' share of the contract price.

  • First, Fortunately, the customers are not in competition. Second, I am thinking us as mediator/arbitrator, and my very concern is that this part of the job is very time consuming.
    – Morten
    Commented Dec 17, 2011 at 23:41
  • Well, as I said, being the mediator/arbitrator between multiple customers and the dev team(s) is your "value-added" contribution to the process. It will be time-consuming, but that time is billable. The goal of this effort is to produce a single prioritized backlog of your customers' requirements. Given that much, Agile teams are relatively self-sufficient; they take work off the top and go off to do it. You will only be needed when there is a problem, and they will either tell you of the problem or it will be reflected in reduced numbers for a sprint or two.
    – KeithS
    Commented Jan 3, 2012 at 22:11

Backlog prioritization is really more of an input to scrum than a result of it. The only property of agile that might make backlog prioritization easier is that more frequent releases reduce pressure to include everything in a release. If you only have one release per year, customers will fight tooth and nail to get their features included now, so they don't have to wait 2 years. They are more amenable to compromise if they only have to deal with a delay measured in weeks.

Therefore, making your sprints longer will make the problem worse, not better. If you think about it, you are probably sort of doing 6-12 month "sprints" now. How's that working out for you?

You don't have to revisit the entire backlog every sprint. You get it into a basic order once, then on each sprint you only need to take what has changed during the sprint into account: an urgent bug that was just discovered, a new feature needed to respond to a competitor's release, etc. The product owner's job then becomes mostly reminding people that they already hashed this all out, and asking if they have new considerations to bring to the table.

  • Don't worry. I am in no way thinking about one year sprints!! That is no where near agile in my mind. I was thinking one month, maybe two.
    – Morten
    Commented Dec 17, 2011 at 23:19
  • ...(continued) That would give me more time to seek/encourage/demand input from the customers. You might say "Then you just need more input, because you need more baclog items for a long spring", and my answer would be: The key here is, that we need BROAD acceptance for our decisions as product owners, and that a LOOOONG road trip to repeat every two weeks or so, as our customers are evenly scattered around the entire country.
    – Morten
    Commented Dec 17, 2011 at 23:31

You need a product owner. You need a single customer(and preferably a single BA from that customer) that can take responsibility for the direction of the project and coordinate your story priority and champion the end product. That product owner would be responsible for taking all of the differing customer expectations pulling them together and either getting a consensus from the customers on the priority and direction and/or making the decisions.

I have heard of some issues with some groups that have multiple customers about competing BA's that want their name on every story and competition for points. It is important for the scrum master to communicate that this is a business project not a football game. The points are an indication of progress not a score of how well some one is doing or how much work any one person is doing. 0 point stories and chores are often just as important to the end product as the 5 point stories.

  • So where does this leave my company? The organizational landscape will not change. Are you saying that we should continue the use of waterfall approach, because agile will not fit here ??
    – Morten
    Commented Dec 17, 2011 at 23:39
  • If you do not have a single product owner I would not expect better results from waterfall either. Your suggested solution of your company being the product owner may achieve the best results for all of your customers but in a highly political environment I would not expect a lot of cooperation from the other business units. It will be important that you have a strong willed BA that can cut through the BS and stand their ground with both the business units and management that will eventually get involved when the wrong feathers inevitably get ruffled. Commented Dec 19, 2011 at 14:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.