...copyright Elena Yatzeck, 2010-2017

Saturday, September 24, 2011

Eleven Improv Commandments for Agile Teams

Improvisational comedy techniques have been making their way into agile training discussions for some time.  The UK (and beyond) Agile Coaches Gathering devoted their 2009 autumn meeting to "Improvisation for Agile Coaches."  Planning for Failure's amazing Todd Charon did this wonderful lightning talk in 2010.  And this week, Lisa Crispin posted an enthusiastic review of Mike Sutton's half-day improv session for AgileCoachCamp US.

From Del Close's skull's MySpace Page
I've always felt happier belonging to the "yes-and" teams much more than the "no-but" ones, but and I wanted to see for myself how improv philosophies and techniques could provide a useful framework for agile/lean software development.  So, inspired by Lisa, here's what I found out.

Most inquiries into improv lead to Del Close, granddaddy of Chicago-style improvisational comedy, and co-author of Truth in Comedy:  The Manual of Improvisation.  Del famously bequeathed his skull to Chicago's Goodman Theater, to be used as Yorick in productions of Hamlet.  His co-author and executor, Charna Halpern, was unable to obtain his actual skull and was forced to donate a purchased replacement, which skulduggery (sorry) was subsequently unearthed (again) by The Chicago Tribune and reported on with great amusement by The New Yorker in 1999.

