Skip to main content

How to run a stream using the scrum framework with multiple products that require different development disciplines

Last post 08:00 am December 10, 2012 by Kim Butler
2 replies
10:22 am December 4, 2012

My stream currently is responsible for a number of products that require different development disciplines (e.g. PHP, Java, Ruby).

I have the development resources in stream along with 1 x PO, 1 x SM, 1 x BA, 1 x UX, 1 x design, 3 x QA. In total there are 12 stream members excluding PO & SM (too many I know!).

I have been told that I can't split the stream as there are not enough resources to do that.

I am currently thinking of running daily stand-ups and sprint planning for each product consecutively so that team members can attend the ones for the products to which they are contributing. However, this is a bit onorous for the shared resources and gives me the challenge of keeping the 'one team' feeling. This might be addressed by holding a retrospective for all products.

Has anyone encountered this scenario before?

Does anyone have any words of wisdom regarding my thinking above or any suggestions of alternatives?


03:29 pm December 8, 2012

Hi Kim

It's generally recognised that, in Scrum at least, the maximum practical team size is 9. A team of 12 people is uncomfortably large and would indicate a need to refactor into smaller teams. The Scrum Guide puts the minimum team size at 3, so (in theory at least) you could get as many as 4 new teams out of the one you already have.

Furthermore, Scrum only recognises 3 roles - the ScrumMaster, the Product Owner, and the Development Team. In Scrum you don't have separate QA testers, UX people, designers, BA's and coders. The Development Team is meant to be cross-functional and multi-skilled, and there aren't supposed to be any "skill silos" where people only do a particular job. Those silos are an invitation for team members to be waiting on each other instead of "going to where the work is" and getting the work done. In Agile terms skill silos are a type of waste, and one that needs to be optimised away by cross-training.

Now, that's all fine and good as far as Scrum theory goes. In practice though a great many...perhaps even most...organisations will merrily break these rules. In my experience it's very common (I would say normal) for a separate and distinct QA or tester role to be included in an Agile team. Separate BA's are also very common. Why? Because it is recognised across industry that Testing and Business Analysis are valid careers in their own right. All you have to do is to look at the jobs boards to confirm that. There are plenty of positions advertised for Testers and BA's, and for which some sort of "agile experience" is required. I'll leave you to work out how many of those organisations would *claim* to be following Scrum.

So the project you have described breaks Scrum rules, but if it is any consolation I certainly recognise the situation you are in. The question is, what can you do about it?

Breaking down those silos by cross-training all 12 people would be a huge challenge. Not only would it mean training QA experts to be developers, it would also require PHP developers to be Ruby programmers, vice-versa and contrariwise. It would be fantastic if you could get buy-in for all that, but the short to medium term hit would be huge, and the individuals concerned might not have the appetite to stray so far from their comfort zones.

But perhaps it would be possible to "box clever" and temper cross-skilling with some refactoring into 2 or 3 smaller development teams. Those development teams would then, in aggregate, comprise a Scrum of Scrums through which releases would be co-ordinated. The Product Owner and ScrumMaster would work across all development teams.

I'd try and keep the development teams focused on the technology area (1 for PHP, 1 for Java, 1 for Ruby). That would at least reduce the technical skill silos *within* each team. I'd think about having the QA, BA and UX experts assisting the PO so he or she can understand the product requirements and make credible decisions about it, including the acceptability of incremental releases.

This isn't ideal, because it means crafting a Definition of Done for each team that only takes an incremental release as far as deploying into a QA environment. There'd be a lot of work to do at a Scrum of Scrums level to manage the release train and to mitigate the risks around integration testing, and also to ensure that release feedback / lessons learned makes it to the relevant team for consideration.

I hope that the above is of at least some help to you. If not, I might refer you to the DSDM method which has a wider range of roles than Scrum, and supports larger team sizes. It's less operationally focused than Scrum but it could provide some initial process and role mappings. Whatever you decide, let me reassure you that your situation is by no means unusual, and that knowing how and when to compromise is half the battle in Agile transitioning.


08:00 am December 10, 2012

Hi Ian,

Thank for the response.

As mentioned, at this point in time I'm unable to split the teams due to resource (it wouldn't just be the PO & SM that would be shared across stream, it would also be the BA, UX & design).

Splitting the team by development discipline is a good idea though and I'll bear that in mind for such a time as splitting is allowed.

As a development team we are well along the agile transition path. My main battle is with management outside of the development team and trying to keep them to agile principles.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.