Finding the Software Nectar

I have quirks. One has to do with information workers named Jerry.

When I meet a Jerry, I’ll insist that this new Jerry suffer the whole Seinfeld sitcom shtick where I, in thinly veiled disgust, say

“Hello Jerry”

and he, on queue, snidely responds to me with

“Hello Newman”

This all started years ago with a Microsoft practice director named Jerry. The shtick with this particular Jerry works well since I’ve long suspected we don’t trust each other.

“You know who you are, Jerry.” 🙂

This Seinfeld repartee amuses more than embarrasses (although increasingly more Jerrys have never watched the 1990’s Seinfeld TV series).

When I find myself enduring an insufferable meeting with Jerrys, my Jerry-tick possesses me like a pesky eye twitch. Every time this Jerry makes a constructive suggestion, I’ll respond with

That’s gold Jerry, gold!

It’s obnoxious, but I’m no Kenny Bania.

I apologize, in advance and in arrears, to Jerrys future and past.

Many agile software teams are burdened with stakeholders and product owners that set direction grounded in whim rather than on hard data. My guess is that most product owners don’t possess savant-like industry knowledge.

I’ve had it with coding to whim.

Should the next step be sarcastically applying That’s gold Jerry, gold! across the range of names to software product owners setting direction based on whim?

Many species, like honey bees, must forage optimally to survive. There is too much churn on most agile software projects. Burn-down charts have developers buzzing, but today’s programmers are worker bees bewildered by the fog of business whim.

There must be more efficient means to find the nectar.

Software Teams versus Groups

What’s distinguishes a team from a group?

In the cultural sphere of my youth, basketball seemed the quintessential team game. I was a playground hoops rat who grew up tolerating ego-centric ball hogs. I’d wonder, why don’t these rubes appreciate the team game?

I dreamed of a team game, modeling and emulating the unselfish play of the 1969-70 NBA champion N.Y. Knicks.

In retrospect, my hoop dreams chums and I were a motley collection of pubescent mouth-breathers missing that magic chunk of gray matter that enables a flock of humans to behave like the symphony of a single organism (e.g., Self-Organization: Flocks, Schools & Colonies).

Compare the shooting stats of the 1969 Knicks with the 2008 NBA runner-up Lakers — a striking difference in the distribution of shots per game for the top 6 players of both clubs is evident.

1969 Knicks Shots per Game
Willis Reed 17
Walt Frazier 15
Dave Debusschere 14
Bill Bradley 13
Dick Barnett 13
Cazzie Russell 10
Mean 13.2 and Std. Deviation 2.4

2008 Lakers Shots per Game
Kobe Bryant 21
Pau Gasol 13
Andrew Bynum 10
Lamar Odom 9
Derek Fisher 8
Trevor Ariza 7
Mean 9.9 and Std. Deviation 5.2

For the Lakers, Kobe Bryant took 3 times the shots per game than 6th man, Trevor Ariza. For the Knicks, Willis Reed, took 1.7 time the shots per game than 6th man, Cazzie Russell. Which club feels like a team? Which feels like a group?  My apologies for leading the witness.

The ’69 Knicks and the ’08 Lakers, by all accounts, were wildly successful in their respective eras. Most people would probably choose to play on a team similar to the Knicks, where everyone was assured roughly the same number of shots. Is selflessness an indicator of team success?


I started this post thinking unselfishness was a defining characteristic of successful teams. I planned to compare a team player’s team, like the 1969 Knicks, with a ball hog team, like Kobe Bryant and the 2008 Lakers, but a funny thing happened:

The premise did not ring true.

Working Thesis

Most of us would rather play on an unselfish team, but unselfishness, while an attribute of a attractive team, is not an attribute that defines a successful team.

Teamwork is less concerned with democratic, unselfish distribution of tasks and skills, then with recognizing how best to combine the strengths and weaknesses of the players.

I suspect that successful teams determine – by a sometimes brutal mechanism akin to natural selection – which player should fill which role based on complementary strengths and weaknesses. These roles are not appointed, they emerge. Roles emerge as strengths and weaknesses are evaluated through trial and error. Appointed roles rarely work, but who doesn’t know the go-to-guy 3 weeks into a project?

Avoid the trappings of appointing and anointing. Try letting roles emerge.

