Skip to main content

No-Blender Zone: Cross Functional Doesn't Mean Homogenous

In the glory days when giants still walked the earth and the Agile Founding Fathers created "the team," they decreed that there would be three "team roles:"
  • The Product Owner
  • The Scrum Master
  • The Team
The product owner would be omnipresent and omni-knowledgeable, the scrum master would (somewhat mysteriously) "move boulders and carry water," and the team itself, the AFFs explained, would be "cross-functional."  Without being told how, the team would just swarm around the work and get it done:  analysis, design, development, testing, release, the works.  Boo-yah!

It's a seductively simple fallacy of division to interpret the concept of "cross functional" team to mean a "collection of cross-functional individuals."  New agilists are quick to apologize that "we still have functional silos here" as though it would be much better if everyone could do all the same things.  Grab some equally skilled poly-functional people, have them all take turns doing all of the jobs as needed, and you'll all laugh your way to on-time, high-quality, and valuable working software.

Not so fast!

The power of an effective agile team, like the power of any other effective team, doesn't come from its homogeneity, but from its ability to harness its diversity.  What does this mean?

  1. If there is commonality, it needs to be respect for differences.  I fear that in practice, the concept of "team role" without sub-roles sometimes boils down to a belief that developers can do everything, and everyone else on the team is a helper or parasite of some kind.  That's putting it too baldly, but it sometimes seems a little like that.  It is not okay for anyone on an agile team to say "you don't need..." anything.  If you're not a developer, you don't know what developers need.  If you're not a tester, you don't know what testers need.  No matter what your role, you need to have humility and respect towards others with different abilities than your own.  Keeping that prerequisite in mind,
  2. A different job title may imply a whole different world view and set of values.  This is a good thing!  Your agile team is at an advantage if it starts with this realization, and works to communicate across different perspectives rather than ironing them out.  Developers, testers, business analysts, and the rest are not typically "all the same under different skin."  They're all different under different skin!  There may be patterns.  Look for them and marvel.
  3. Today's technology world is specialized.  You want best in class, not the least common denominator.  Team members shouldn't attempt to Harrison Bergeron themselves into a mish-mash of mediocre (but working!) software.  Someone needs to facilitate the stakeholders into some sensible semblance of a business case.  Someone needs to build functional test suites that mercilessly beat on the code to prevent it from breaking in production.  Neither of these are exactly the same skills it takes to gradually evolve the design of a complex system in modules of 100 lines of code or less.  If people want to try new things, that's great, but it needs to be with the realization that other jobs on the team are actual professions with skills and the need for experience in order to excel.
I know there are agile teams out there who function without even a scrum-master--just a small group of really smart developers in a room with a product owner.  That is great!  But that is not a "norm."  The norm is a diverse group of people getting work done in a way that builds on their existing knowledge and preferences.  The diversity reduces risk and increases quality (both fit for use and fit to design).  Some things just don't belong in a blender.


Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…

How To Write A One-Page Proposal to an Executive

One day you may need to communicate with an executive. Pro tip 1:  executives do not have time for you to dim the lights and show them forty slides with charts composed of animated dancing leprechauns and flashing arrows that emerge from the void in a checkerboard pattern. Pro tip 2:   Guys, and gals with deep voices, executives also don't need you to use your "Radio Announcer Voice."

As a rule, what executives want is simple: one printed page. No matter what it is, it should be one page. And it should be printed, not emailed.  You should plan to hand it to the executive, and then you should be quiet when they read it and wait for their questions.  It's harder than it sounds.
 So how do you do it?  Here are the steps:
Write the deck that expresses your proposal in as many slides as it takes.  Use imaginative animation and blinking letters if you must.Remove your title slide.Insert a new slide at the front of the deck with "Appendix" written on it in big …