We’re back after an insane May teaching CAPED (Complexity-Aware Planning, Estimation, & Delivery) workshops, including our flagship Certified CAPED Consultant course in Boston and our new CAPED Team Leader course at a client in the Bay Area. CAPED Team Leader is our successor to the ScrumMaster course, much more oriented towards real-world agile team leadership on complex initiatives. We also kicked off a cohort of Advanced CAPED Product Owner, our successor to A-CSPO. Lots of exciting new and refined content. And going back to in-person workshops has been both exhilarating and exhausting.
Watch for more info on our full suite of CAPED courses and certifications in the coming weeks. These courses are the best of what we’ve been practicing, testing, and refining over the past two decades, and we’re eager to share them with you.
About a month ago, I asked our readers if your team is sufficiently cross-functional to deliver a complete increment of value.
A little under a quarter of responses indicated, “yes, my team is sufficiently cross-functional to complete vertical slices.”
The other three-quarters indicated their team is not fully cross-functional but were split in half about whether that was fine or something that should change.
We’ve worked with a lot of teams in a lot of different contexts, so I expected to hear that many teams were less than fully cross-functional. I didn’t expect the percentage of fully cross-functional teams to be so low.
In future weeks, we’ll share our recommendations for how to nudge team structure in the right direction, especially if you don’t have the power to just decide to make that happen. This week, I want to share some initial reflections on the results of this poll, based on our experience with team structure in lots of different contexts…
If…
- working in small, vertical slices of value is the keystone habit that makes all of the rest of the agile stuff work, and
- only a quarter of people who responded to that poll said their team was set up to use that practice, and
- our mailing list probably selects for people trying to practice agile software development well
…then it’s no wonder people are a bit jaded about agile these days.
To get the results people say they want from agile, it is essential to shape the work to deliver incremental value and to design team structures that support focus and collaboration on that work.
For those of you who have that team structure already, don’t waste it! You have a surprisingly rare opportunity to work in small slices of value, building learning and impact into your work every day.
For those of you who don’t have a functional team but would like to, I’ll share more advice in the coming weeks, but here’s my #1 tip to start nudging things in the right direction: Make it visible. If you can’t fix it, make it visible. In this case, making it visible means identifying the actual value you’re contributing and tracking how it moves between teams and how long it takes to go from start to finish. Work that spans teams often has a cycle time 10x longer than the same work done within a single cross-functional team. Showing real data about that often convinces leaders to adjust team structure.
Thinking about the “not cross-functional, but it’s fine” responses… I don’t have context for those votes, but in my experience, there are three situations where that’s actually true.
- When value comes from two or more very distinct kinds of work being integrated. The classic example is hardware and software. Some products only deliver marketable customer value when both hardware and software components work together. But putting, say, mechanical engineers and software developers on the same team is usually clunky. The work is so different and runs at such different paces that you end up with two virtual backlogs and two virtual teams pretending to be one team. Better to separate out the work, coordinate closely, and integrate frequently.
- When your definition of “cross-functional” is bigger than it needs to be. Some skills are needed sporadically or at very predictable times. In those cases, if the skills are available from outside the team when you need them, then you can have a sufficiently cross-functional team without those skills on the team. A classic example is IT skills like server management on a software team.
- When part of the stack is outside your org. I’ve worked with teams who deliver a service that gets used by multiple outside teams to ultimately deliver value to end customers. It’s still good to think about your work from the perspective of the end customer, but you’re not likely to build a team around that whole stack.
There’s a fourth case that can go either way: The platform or shared component team. If the platform or shared component is mostly non-functional and independent of functionality in the products that use it, this can sometimes make sense as its own work stream. For example, a logging and monitoring component used by various applications in an org.
But much of the time, a shared platform or component is more closely related to the functionality that uses it. And in those cases, it’s often better to have shared ownership among the teams that use it and to layer on a structure for coordinating across teams to keep the shared component aligned.
Did I miss a case? Reach out to tell me about it.
Finally, to those readers who voted “not cross-functional, but it’s fine” mostly because you’ve given up hope of change, I want to encourage you that the right team structure really does make work more effective and more engaging. It’s worth nudging in the right direction. Leaders, team members, and customers all benefit when orgs get this right, but sometimes it can be hard to see how to make it happen. Start by just making the current state more visible, and see if that creates any interest in change.
Last updated