The Greek syn-ergos is the root of the English synergy meaning working together. Synergy describes conditions where entities cooperate advantageously for a final outcome. Synergy is an over-used word that feeds the old saw

The sum of a team’s parts is more important than any individual

Groups begin the path of team transformation when each group member acknowledges and pursues a shared goal. When group members are able to subjugate personal ego in the pursuit of the most efficient path to a shared goal, they cross into the realm of team.

Teams display emergent behavior which is a collective behavior that is largely unpredicted by the behavior of individuals taken separately. Sometimes simple entities like individual players, form more complex behaviors as a collective. NBA teams assemble players based on roles like shooter, rebounder, defender, etc. They build around core players and skills that fit a style or vision with complementary players and skills.

Teams where players emerge into roles are not necessarily exclusive from the much ballyhooed cross-functional teams. On the best NBA teams, when the shooter gets hurt, other team members fill the void by taking more shots. Because you emerge as the best person to branch of your source code, doesn’t mean you are – or should be – the team’s exclusive branching dude.

I have heard the phrase self-directed teams used to describe teams that are given autonomy and take responsibility. Teams are self-directed by definition, so self-directed team is as redundant as Free Gift or Frozen Ice. Perhaps “self-direction” is merely another characteristic that distinguishes a team from a group.

Following is a working enumeration of some of the characteristics that might distinguish a team from a group:

  • Teams work toward shared goals
  • Teams have emergent roles based on the most efficient path to shared goals
  • Teams emerge as a single organism when advantageous
  • Teams have emergent behavior unpredicted by individuals
  • Team members subjugate individual ego for the sake of team efficiency
  • Teams are self-directed

Software Teams, Comedic Improvisation, & Acceptance

Improvisation is an intuitive, coordinated, and spontaneous response to dynamic events. Improvisation is widely used in comedy, music, theater, and dance.

How might the techniques of improvisation be used in software teams?

In Blink, Malcolm Gladwell, author of the best-seller The Tipping Point, examines the structure of spontaneity. Gladwell observes that one of the critical rules of comedic improvisation is that the characters in skit accept everything that happens to them. He refers to this as the rule of steadfast acceptance.

Improvisation and Acceptance

Gladwell illustrates the role of positive acceptance with two improvisational comedy skits using the same comedic actors playing a doctor and a patient. The initial setup for the skit is that the patient’s leg is in pain. The first skit has a funny line, but quickly stalls out:

Patient: I’m having trouble with my leg.
Doctor: I’m afraid I’ll have to amputate.
Patient: You can’t do that, Doctor.
Doctor: Why not?
Patient: Because I’m rather attached to it.
Doctor: (losing heart) Come on, man.
Patient: I’ve got this growth on my arm too, Doctor.

Both actors become frustrated because the improvisation stalls abruptly. Why? Because the doctor offers a suggestion, “I’ll have to amputate”, but the patient rebuffs the suggestion, saying “You can’t do that, Doctor”

The following skit that Gladwell uses is more sustainable because the comedic actors agree beforehand to accept rather than negate any turn of events:

Patient: It’s my leg, Doctor.
Doctor: This looks nasty. I shall have to amputate.
Patient: It’s the one you amputated last time, Doctor.
Doctor: You mean you’ve got a pain in your wooden leg?
Patient: Yes Doctor.
Doctor: You know what this means?
Patient: Not woodworm, Doctor!
Doctor: Yes. We’ll have to remove it before it spreads
(Patient’s chair collapses.)
Doctor: My god! It’s spreading to the furniture!

The first skit peters out to a pre-mature end. The second skit opens up with possibility.

Steadfast Acceptance

How might our software teams apply Steadfast Acceptance to paired programming, architectural decision-making, or iteration planning?

Listen to – and carefully consider – your teammate’s suggestions

Has your suggestion been rebuffed while pairing on a programming task, or while a participant in a decision-making meeting, or while participating in planning an iteration? It’s a mojo-killer. Many people squash ideas with uncanny regularity. It’s destructive.

Should we consider taking our cue from actors trained in comedic improvisation who

accept all offers

to move the skit forward? Should we accept that none of us are truly smart enough to anticipate where our software skits will go?

