How to handle backlog of own software that is sold to clients?

In Scrum, there should be exactly one product backlog for exactly one product, and for which there should be exactly one Product Owner.

Who actually is the Product Owner in this situation? It sounds as though you are trying to make product ownership decisions.

What do you mean by "implementation"? Does this require developers to work closely with a customer to configure your product to meet their individual needs? Or something else?

As pointed out, one product = one backlog = one product owner.

You'd have to think of a bigger picture here. And the first step would be to engage in as many conversations as possible with the business itself (managers), the PO, and of course the developers. Not only you offer a single product that you sell to others, but you also take care of the actual implementation (either thru the same team or a second one), and you also ensure ongoing support for product itself, plus support each of the instances customized for your clients. You'd also have to consider contractual SLAs (which I assume are in place), time zone, language, culture, a possible service desk for support, etc

In terms of backlog, you can have epics for the product itself, implementation epic per customer, etc. The PO would prioritize the dev epics, the dev and implementation epics, implementation epics against other implementation epics, and so forth.

I'm not sure how to handle this: the company I work for develops a software package for energy suppliers and I have to transform them into an agile organisation. The whole organisation backs me, which makes it a bit easier.

Dedicated team for implementation sounds good in paper, may not be that good in reality. It all depends on the product itself, the complexity of each implementation, required level of support pre, during and post implementation, and so forth. There are strong arguments to be made that you'd want the same people developing the product also implement it and also ensure support to ensure the right knowledge is applied for the maximum benefit. But there are lots of factors to consider, so lots of discussions are required.

As a SM (assume you are one), it'll be up to you to encourage as many discussions as possible, push for as much transparency as possible, with the ultimate goal of choosing the most appropriate paths

Thanks for your insights Eugene. Actually,  the issue I have currently is that this is not an agile organisation yet. I was hired to transform them, and they are very eager, top-down, which is very positive.



Currently however, I have a PO who is also a shareholder of the company. Not ideal, but until we have someone who can take over, this is it.  I will of course act as the scrum master but also as an agile coach for the whole organisation. The development team consists of four people at the moment, and one of them only does technical support. Testing strategy is non-existent, so support has a heavy load because of all the bugs.



My team is currently too small, that's clear. I need two development teams of five or six people. One will work on the evolution of the platform, and one will work on customer implementations, and they can pick up part of the product backlog of the platform evolution when needed.  We will have a third team, who will work on new products, and they will have the freedom to experiment a lot.



but until then... I have to work with one PO and a dev team of three. Four as of Monday. And unemployment rates are zero in this part of the country, so it'll take time.

I think I'm just going to allocate 40% of the time to customer implementations, 30% to product evolution and then see what happens in that first sprint, so we learn for the next. But... if you do both dev work and implementations... what will be the clear sprint goal?



I'm probably looking for the most efficient way to deal with the workload. We will start our first sprint on January 21. I've asked the PO to prioritize the most pressing items that could fill up the first sprint, and off we go.

Understood. It's a journey, so you learn as you travel :)

Currently however, I have a PO who is also a shareholder of the company. Not ideal, but until we have someone who can take over, this is it. 

Of course, you have to adapt. Are there plans to recruit one externally? Or select from within? In my experience, usually internal people (transfers, promotions, etc) make up the most appropriate PO given their already sizeble product knowledge.

Testing strategy is non-existent, so support has a heavy load because of all the bugs.

That's one of your biggest issues right there. Normally (and where possible), developers test their own work, and QA picks it up afterwards. So as long as you aim for internal QA and business UAT within autonomous team(s), all good. 

My team is currently too small, that's clear. I need two development teams of five or six people. One will work on the evolution of the platform, and one will work on customer implementations, and they can pick up part of the product backlog of the platform evolution when needed.  We will have a third team, who will work on new products, and they will have the freedom to experiment a lot.

It's always good for management to have a vision. However, especially since this is a transformation and you have full support from the organization, I argue you are in a very good position to actually encourage the people who work on product evolution, handle implementations, fix bugs, etc, think of ways to organize themselves into what makes sense. They way reach the conclusion it's best if they stay in a single team, split into 2 or even 4.

They know their skills, their strengths/weknesses, and would be best placed to self organize. If you or anyone else in the company is going to say: here's how we're going to work, Team A (consisting of Ben, Adrianna, Luigi), Team B (Jacqueline, Andrew, David), Team C (Michael, Robert) - then you've already waste a good opportunity.

I have to work with one PO and a dev team of three. Four as of Monday. And unemployment rates are zero in this part of the country, so it'll take time.

I think I'm just going to allocate 40% of the time to customer implementations, 30% to product evolution and then see what happens in that first sprint, so we learn for the next. But... if you do both dev work and implementations... what will be the clear sprint goal?

I would advise against allocating anything. The only thing I would set aside some time for would be critical production support (say 10-20%). Better have the ad hoc PO order the top of the backlog, have refinement sessions to get work understood and estimated, and invite as many relevant people (not just the PO) to the sprint planning to make sure you have a right start. Rather than pre-existing % allocations, stimulate discussions - business value, contractual SLAs, severe bugs - see where that takes you. It may be that, at the end of the sprint, it's proven that it's best for the business to have the sprint just address 5 major bugs and nothing else :)

Wanted to write earlier, didn't have the time. Can't edit the comment, so going to update here:

It may be that, at the end of the sprint planning, it's proven that it's best for the business to have the sprint just address 5 major bugs and nothing else :)

I was hired to transform them, and they are very eager, top-down, which is very positive.

If you were hired to transform the organization, isn't it normal to start at the top of the organization and transform down levels as higher levels appreciate and execute against the agile principles?  If you are trying to start the "transformation" at the lowest levels (i.e. the development/product level) then you are doing a revolution not a transformation.  And revolutions are usually bloody, hazardous, very slow to complete and often fail.

If you did start at the upper levels of the company, then a number of the questions/concerns you are wrestling with now would probably solve themselves.  But based on your conversation so far, it sounds like you were hired to convert the product delivery (product management, development, implementation) and not the entire organization. If you really do have eager, top-down support then they will have to understand that they will also have to adapt in order to support the adoption of agile/scrum at lower levels. Given that you have gotten a lot of good advice so far. 

I'll just add this one tidbit.  Remember that in Scrum, the purpose of a Sprint is to deliver an increment.  The increment is potentially releasable body of work. The PO makes the determination of when to actually release the product based on a collection of increments. In your case it seems that it is not completely released until after implementation has occurred.  So how would that play into your sprints?