Skip to main content

Cross-functional vs. Component teams (and the use of guilds)

Last post 12:29 pm June 13, 2024 by Joeri Mastop
4 replies
12:10 pm June 12, 2024

Hi all,

Looking for any insights or experience with transitioning from component- to crossfunctional or value-streamed teams. I'm working as a scrum master in an IT department, infrastructure side of things (no software development). We currently have several teams split by component or expertise area (networking, serverhosting, storage, etc.). I'm trying to advocate the advantages of aligning product definitions and valuestreams with the way teams operate. 

The way I see it: for each 'product' or service that we provide to others, we need almost every team to do 'something'. Only combined does it have real value. Most engineers feel that too: they are disconnected from the product chain, and have little to no contact with end-users or stakeholders. An earlier idea I posted with the department to create value-aligned teams mainly died due to heavy protests by the engineers themselves. They feared that they would lose the freedom or width of their expertise. "If I'm an expert on networking, why would I want to do it in a team that only delivers the workplace environment? The datacenter is interesting too. I want to do everything networking related over the full width of the organisation."

A guild or other means to bring people of the same skill-set together could be a solution perhaps. Or to let people change teams every now and then. There's probably many ways to do this, or many reasons not to. Curious to hear what you have encountered, or if you have had a similar experience.

01:42 pm June 12, 2024

The way I see it: for each 'product' or service that we provide to others, we need almost every team to do 'something'

That might be the way you see it, and you are very likely right, but what transparency have you established over integration dependencies? Others will need to see these too, because if they are to create a Done increment each Sprint, the integration dependencies between teams will need to be self-managed.

01:56 pm June 12, 2024

Fair point. We have a separate 'team' consisting of scrum masters and an agile coach, to monitor issues on the various boards that show a dependancy towards other teams. But since most teams have established ways to manage that (e.g. a support ticketing system to assign work to other teams) it is very difficult to create that transparency. Also, the urgency is not very apparent to the teams, since the pain of slow release is felt by the end-users, but communicated through layers of managment and business relationship managers.

But thanks @Ian for pointing this out: the key is to make the integration dependencies transparent.

11:40 pm June 12, 2024

As a first stab, set the value stream aspect aside seeing the engineers want to work across the organisation. Cross-functional teams and value-streams don't need to go hand in hand. Cross-functional teams can exist independently from value-streams. 

Then build cross-functional teams having team members with all the expertise in a team. Instead of having a networking, server hosting and storage team etc, build teams with at least one member with knowledge in each specialisation area, thus having a team with a networking specialist, a server hosting specialist and a storage specialist etc. (People can share specialisations or learn new ones from other team members.) Allow these teams to pick up backlog items from across the organisation. Each team has the capability then to take an backlog item from start to finish, instead of each backlog item having to move from team to team. 

This concept was also introduced in manufacturing. Initially one person only worked on one component and that was replaced with a team of people, combined having all the knowledge to build a car. 

12:29 pm June 13, 2024

Thanks @Pierre. Maybe I'm setting the bar too high. Although there is some resistance against working in value-stream teams, I do expect some engineers actually want this to happen. We could try and ask people of they would be interested in taking part in such a team, find something useful and valuable to work on, and take it from there.

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

Please note that the first and last name from your 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. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, 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 may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.