Skip to main content

Managing knowledge distribution across a Scrum Team

Last post 08:07 pm October 12, 2022 by Ian Mitchell
2 replies
07:39 am October 12, 2022

We are a Product team delivering DevOps tools for internal use within our organization. The work in the product team usually involves installing, configuring, testing, integrating, and deploying the DevOps tools. We were a small team (around 4 devs) until recently. We have now increased to 8 devs. When we were a smaller team, we had decided to become "generalists" i.e. everyone could work on any of the DevOps tools. Now that we are 8 devs, it's going to be difficult to continue with the generalists concept.

Are there any known strategies for managing knowledge across the team? 


08:02 pm October 12, 2022

One option may be to better define the products that are part of your "DevOps tools". A product may consist of multiple tools, but you could organize these tools into discrete products and build teams around supporting teach product.

Another option could be to organize around value streams. Each team may work in multiple tools, but would serve a particular set of end users or customers of those tools. If a customer doesn't use a tool, they may never need to touch that tool for their development. They can become deeply familiar with the people who use the tools and optimize their work for that particular audience.

There may be other options, as well, but I'm not sure that you could split fully. For example, if your tools are on a common platform, splitting out a platform team and having other teams focus on individual tools, small groups of tools, or value streams.

I would recommend Team Topologies. On the surface, it seems like reorganizing your people into better teams would give you what you need, but if your environment and architecture don't support it, splitting into smaller teams could introduce cross-team dependencies which would introduce management complexities.


08:07 pm October 12, 2022

How much of a generalist does a Developer need to be? Do you have a feeling for that, and of the degree of cross-skilling required before the team's workflow becomes impeded?

Remember that maintaining a range of skills can be expensive, and the cost of being a generalist is not necessarily justified. Often it is enough for a Developer to have one or two additional disciplines. Ideally, this would allow them to assist and smooth the flow of work at the boundary of their core discipline, when bottlenecks or starvation seem likely to occur.

For example, in the workflow you describe of:

installing, configuring, testing, integrating, and deploying

a test specialist might acquire T-shaped ancillary skills in configuration and/or integration only.


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.