Unilateralism is the bane of teamwork. I once worked with a talented programmer who consistently countered any suggestion or observation I made. It was baffling. To break the logjam I tried magnanimity. I enthusiastically agreed to his assertions, even when I thought my suggestions, or the ideas of others, had promise. It became poisonously unproductive. I resented his autocracy. I resented his lack of respect for alternatives. It clouded my acceptance of his best ideas.

Comedic improvisation teaches us to

  • Open ourselves to occasionally ego-compromising risks
  • Adapt to the immediacy of change with mindfulness
  • Improve our concentration skills
  • Improve our listening skills
  • Examine our responses to suggestions
  • Recognize that rebuffing suggestions is a mojo-killer
  • Consider steadfast acceptance as a practice (i.e., accept rather than negate a suggestion or a turn of events)

Tweet this Tweet this post

Extreme Interviewing – An Agile Aptitude Test?

How do you hire for an Agile team?

Does an Agile aptitude test exist? Does traditional interviewing work when it comes to finding people suitable for an Agile team?

Scrum proponent Gunther Verheyen, a member of Scrum Practitioners on LinkedIn, pinged our group about an article on hiring people to an Agile team.

In Hiring Software Developers: The Agile Aptitude Test, Richard Sheridan and Lisamarie Babik of Menlo Innovations explain to CIO Magazine how “Extreme Interviewing” helps hiring managers select Agile team members who posses the requisite Social Intelligence to apply Agile principles.

The gist of Extreme Inteviewing is that candidates are gathered and paired off to solve a problem.

Here’s a distillation from the article of the 3 most important characteristics of Extreme Inteviewing:

  1. The interviewers are not interested in the outcome of the problem solving;
  2. The interviewers are looking for good “kindergarten skills“; and
  3. The interviewers are seeking pair-partners who “make their partner look good

#3 is intriguing because it gets to the heart of teamwork.

Take-Away Tips

  • If you’re hiring to an Agile team, consider Social Intelligence as well as Technical Prowess.
  • If you’re already part of an Agile team, think about ways in which you’ve made your teammates look good. A well-placed assist is as satisfying as an acrobatic slam dunk.
  • If you’re part of a dysfunctional team, reviewing kindegarten skills might be revealing fodder for your next Retrospective.

MVP of your Agile Team

I engaged four Agile and Scrum discussion groups with the question:

Which person is more valuable to an Agile team?

One with SUPERIOR KNOWLEDGE of software systems and architecture
— or —
One with AVERAGE KNOWLEDGE capable of admitting what he doesn’t know

And, who would you rather work with?

Many in the Scrum Practitioners Group and Agile Alliance Group misunderstood the gist of my question. Probably because the question is “Bobtuse”. Among the Scrum crowd, it sparked a somewhat embarrassing thread about Product Owner versus ScrumMaster. Not my intent. I blamed myself for misleading them, then offered further explanation that I’m entertaining a thesis that the sublimation of ego is a crucial ingredient to team success.

I coined the aphorism

“Humility is the WD-40 of teamwork

I did get many thoughtful responses. Management consultant Steve McGee fed me:

“..a passion for knowing the truth, contrasted to a passion for being right…”

from something he noticed while reading about gender communication differences. He said,

“… men are stereotyped as always competing to be right. I was offended by that, and after thinking about it, it seemed this distinction had been missed. In both cases there will likely be an argument or at least debate. But the goals and therefore the results will be totally different.

Steve agreed that to get an honest evaluation and transparency, team members need to subjugate their egos. He went on to say,

“If a person is willing to trade certainty (accept ambiguity) so they will not miss any potential information, he or she will get closer to understanding what’s really going on and can respond more effectively.”

Thanks Steve.

My Agile mentor, David Hussman said,

I feed on environments where people are proud to say they don’t know. Some of the smartest people I know, know when to say they don’t know, and when to shut up and listen.

Thanks David.

Regarding who he’d like to work with, Agile coach Paul Ellarby said,

“…it all depends upon their personality. I have worked with individuals who freely admit they are “not experts”, yet try to dominate all discussions around their area of responsibility. Similarly, I have worked with folks who clearly are highly valuable experts, yet listen carefully to the teams dialog, and respond in clear, concise, and respectful tones.”

Paul also reminded me of the aphorism “Two ears, one mouth – use them in proportion…”.

Thanks Paul.

Was it Socrates or Epictetus who said

we have two ears and one mouth so we listen twice as much as we speak”?