On Cross-Functional Teams Held Accountable as a Unit

A common problem I see companies – both old and new to Scrum – face is an understanding and execution on the idea of cross-functional teams, and the associated idea of holding a team, not individuals, accountable as a unit.  Struggles in this area commonly lead to:

  • Individuals remaining highly specialized, often identifying themselves as their role (“I’m a tester, so I [should do x] and not [do y]”), instead of as a team member.  This problem is even worse if this is how they are incentivized (e.g., coders are rewarded for slinging code, not for making sure done, quality software is releasable as soon as possible, testers are rewareded for finding bugs, etc.).
  • Sprints looking like miniature versions of a waterfall project – do some design first, then code, oh, and the testers obviously couldn’t do anything until the coders are done…
  • These first two naturally lead to activities with heavy phase gating, where “throw it over the wall” is the method of (non-)communication between gates.
  • Teams remaining in a lot of wait states, because they’re waiting for [specialty x] to handle [job y], because they’re “obviously” the only one qualified (or even worse, “authorized”) to do that.  Oh, and since the specialties are so strictly defined, it doesn’t make sense to pair up to tackle a problem.  For example, “As a coder, I can’t start working on this bug until the analyst has told me exactly how to reproduce it.”

By contrast, where I’m working with a team that is effective as a unit here are some of the ideas and activities I see:

  • Individuals are respected for their specialties, but they are also expected to go beyond their comfort zones.  They identify as team members, and are willing to do what it takes for the team succeed – whatever that might be.  Yes, a coder might help with testing, and a database specialist might proofread the technical writer’s copy.  And yes, that happens even if their individual functional managers are obsessed with “correct utilization” – because that’s what the team needs at the moment.  Ultimately, stakeholders want working software (not “done but not tested” or “done but not ‘done done'” stuff).  That may or (usually) may not have anything to do with some line manager’s idea of “correct utilization.”

Even Alex Rodriguez, generally accepted as one of the most selfish and detached baseball players of all time, “contributed where needed” by moving from Shortstop to Third Baseman…

CC BY-SA 2.0 - Keith Allison - https://www.flickr.com/photos/keithallison/ Here’s a little story to demonstrate this principle.  Even Alex Rodriguez, generally accepted as one of the most selfish and detached baseball players of all time, “contributed where needed” by moving from Shortstop to Third Baseman when he was acquired by the Yankees, where Derek Jeter was already established as Shortstop and team captain.  “Correct utilization” in Rodriguez’ case could have looked like, “the money spent on Alex must go towards his contributions as a Shortstop, because that clearly is his best / most experience-backed defensive position…so if we don’t have a need for a Shortstop, it’s not the best use of our money, so don’t acquire him.”  I’m guessing Yankees fans were pretty happy that wasn’t the rationale and allocation / utilization strategy that was actually used.

Did the Yankees expect Rodriguez to be the best Third Baseman ever?  Better at Third Base than at Shortstop?  More comfortable there?  I hope not, at least not initially.  Third Base is about playing the “hot corner” of sharply hit balls (hand speed), long throws to first, and knowing when to bare-hand slow-rolling grounders.  Shortstop is about range, leadership, and working in tandem with the Second Baseman.  But whatever his shortcomings may have been at his new position, they knew that having him playing at a less-than-ideal defensive position was better for the system (which would include offense, not just defense) than not having him at all.

  • The diminished focus on specialist roles allows more natural interaction between the different specialists, where testing informs coding, coding informs architecture, architecture informs testing, testing informs analysis, etc. – any and all possible permutations.  There is no waterfall of phase-gated activities – there are the right interactions at the right times with the right sequence – where “right” is determined empirically by the people closest to the work, not by a process or dictate.  This is how software is actually built in the real world, even if you pretend to have strict phase gates – the difference here is we’re going to acknowledge and optimize for that, instead of insisting that separation exists and treating any lack of separation or any need to iterate back over ideas as “problems.”
  • With more natural interaction between specialties, the “throw it over the wall” and “not my problem” phenomenon start to fade away.  Where there were things that were treated like strict, detached handoffs in the past, we now see at the very least informative walkthroughs between specialties, if not outright collaboration in building the artifacts at hand.
  • This sort of collaboration – pairing, swarming, mobbing – eliminates handoffs, because multiple people have their hands on something at once.  There are far fewer wait states, because the team as a whole relentlessly focuses on the most important work at hand.  No analyst available?  What can we learn on our own to start?  Who can we talk to?  How can we leverage the inherent low risk of our small batch (determined by Sprint length) to do something that makes a reasonable amount of sense, even though we still wish we had someone with this specialty around?  Asking these questions become both a cause and an effect of a team who feels empowered, motivated, and accountable.
  • Team members start to realize that underneath, they’re all doing the same thing – discovery, experimentation, and building something to satifsy users.  Designing the right architecture involves understanding the user’s needs and the product’s vision (Architect <-> BA <-> PO).  Coding is judged by whether it works and whether it solves the user’s problem – i.e., the cornerstones of testing, verification and validation (Programmer <-> Tester <-> BA <-> PO).  Good architectures allow for the testing of the most granular structures to the most coarse (Architect <-> Programmer <-> Tester).  Test cases start out very abstract and declarative, and move towards detail and imperativeness – just like the implementation of a feature in code itself (Tester <-> Programmer). We’re not only on the same team, we’re all doing the same thing.  Our specialties are merely dimensional views of the same thing, with the same goals.  We have more in common than we do in difference.  We are discovering, experimenting, and building valuable, high-quality solutions to delight users.  All of us.  Together.

We’re not only on the same team, we’re all doing the same thing.  Our specialties are merely dimensional views of the same thing, with the same goals.  We have more in common than we do in difference.  We are discovering, experimenting, and building valuable, high-quality solutions to delight users.  All of us.  Together.

Again, the value or breakthrough here isn’t that idea itself, because that’s always been true – the value and difference is acknowledging and optimizing for that fact, instead of pretending it’s not true.

In the future, I plan on writing some posts that talk about specific, detailed expectations that can be set for team members, regardless of specialty, and the sort of behaviors that these expectations engender.  Stay tuned…

Leave a Reply

Your email address will not be published. Required fields are marked *