Cross-functional vs. Component teams (and the use of guilds)
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.
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.
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.
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.
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.