Splitting into Multiple Scrum Teams

Hi Jason,

Have you tried both options already? Are these pros and cons based on inspection and adaptation?

Jason,

What is your role on the team?

Have you asked the team members what they view would be the best formation? Do you have the flexibility to let the teams self form and re-adjust based on inspection and adaptation as Joshua mentioned above?

My role on the team was the guy that convinced our heavy waterflaw organization to "allow" 2 pilot agile teams, although not specifically Scrum as it WAS an politically charged term. My role then become being one of the half dozen folks to successfully convince our organizational leadership to move the organization (over 700 people) to an agile model, specifically Scrum, based in no small part on the success of those teams. My role going forward is to manage a group of Scrum teams, hopefully by keeping my pointy hair out of their way as much as possible and providing them with whatever their inspections reveal is needed to be successful .

The current team that I'm referring to was one of those pilot agile teams, and is currently one very large team. From an inspection standpoint that team has recognized that this is an impediment going forward. There is no consensus on the team whether splitting into 2 or 3 teams would likely be the best approach at this time. We will have some flexibility to adapt if the team determines that initial approach is not working (or does work for a while but needs to change later). However, we do have to work and align with the "Product Owner" group and other "Foundation Teams", so there will be a non-trivial cost with that type of change. So we don't HAVE to get it right out of the gate, but I would like them to have the most likely chance of success to start out with.

Thank you,
Jason Skidis

Jason,

Thanks for the expanded context. Something I failed to mention before but need to ask now is:
Would all the teams be working on delivering one product?

If so, and assuming that they've discussed all of this a fair amount already then my advice is to put them all in a room, have the next 2-3 sprints worth of Product Backlog handy, and give them 1-2 hours to decide for themselves, after you've presented all of the information that they don't already have. This large team seems like they have enough Scrum and development experience to make decent decisions, and you yourself admit that there isn't one straight forward and obvious best solution. It also sounds like you have enough leeway from the org to allow them to inspect and adapt in at least smaller ways going forward. You might try using the "Fist of Five" technique rather than trying to a get a completely unanimous decision that everyone has to be ecstatic about.

Your situation is fairly unique. I don't have a personal experience that matches close enough to contribute, I'm afraid. Maybe others do.

"Is it one product?" is one of those questions that depends on what context your asking in. The team is working on one PROJECT. This project is composed of a back-end "big data & analysis" layer with regular user facing capability exposed through web portal content and a set of APIs and tools made available for "external tool builders as users" . In terms of "deployable units" (different sets of portal content, services/API vs. tools etc.) we can split on a number of axis, so depending on how we want to define a "product" there are a number of ways to answer that question.

Moving forward we can relatively easily split into 2 groups either by splitting core data + analysis vs. portal content, API and tools OR by splitting up by the domain area. The problem comes when we try to think of logical way of splitting into 3 groups that could be maintained with relative consistency (in terms of team size needed to be deliver the highest value backlog items of the project) over the next 12-24 months. As I mentioned there is some value in allowing teams to have ownership of some logical grouping that is consistent for a significant period of time. However, we could go to a model of one backlog across the multiple teams and is somewhat arbitrarily split up each sprint (or every few sprints) that would allow us achieve a smaller team size. There is a consensus that an approach where we split into 3 teams whose size is frequently changing to meet demands is not an option we would want to explore. The "Product Owner" group is pushing for the logically consistent grouping in 2 teams but aren't adamant and could be convinced otherwise if given good reasons to do so.

I was hoping, probably unrealistically, that I would get some feedback like "Advantages of small teams almost always trump team ownership consistency or requiring certain specialists trying to focus on 3 or more teams at once" or "The team ownership principles and/or having specialist focused on fewer groups is almost always more important than having a team that is a little large than ideal." I appreciate the feedback I have received. I think we will likely move forward with the 2 team approach and make sure we are regularly assessing (inspecting) that decision and adapting it if we found that we need to.

Thanks,
Jason

Jason,

Thanks for the extra context. Defining "product" is sometimes difficult, and in your case, moderately complex (though I've seen similar products in my career)

I'm sorry you didn't get the straightforward answer that you're looking for. I understand and feel your pain. Your motivations are noble and genuine. Having said that, this happens a lot in complex situations. If your problem was simple, I might be able to give a simple answer. Your problem is not simple.

Some things to consider:
* It's very difficult to communicate complex team/project context across the "interwebs" or "not live." Ken Schwaber talks more about this in this post(and I tend to agree): http://kenschwaber.wordpress.com/2012/08/04/i-have-a-quesstion/
"...Forgive me for not giving quick answers. Surgeons don’t perform surgery over the phone, either (I think)..."

* There are other variables you did not and maybe could not describe. Some examples:
Is your team co-located? How truly co-located is it?
How good is your PO who might be split across 3 teams? Is the PO 100% dedicated/allocated to working on this project and this project only?
How good is your SM who might be split across 3 teams? Is the PO 100% dedicated/allocated to working on this project and this project only?

And then we come back to the meta issue at hand.

If what you're describing is a truly complex problem, then there is no easy/quick answer, AND furthermore, the accuracy of said answer is suspect. Scrum and complexity theory (the Cynefin model, in particular) teach us that, for complex problems, it's usually better to "Probe, Sense, Respond" then try to "Sense, Analyze, and Respond". Said another way, it's better to pick a path and test it out than it is to over-analyze which path to take. I believe this is kind of what Joshua was alluding to above.

If I were you, I would work to convince your org something to the effect of "All the easy problems are already solved. The days of one size fit's all solutions and 'best practices' are over. We live in a society with global competition and globally complex problems. Software product development is a complex space that is not predictable by statistical analysis. The best we can do, as a team, is to pick a decent path and then inspect and adapt towards a better path. If anyone else thinks they can always pick a better path for complex problems, then they should get to Las Vegas or become a stock market investor, because they will get much richer in those arenas. Or not."