2

Backstory

A scrum team is well defined. They have a PO, scrum master, clearly defined scope. The workload increases, as more and more projects are covered and need to be maintained, but it is still the same scope.

Problems

Team struggles with capacity, so more developers are added to the team. They pick up, the job gets done, but the manageability of the team decreases. Scrum events (standups, grooming, planning) last long, plans are less precise, and since the sprint backlogs are larger, PO is overloaded.

Question

We want to split the scrum team in two or even three scrum teams, sharing the same scope. The scope cannot be divided. We just want to split the workload. Since the PO is also overloaded, we want to introduce another PO or even two. If we do that, what would be good practices in organizing the overall backlog and organizing scrum events, such as planning? How do we efficiently groom, plan, synchronize the teams, and synchronize the POs?

More precise question

PO's create the tasks based on the input from the stakeholders. The interface towards the stakeholders does not change. The overall team backlog remains, and the stakeholders put the requests in it. The POs then process the requests and create user stories. Since we do not want to assign user stories to specific developers or even teams at such an early phase, how do we organize grooming, so that the teams have the knowledge of the backlog items before planning, but not to turn grooming into a meeting of 20-30 people?

Improve this question
5
  • 2
    Do you know about Scrum of Scrums aka Meta Scrum? It sounds like your team is right at the edge of where that starts to make sense. Maybe you can cherry-pick some ideas from there, even if your team is not quite large enough to need a full implementation. Commented Dec 2, 2017 at 12:01
  • Thank you. I heard of SoS. In fact, we implemented it in our company, but more as a synchronization between the teams with different scopes, but with some dependencies between each other. I will look more into this, to see if there is something more I can use from this. Commented Dec 2, 2017 at 12:06
  • 1
    Sorry, if the workload increases, so does - by definition - the scope of work. Commented Dec 2, 2017 at 16:22
  • Let me try to clarify our terminology. You have a baseline product. If you sell it to three different clients, you did not increase the scope, but you do increase workload, because you have three different installations to maintain. However, if all three clients have their own customizations of the baseline product, then the scope has increased as well. Commented Dec 3, 2017 at 19:47
  • "as more and more projects are covered and need to be maintained" does not fit into the Scrum framework. It is focused on having a Scrum Team creating a single product, not working on multiple proJEcts. Commented Jan 3, 2018 at 18:14

4 Answers 4

Reset to default
3

In short:

Sharing the same scrum scope between several scrum teams, just for the sake of dividing the workload, is against the scrum spirit and it is doomed to fail.

In addition, developers are not just an interchangeable capacity to process user stories: developers build up knowledge during each sprint and share it within the small team. This knowledge must remain available in the subsequent sprints for ensuring sustained efficiency.

You will certainly be disappointed to hear this. But fortunately there's some hope on the side of Nexus, if you're ready to adapt a little bit your approach.

Detail: why is it against the scrum principles ?

The issue with the PO

Scrum is based on the assumption that one Product Owner (PO) is totally in charge of the product in scope and decides about priorities. According to the Scrum guide:

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.

The Product Owner is the sole person responsible for managing the Product Backlog.

In your situation the single PO is a bottleneck. So you want to have several PO. But then the POs are no longer the sole responsible. And if there are several POs, do they all have the same understanding (and ownership) of the product ?

A couple of periodic meetings will not solve this issue. Either there will be three POs owning the product with necessarily a different understanding of the product. Or there will be one PO and two assistant POs who no longer have the required power. This will no longer be Scrum.

The issue with the teams

One of the principle in Scrum, is that the teams are autonomous, organise themselves, and have all the skills to succeed. Some quotes from the Scrum guide:

teams have all competencies needed to accomplish the work without depending on others not part of the team.

Scrum recognizes no sub-teams in the Development Team

accountability belongs to the Development Team as a whole.

De facto, your organisation is to have three subteams that are co-responsible for the overall product.
Making several teams working on the same scope just for splitting the workload, will result in one team being dependent from another (for example if a team has to develop a refinement of a user story made by another team). You will lose all the synergies that Scrum tries to achieve.

Scaling Scrum is not a problem !

Scrum of Scrum

The scrum of scrum is the most common approach. There are several teams (and hence several PO), but each is responsible for one sub-product. Of course there could be some overlap between the teams, but it's limited to the frontier between sub-products and well managed in the scrum of scrum. Reported scalability is beyond 200 and up to 1000 team members.

Nexus: a solution for you ?

The Nexus approach is closer to what you are looking. It was developed by the inventors of Scrum.

A Nexus has one single PO (and hence clear ownership of the product) and a single SM, but several integrated teams. The approach addresses in detail the inter-team integration and synchronisation across the full Scrum process. For this purpose it uses a tightly coupled integration team (more tightly coupled than scrum of scrum).

The backlog is split between the teams so to minimize dependencies (so to increase autonomy of each team). You will be pleased however that there is no requirement to identify different sub-products. Nevertheless, this approach takes account of the knowledge building aspect I've mentioned earlier:

