In a recent blog post my colleague Steven asks the question, “Do Teams of Cross Functional Individuals Hide Dysfunctions?” This grows out of some conversations we’ve had around the office about the intended meaning of “cross-functional” and whether it’s a virtue or a vice.
When I joined Northwest Cadence, which as we’ve established was not so long ago, I found earlier training materials referring to the need for “generalists” in Scrum, and some diagrams showing how team members might shift to other types of tasks during a Sprint. But since my formal training in Scrum has been more recently, I recalled that the Scrum Guide calls for the team to be “cross-functional, with all of the skills as a team necessary to create a product Increment” (emphasis mine). As I read it, this means the Development Team should have all the skill sets represented that it needs to complete the work of the Sprint, but it doesn’t say a thing about every team member needing to possess every needed skill, or even multiple needed skills. (What if what the Development Team really needs in a Sprint is a specialist?)
Anyway, around the office we’ve started making the semantic distinction between “cross-functional individuals” (generalists) and “cross-functional teams” (generalists or specialists or a combination of both who provide in aggregate the needed mix of skills).
In our Scrum vs. Kanban Smackdown on Friday, Steven and I dug into the issue a bit more, and he mentioned that while single cross-functional individuals are less productive than specialists, he found it curious that the opposite is true in teams: teams of cross-functional individuals are more productive than teams of specialists. (Source: Capers Jones, Applied Software Measurement.)
It seems to me that there’s a delicate balance to be achieved between focus (preventing context-switching) and flexibility.
Particularly in Scrum, it’s critical to have a cohesive team, and one of the strengths in Scrum is that the team learns to work together more efficiently over time. A Scrum team’s membership should strive to stay stable. But given that the Product Backlog and the Sprint Backlog’s contents are variable, how can the team maintain a stable membership while ensuring it has all necessary skill sets for any work that may be thrown at it?
In Kanban, of course there’s no prescribed process: the first step is to visualize the existing flow of work, identify bottlenecks, and then address bottlenecks to promote flow. Again the question is, how should the team address them, especially over time as a variety of development items enters the work stream?
I think there’s no simple answer, but I have a few ideas, and I think they’re potentially equally applicable to Scrum and Kanban.
- Swap Out Team Members. I think this is a non-solution for both Scrum and Kanban. If we weren’t trying to build more effective teams, we wouldn’t be here, right?
- Balance the Backlog. Items in the backlog or queue should already be right-sized and should represent standalone stakeholder value. If the team works from a consistent Definition of Done, then it should be possible to figure out what skills are needed to deliver a particular item – and to break down an item if any stage of its delivery is too big for the team’s capacity. However, this won’t always be perfectly possible: for example, some features may lend themselves to more test automation, while others demand more manual test, and these call for different skill sets on the team.
- Negotiate. In Scrum, the Product Owner and the Development Team work together to select the Sprint Backlog and they don’t always have to select the stakeholders’ highest priority items. If it makes sense, they can pull a different mix of items into the Sprint to keep the workload balanced to the team’s capacity. Similarly, a Kanban team can pull new work into the work stream for any reason at all, and can choose to pull items that balance better with work already underway. However, this must not be used to mask dysfunction, especially because it risks taking the team too far afield of the stakeholders’ priorities.
- T-Skills. Team members who have needed depth in a few areas, but breadth and willingness to help out in others (“T”), can give the team the flexibility it needs to accommodate shifting Work In Process loads. I think this is what most people really mean when they say “generalists”. This can be effective when role-based bottlenecks are occasional and temporary. However, this must not be used to mask dysfunction; if team morale is affected or the team resists seemingly reasonable calls to “swarm”, that’s an indication that their willingness to flex is being overused or abused.
- Expose the Pain. If the team’s skill sets are out of whack due to external constraints, it may be to the team’s advantage not to solve or compensate for this problem. Instead, making the effects of the imbalance transparent to decision-makers and stakeholders may be what’s necessary to get a real lasting fix.
Elastigirl rocks, but she still values her team.
In all cases, the entire team needs to be involved in and accountable for the solution, and as you see from some of the ideas above, the solution may need to start well before the work hits the dev/test phases of the team’s process.
