...copyright Elena Yatzeck, 2010-2017

Sunday, January 22, 2012

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.

Sunday, January 15, 2012

Road Rage: You and Your New Agile Teammates

As you join your teammates in your sparkling new agile team room, and you all do your best to quickly "become agile," I guarantee that despite being surrounded by brightly colored index cards and sticky notes, you may sometimes feel...angry.  Here you are, supposedly liberated to be "self managing," out from under the collective thumbs of your corporate hierarchy, and you realize that you are reminded briefly of the Lord of the Flies

Your agile pilot has quickly, as promised, surfaced all possible risks and issues to the project.  That idea sounded good on paper.  In real life, you have ripped the comforting blanket of denial from yourselves, and now, rather than waiting for the UAT team to take the bulk of your business users' thwarted fury eighteen months from now, you already see problems right at the beginning of the project, where you've never seen them before:
  • Inappropriate cost estimate
  • Unrealistic project schedule
  • Slap-dash business case
  • Conflicting time demands on team members
  • Balking integration partners
  • Lack of air circulation in the team room
  • Unhealthy snacks
And you need to deal with those things now, not later.

If you escalate the issues now, as requested by your starry-eyed manager from behind his copy of Agile Software Development:  The Cooperative Game, will you be the messenger who gets shot?  Or do all of your line managers actually intend to support you?  You haven't been through this before.  You are under stress, you're on edge, and yes, that may sometimes make you feel...angry.

Like the Ben Stiller character, Mr. Furious, in the classic 1999 movie, Mystery Men, you want to caution everyone, "Don't mess with the volcano my man, 'cause I will go Pompeii on your... butt."  Indeed.

What should you do?  I've experimented successfully with spritzing rose-scented essential oils around myself, but my best guidance in this area comes from the unlikely source of a brochure I read at the office of the Illinois Secretary of State several years ago on the topic of Road Rage.  I found the equivalent online here, although the original was better, because it included a multiple choice self-test at the end with some awesome questions.  One of them was along the lines of "if someone cuts you off, and you find yourself behind them at a long stoplight right afterwards do you..." and the correct answer was not "approach their car with a baseball bat."

In the agile team room, here's what Illinois Secretary of State Jesse White says you should do, (or what he would undoubtedly say, if he were talking about agile software development instead of driving.  I've taken the liberty of substituting a few of the key nouns):

How to Avoid Becoming an Aggressive Agile Team Member
  • Keep your emotions in check. Don’t take your frustrations out on other team members.
  • Plan ahead and allow enough time for delays.
  • Focus on your own contribution. Yelling, pounding on the conference table and honking the nose of your coworker won’t make the project move any faster.
How to Avoid Danger

First, be a cautious, considerate team member. Avoid creating a situation that may provoke another agilist.

Second, if you do encounter an angry person, don’t make matters worse by triggering a confrontation.
  • Avoid eye contact.
  • Steer clear and give angry teammates plenty of room.
  • Don’t make inappropriate hand or facial gestures.
  • If you’re concerned for your safety, call 9-1-1.
We're all in the same traffic, you guys.  I promise you it will get better.  Go ahead and let your groundhog drive.  But as Bill Murray says in Groundhog Day, "don't drive angry."