To the extent that requirements, team members’ knowledge, and code/test artifacts are mapped to the same Scrum Teams, dependency between teams can be reduced.

The reported scalability is three to nine scrum teams, meaning 9x9+2=83 persons.

Improve this answer
4
  • +1, but take those reported numbers with a grain of salt. I’m sure they were reported by the people selling this method... Commented Dec 3, 2017 at 2:06
  • I do not believe that something is doomed to fail if it is against the scrum spirit. Especially since I believe that this approach is not against the scrum spirit, but rather modifies it a little bit. Nexus is a nice touch, but does not solve the problem of the overloaded PO. Now, some members of the scrum teams could take on some of the duties of the PO, but then they would de facto be assistant PO's. They just would not have that title. Commented Dec 3, 2017 at 20:17
  • @VladimirStokic Thank you for the opportunity to clarify. It's not only because applying scrum against the scrum spirit (i.e. wanting the benefit, without the constraints) that your intended approach is doomed to fail, but far more because you want to manage a large scope without assigning clear responsibilities, without taking into account the knowledge building aspect of development, and in addition creating lots of opportunity for friction. Commented Dec 3, 2017 at 20:45
  • 1
    @VladimirStokic The key to your issue is the overloaded PO. With the nexus approach, the integration team (that is composed of representatives of all teh other team) should be able to support the PO, especially on planning and prioritization issues. However they can't necessarily replace the PO in his/her role of representative of the customer (i.e. ownership of the product features and understanding of the business needs). However, as each team is multidisciplinary you could organize having a business analyst or a user representative in each team, so that the PO could delegate this part Commented Dec 3, 2017 at 20:52
1

After some thinking, an answer popped to my head.

What do we do when we split the scrum team? We have to introduce a new scrum master too. Ergo, we are introducing more hierarchy. We could do that with POs as well.

In the situation that I have described, we could split the team into the optimal number of teams. Each team would have their own PO. The overall team backlog would, however, have its own PO. Let's call him Master PO. Master PO would be a proxy towards the stakeholders. This person would have to have an extensive knowledge of an entire scope. They would gather requirements from the stakeholders, put them in the master team backlog in form of the user stories and then groom the master backlog with team POs. During the grooming, team POs would roughly divide the user stories among themselves, taking them into their respective scrum team backlogs, and then groom the stories with their respective teams. During this time, they would identify user stories that might better fit into another team's backlog and communicate that with that team's PO. They would then report to their Master PO, who would oversee this all. Sprint review would be a single sprint event, where all teams would present what was done.

Improve this answer
7
  • 2
    What you may find over time is that each team gravitates to a set of projects that they care for and that other teams hardly touch those projects. My advise would be to let that happen when it happens, unless it creates a strong dis-balance in the workload of the teams. Commented Dec 2, 2017 at 12:19
  • That is quite possible, and I think it is a good advice. Thank you. Commented Dec 2, 2017 at 12:21
  • are your POs techincal? if not I think this is a recipe for disaster Commented Dec 2, 2017 at 15:09
  • I would actively encourage teams working on different projects, so they don't get into each other's way. Just a quick question, though: why does a second (or third) scrum master mean more hierarchy? The PO hierarchy makes sense to me, I just don't see how it follows from having multiple scrum masters... Commented Dec 2, 2017 at 23:31
  • Sounds like Scrum In Name Only (SINO) missing understanding of the purpose and values of the framework; RTFM? Commented Dec 3, 2017 at 14:28
0

Its no secret that agile has problems with scale. But the usual solutions all involve splitting the 'scope' or product into many smaller products which you say you cant do.

For example, say you have an e-commerce site which has grown. you might split by business departments:

  • stock management
  • delivery
  • returns
  • customer payments/accounts
  • catalogue website

Or technical layer:

  • Database
  • Business logic
  • front end website

Most large projects can be broken down, but you need a technical architect or lead dev to find the best splits and work out agreed interfaces between them.

A feature or user story will probably touch more than one project, eg "The user should get next day delivery" would require work on all the layers and/or some of the departments.

But which ones come down to technical reasons not business ones.

Improve this answer
0

I'm having trouble conceptualizing how the PO is overloaded.

One PO, assuming this is their full-time job, should be able to accumulate a lot of requirements to keep your teams busy for years. If yours can't, look into what this person is required to do. Is there any management or push-back on requests to trim the scope? Too many meetings, paperwork, customer communications all take up time (Which is why we don't want the programmers doing it.), but can be managed.

Separate Support and Implementation from Development.

You could get additional people to work with the clients. Your product is in a different situation where you need to work with additional installations. This could fall under customer support and be managed by a different team.

Dividing your product.

I don't think there is a clear-cut definition of a product. Address communication among the teams when needed. Everyone needs to focus and get the stand up meeting done quickly. 20 seconds per person.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.