Using Scrum/agile with multiple customers

Question

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)

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.