Del had what he called "the Eleven Commandments" of improv, encompassed, more or less, by this list:
  • You are all supporting actors.
  • Always check your impulses.
  • Never enter a scene unless you are NEEDED.
  • Save your fellow actor, don`t worry about the piece.
  • Your prime responsibility is to support.
  • Work at the top of your brains at all times.
  • Never underestimate or condescend to your audience.
  • No jokes (unless it is tipped in front that it is a joke.)
  • Trust... trust your fellow actors to support you; trust them to come through if you lay something heavy on them; trust yourself.
  • Avoid judging what is going down except in terms of whether it needs help (either by entering or cutting), what can best follow, or how you can support it imaginatively if your support is called for.
Do these apply?  Well, it's not clear in the software development context that jokes shouldn't be allowed, unless the team includes a particularly bad punster.  But with that specific caveat aside, these rules are wonderful for describing how to behave when you're part of a team, not an individual achiever.

In particular, the advice to trust, avoid judgement, provide support, and check impulses seems like it would go quite a long way to create a team where everyone would want to be working with the best part of their brain at all times.

What I like the best, though, is the advice to "save your fellow actor, don't worry about the piece."  The example Todd Charon provides in his YouTube video is of a case where a troupe was performing on a slippery stage, and the first person went out and fell off a chair while pretending to screw in a lightbulb.  Without hesitation, a second troupe member ran out on stage and did the exact same thing, turning a potentially embarrassing and show-stopping moment into "part of the show."

There are a lot of lessons for us in this vignette about a unified and supportive team stance in face of adversity, and about how to communicate with stakeholders in a face-saving way at all times.  But at the end of the day, what I like about this advice is that as you look over the course of your career, you really DON'T care if this project or that one succeeded or failed.  Even my successful software projects have been rendered obsolete by the passage of time.  I think fondly of the Dbase III purchase request generating system I wrote in 1985, for example.  But what matters over time is the relationships you build with the people around you.

I'm pretty sure "focus on the present" is another rule of improv which holds very true for agile software development teams.  But how nice that this art form shows how focusing on the present sets you up well for a life well lived.

Thursday, September 15, 2011

What do women (in technology) want?

I have the honor of serving on the ThoughtWorks North America "Women's Networking Board," WNB, which focuses on bringing more women into our company, particularly as developers, and supporting them well once they join us.  ThoughtWorks isn't alone in thinking about this issue.  The US National Science Foundation (NSF) has sponsored research on "Gender in Science and Engineering" (GSE) for more than a decade, and a google search on "women in STEM" (that's "Science, Technology, Engineering, and Mathematics") provides a large number of useful responses before it devolves into pyramid schemes and pornography.  As all searches tend to do.

As part of my WNB duties, I've been interviewing my female colleagues on what motivates them to work at ThoughtWorks, and what they would like to see the company do to attract more women.  These conversations have been fascinating.  As an academic I once knew liked to say, "facts are friendly."  (He was a high-functioning psychopath, sadly, but I still like the quote).

Here are some preliminary insights I've gotten into the "STEM problem" from asking actual women about technology:
Agile software development is more social than most other methodologies.  I don't want to generalize that women are more social than men, but many women are repelled by the idea of working in a basement filled with black vinyl chairs, pervasive oversized gaming headsets, the stink of ancient sweat socks, and companions who grunt as their primary mode of verbal communication.  Companies (like ThoughtWorks) who do agile software development using small teams gathered around tables, encourage paired programming (and pairing of BAs, Devs, and Testers), often with access to daylight and herbal tea, should make themselves known to the female audience.
Companies who are trying to hire more women developers should advertise that fact.  It is empirically true that there are organizations out there where no sane person would want to be a woman developer, due to a pervasive misogynistic culture.  But there are plenty of companies (like, well, ThoughtWorks) who are NOT like that.  They too should make themselves known to women.  Women, like other people, respond well to a positive invitation.  Companies can differentiate themselves in the market by appealing directly to the female audience by reaching out to self-identified organizations such as the annual Grace Hopper CelebrationWomen in Technology International or Women 2.0.  
You can appeal to would-be female STEM-ers even at the high school level, if you are a company that is woman-positive and you offer agile development opportunities.  I tested this empirically over the past months by trying different appeals to a young woman of my acquaintance who is taking two hours of AP calculus and one of AP Chemistry per day--as a high school junior--and who tells me she "hates science" and "doesn't want to be a software developer."  I suppose she'll eventually take over the world instead, but here's what she suggested we all tell our overachiever high school women friends to get them to consider a job as a developer:
  1. "It's just like a co-ed study party."  Stress the social, group-effort aspect of computer programming.  Crush the stereotype of the fetid male-only dungeon.  
  2. "It will differentiate you on your college application."  
I can confirm that the recalcitrant young woman has now agreed to attend one week of computer camp to learn java next summer, just by being exposed to these two sentiments.  As she pointed out to me, if programming isn't for any individual, little harm can be done by presenting these messages.  But women who might not otherwise even try programming to see if they like it can be brought to the table with these two irresistible lures:  group effort and enrollment at the selective school of their choice. 

I would like to close with this cartoon from the inimitable Saturday Morning Breakfast Cereal:

Sunday, September 11, 2011

Don't Be a Hero

Do any of these resonate with you?
  1. Are you the lone sane person in your company at your level or higher?
  2. Do you "call BS when you see it," in the words of Jonathan Rasmussen, the Agile Samurai,  while everyone else is "just keeping their heads down" (er, "low")?
  3. Are you protecting your team, because without you, something bad will happen?
Well, give it up.  I'm serious.  In a modern corporate enterprise, the way of the hero is the way of burnout, madness, and defeat, generally followed by a worrisome period of unemployment and perhaps an eventual new job in Oklahoma.  Joseph Campbell's monomyth may sketch this journey, but put me on record suggesting when you get the call to adventure, you should send it straight to voice mail, because the uphill slope on the left is a doozy.

Far be it from me to suck all the fun and adventure out of your work life, however.  There is an alternative to being a hero.  It's called "being diplomatic."  In its own way, it is even more fun than calling BS when you see it.  Imagine the challenge of NOT calling BS when you see it, and still getting your way.  THAT is the best fun of all.  Here's how it works:
  1. Deliver territory and face, not just value (and most certainly not just "working software").  The currency that matters to people with power in a corporate environment is "saving face" and "accumulating territory."  Delivering business value to the company is not an end in itself--if you as an agilist are offering merely a good return on investment, you aren't going to capture the interest of most corporate executives.  If you are working with a "courageous executive" who is actually motivated by running a business well, then certainly trot out your proven ability to deliver.  If not, figure out what your targeted executive personally has to win or lose through the application of agile philosophy and practice in her area, and make your appeal in those terms.  Under no circumstances ever use the phrase "but that doesn't make any sense."  Not helpful.
  2. Corollary:  logic might (not) be your friend.  Sales people will tell you that potential clients are convinced through emotion, not logic.  If logic works, then it's because you've hit upon a listener whose emotions are triggered by logical arguments.  If it doesn't, do not despair--just try something else.  If your goal is to help your business customer deliver good return on investment, ironically, the best way to convince her may be to talk instead about how you are best pals with her arch-rival in Budapest, and you can keep her one step ahead of that crazy, out-of-control moron.
  3. People really are more important than process.  That means you, not just the people you want to convert to your agile philosophy.  It's more important for you to preserve your relationships than to keep your teams' noses to the agile grindstone.  If they want to call it a "supersonic delivery monorail" instead of a "release plan," get out the Disney posters and the mouse ears, embrace the creativity, and free your teams to jump on that futuristic vehicle.
Agile theory will tell you to measure success and failure in terms of a whole team, rather than one overachieving individual.  But like gravity, it's not a suggestion--it's the law, if you care for the sanity and well being of the individuals who make up the team.  When you mutter to yourself, "there's no 'I' in 'team'," you want the phrase to be metaphorical, not literal.  As Paper Lace put it so poignantly in 1974:  "Billy, don't be a hero.  Come back to me."

Friday, September 9, 2011

Agile Purity

In 1998, Sun famously accused Microsoft of attempting "to kill cross-platform Java and grow the polluted Java market," a dispute which was settled out of court with Microsoft paying Sun $2B in damages.  About ten years later, in 2009, a scuffle ensued between Jeff Sutherland, original designer of Scrum, and the Scrum Alliance, which had begun issuing the "Certified Scrum Master" credential based on an outdated version of the Scrum guide.  Sutherland affirmed that "pure scrum" was defined and owned by himself and Ken Schwaber, even though the Alliance was issuing the certifications.

From http://www.sciencefix.com
The attractive paradox in both cases is that a single party (Sun or Sutherland) claims to have cornered the market on NOT cornering the market (universal software language/universal software development methodology).  But despite the wonderful symmetry of the apparent paradox, in both cases, actual revenue dollars were attached to the outcome of the debate.  As is so often the case, "pure" theory turns out to have been sheeps' clothing around an economic wolf securing net present value.

It's good to keep this in mind the next time someone accuses you of doing something that's "not agile."  "Oh," your new colleague says with a twisted lip, "You guys do PLANNING??  THAT's not agile!"  Or "Get away from me, you command-and-control fascist!" your Organizational Change Management Team Lead may shriek in panic as you suggest reconciling the story points values across two teams to allow for consistent reporting for the whole program.  Then she may attempt to roll you up in a handy burndown chart from one of the teams and throw you down the laundry chute.  There's an amazing amount of dogma in the supposedly freewheeling world of agile software development.

Let's just stop and take a deep breath for a moment.  Is the important thing to "be agile?"  Or is the important thing to secure your company's revenue with a continuous stream of high-quality software that meets the needs of your market?  Do not let the people in the brightly colored "Agile 2011 Conference:  Return to Snowbird" t-shirts distract you from what really matters:  delivering business value.  Do you want the shirt or do you want the satisfaction of a job well done?