Estimated Reading Time: 2 minutes
Improving teams/organizational flexibility/versatility is a topic that comes up often in my engagements. This includes discussion of T-shaped people/teams, Collective Ownership, Code Stewardship
, Full-stack-developers and the like. I typically refer to Henrik’s classic
(and recently my “scaled” version
So let’s assume you improve the agile team flexibility which means you can “swarm” a couple of teams to areas in high demand. How do you deal with their product ownership/management in those cases?
Let Product people stay with their product
One alternative is to keep the Product Managers/Owners more specialized and focused on a business/product area and basically give them more teams to work with. This obviously has limitations. Product Managers/Owners are human as well and have capacity limits…
Home team offloads some Product responsibilities from the Product person
This can work when the “home” development team that typically works in that area can take on more Product responsibilities and free up capacity for their Product person to work with other teams that have less Product knowledge. This would require the team to grow that Product capability as part of their “T-Shaped” team/people investment.
T-Shaped Product People
Another alternative is to have Product people swarm as well. They could also use a Skills Matrix to help them see how far they are from being able to help each other. You might be thinking – Product people are much more specialized, have customer/user relationships, so cannot really help each other. But we know we’ve been hearing these sort of statements from developers for years now. And yet it is possible to grow towards being T-shaped developers. And I’ve seen T-shaped Product people as well.
These are the ones I’ve seen and can think of. Can you share another alternative from your experience? Which of the ones I’ve mentioned have you seen out there? Are they working well for you? Leave a comment and let me know.