-1

We have one Dev Team (Approx 20 Team members) currently working on 5 products with 5 product owners (one for each product). We are struggling with story prioritization between different products and lots of meetings for the same.

Below are the two options we are looking at:

1. Merging product backlogs to a single product backlog

So that team can pull stories from one product backlog to sprint backlog. (And does not have to bother about priorities anymore). But a single product backlog maybe too huge and unmanageable.

2. Separating the team into 5 teams for each product

But this is not currently possible as we have resources specialized it a particular skillet and needs to be shared across the products.

Any suggestions?

Niranjan Patil
  • 57
  • 4

5 Answers5

4

I would suggest a third option.

Form teams around the products that generate the most work. Then have the remaining developers work on teams that cover the remaining products.

Something like:

Team 1 - Product 1

Team 2 - Product 2

Team 3 - Product 3, 4, 5

Hopefully this will reduce the struggle with story prioritisation (although not completely eliminate it).

The most important thing is to identify what you want to gain by the new organisational structure and how you intend to measure success.

Get some suitable metrics in place, try the new structure and see if the metrics get better or worse. Then inspect and adapt your approach.

Community
  • 1
  • 1
Barnaby Golden
  • 4,176
  • 1
  • 23
  • 28
  • Currently the Agile Team Lead (Disciplined Agile delivery terminology) has to chase product owners and get settlement on which story is on more priority. This issue will still persist. This is in coupled with varying amounts of demands in each of the product. some products will need more than half of the resources at times. and sometimes no one would be working on that product. Any advice? – Niranjan Patil Mar 14 '17 at 10:07
  • One option is to get the Product Owners to quantify the value of each story. That way, prioritisation comes down to the most valuable story and you don't have to chase the Product Owners each and every time there is a conflict. Of course, the challenge then is getting the Product Owners to assign a story value. – Barnaby Golden Mar 14 '17 at 18:22
  • 1
    This would have been easy if we had only one product owner. But we have 5 product owners for 5 products. One PO for each product. I have started to think that splitting teams for each product is a better options, so that we have "One team - One PB - One PO". Although this has to be a long term goal, since we have specialized team members and would need some time to learn new stuff and be multi-skilled. – Niranjan Patil Mar 15 '17 at 07:55
  • The key here is to try it as an experiment. Find some measures that will indicate success (such as time spent prioritising) and then monitor them as you make the change. That way you will get a clear idea if the change to your organisation was a success or not. – Barnaby Golden Mar 15 '17 at 08:07
  • I was thinking we should go for Kanban or Scrumban. We can create dashboards and then get all the 5 product owners to keep pushing say 20 work items on the board at a time in ToDo section. Let them fight it out for the priority and keep these workitems/stories as a prioritized list (top down). Team then can just pull the work item/Story from top of the list and keep it in In progress and proceed with the work. No one from team really has to bother about priority then – Niranjan Patil Mar 15 '17 at 08:12
2

I have a couple of things to point out, the tasks priorities are not responsibility of the development team at all, this is something that is managed by the PO for many reasons, but lets not discuss about that.

As you don't have a single PO this is transformed in a fight of interests. If there is no common goal between them every PO will want their US to be done ASAP because is the highest priority for them (and this is totally understandable).

So, if you want to keep one single team for all this products you will need a PO that works as single point of contact for the Dev team, a single backlog for them and then you can try to make sprint goals focused on single products so the dev team does not have to change their "environment" in the middle of the sprint (but this is a bonus point, not mandatory).

The main thing is if it is possible to have this single PO to manage this single backlog, at the end its the same as if your current 5 POs becomes stakeholders, they will ask for what they want, and this single PO will put those thing in order. Based on what ? could be company need, if there are blocking issues or it could go as easy as money ... who is the one that is paying the most and thats the one you will attend first.

In resume, remove the responsibility of picking the task to be developed off the team, it could be by this single PO approach, by a forum between the PO where they manage the single product backlog all together. And those are my 2 propositions.

There are too many factors in place, the company, the POs shared vision and needs, the reason why there is 1 single team that is managing all this.. etc.

We are currently working with one single team for multiple products as well and we have just one PO and a single product backlog and things goes smoothly.

Hope this helps! Any doubt just tell me!

BrunoX
  • 404
  • 2
  • 8
  • 17
  • PD: this is not related with the tools you are using! Nor if you use Kanban or Scrumban, if you do so you will have the same issue with priorities. Here the issue is with the POs and their ability to decide things together. If they can do it in a forum as I said, great! if not there should be someone that do this! – BrunoX Mar 31 '17 at 08:46
0

This is a common problem and one that can be solved by discipline and team work.

5 Products seams like a lot for 20 people, and hopefully some of that work is similar and you can include it together. I would encourage the group into a smaller number of teams of 6+-3 and have them choose how best to meet the work.

If you have a self organising set of teams they will be able to figure out how to cross train enough that you will not have the need of so many specialists. Have a look at the Scrum Guide (http://www.scrumguides.org/) and follow the guiding principals in there.

MrHinsh - Martin Hinshelwood
  • 23,409
  • 5
  • 46
  • 69
  • Are you sure Scrum is well suited for us? I was thinking we should go for Kanban or **Scrumban**. We can create dashboards and then get all the 5 product owners to keep pushing say 20 work items on the board at a time in **ToDo** section. Let them fight it out for the priority and keep these workitems/stories as a prioritized list (top down). Team then can just pull the work item/Story from top of the list and keep it in **In progress** and proceed with the work. No one from team really has to bother about priority then. – Niranjan Patil Mar 15 '17 at 08:05
0

I'll make some assumptions first:

  1. The products are loosely related - e.g. if your company produces HR software, the products may be Timesheet, Training, Performance Management etc...
  2. There is a certain amount of shared code between the products e.g. login, logging, deployment etc...
  3. It is possible to have smaller teams that would have the skills necessary to ship product features.
  4. The Product Owners are able to understand the business value of a product feature and negotiate between themselves on priority.

In this case I would...

  1. Divide into 3 teams of 6/7 - this is enough people with the skills to get significant features done.
  2. Have the 3 teams "own" 1 or 2 of the products - this is so that the team can really understand and contribute to the longer term vision of the products, and ensure that technical backlog items are prioritised appropriately against the product value.
  3. Have a backlog for each team - that the product owner(s) and team own.
  4. Have an explicit method that the product owners use to prioritise features - e.g. business value, WSJF, Kano etc... Agreeing this and writing it down may help stop arguments over the approach
  5. Have the 3 teams co-ordinate changes to the shared code - maybe an Inner Source type approach.
  6. Have a coach help the team and stakeholders through the change.
Adam Gilmore
  • 13
  • 1
  • 4
  • We have varying amount of work coming up in each product. Sometimes more than half of the team has to be dedicated to one product and the rest divided among others. If we keep a fixed team of 6/7 for each product, any advice on catering to varying demands? – Niranjan Patil Mar 14 '17 at 10:04
0

Too many fronts open maybe? Take a step back to revisit your companies goals, consider lowering expectations and re-organise the teams accordingly. If you postpone a product and do 4 products instead of 5 is not the end of the world. This will give you a good boost in the other products. Be smart and pick your battles. You don't need to fight every battle to win a war.

javing
  • 12,307
  • 35
  • 138
  • 211