Atomic Agility 2

Why does demonstrated talent fail? Why do people who have shown questionable talent succeed? What makes an "A" Group, an "A" group?

This year the Seattle Mariners and the Always Locationally Confused Angels of California Los Angeles Anaheim have basically had the exact same record. The Mariners have tracked them at 3 games out the whole year with minor fluctuations. They've beat the same teams, they've lost to the same teams. Statistically they are the same.

So the CaliLosaheim Angels came to Seattle and swept the Mariners handily. The games were consistent, they were obvious and they were part of a trend. Why?

A baseball axiom is "On any given day any team can beat any other team."

So baseball itself nearly writes off the event as merely being what makes baseball exciting. Small comfort for Mariners fans.

Mark Buchanan's book The Social Atom may help explain some of this and give us a very important cooperation and Agile Management takeaway. I am going to hyper-simplify one of the elements of Mark's book and then expand upon it.

Social Weight

Why would a bunch of people suddenly riot a break windows at Niketown? Niketown may go decades without having its windows broken, but then suddenly a bunch of people show up and break windows. Were these people bred to break windows? No, if they were they'd have been there breaking windows all the time.

But somewhere deep within these people is a propensity to act and that action may include window breaking. So let's say for simplicity that there is a window-breaking gene that governs this. One person in a group may have a strong strong propensity to break windows. He needs no social weight to break the window, he  just needs an excuse.

He has an n+0 window-breaking gene rating, where 0 people are needed to drive him over the edge.

Let's say that he's in a crowd of 10 people and in that crowd is someone who has an n+1 rating. He likely wouldn't break a window unless he saw someone else doing it. Since Mr. n+0 has started the trend, he now joins in. When he goes an n+2 would join in. And so far up the cycle until you run into people who's n+ rating is way above the current mass. So maybe after n+2 joins, the other people in crowd are all n+40s and they don't join in.

Of course, you rarely act in such rarified conditions where you'd only respond to your window-breaking gene. You'll also be wondering if you'll be thrown in jail, if you'll be seen on television, or maybe you really like Niketown a whole lot. These would all act as elements to over-ride your genetic propensity to smash windows.

But! Suppose Niketown is filled entirely with human-eating space aliens and, for some reason, the only people to stop them are you, your crowd, and a pile of convenient bricks. Then, even if your window breaking gene was really high (N+a million), your Xenophobic or Don't-eat-me genes may well override it.

So the point here is that while we are autonomous and rational actors in our heads, the actions of society and the context directly impact the decisions we make and the emotions we feel.

Momentum

The actions of the Mariners this week brought it all home to me, so to speak. The team itself, through a few bad calls by the umps, a few good pitches by John Lackey, and a few missed opportunities with men in scoring position, began a slide of downward momentum. You hear a lot about momentum in sports.

What momentum seems to do is start cascades in the various "n+" numbers in your team. A few things go bad and you're not as hyped as you were a few minutes before. That leads to a noticeable decline in performance, which is felt by the rest of the team, the crowd, the opposing team, and the announcers. Everyone can feel it.

The Agile Manager as Momentum Agent

Traditional management has adopted, to varying degrees, the attitude that people are rational actors. The manager and the organization sets up a series of rules (job description, project description, budgets, specs, etc.) and people will, of course, follow those rules.

"Why?"

"Huh! Well, they'd better if they wanna get paid!"

We've all witnessed that rigid top down organizations have limited runs of success. When people lack freedom to act, they lack the freedom to innovate. When people lack the freedom to innovate, they lack the freedom to improve an organization or even to get excited about it.

In agile management we have a convenient and meritocratic concept of "A" programmers. Agile needs "A" programmers to work because they are motivated, they are innovative, and they are fast.

But we know lots of programmers who are amazing at their craft and utter failures at working in a group. "Good programmers are a dime a dozen," my cousin Robert once counseled me.

So what does an Agile manager need to do to achieve success given these hypotheses?

Set Expectations

An agile manager needs to frame the initial world in which the project operates. Successful framing would be both clear and flexible (always the challenge of an Agile approach is finding the balance). The overall goal for the project, the general feature set, the expected delivery dates and the starting budget are easy to tie down.

For flexibility, something is or group of things are usually driving a specific need, a specific budget, a specific deadline. An Agile manager is up front with project staff about what is truly driving the project and what elements of the project are more flexible. An Agile manager is also up front with clients or upper management about what can be comfortably set in stone and what cannot.

The Agile manager does not just set the team's expectations, but also the client's.

The social atomic theory makes this even more important because expectations create goals and frame the extents of creativity. Your team needs to have the right "N+"s for the project's requirements. Does your team like a strong spec and then to fill in the blanks? Do they like pitching in to meet deadlines? Do they like finding new features and creative solutions, but feel hindered by strong specs?

Does the client-side have the appropriate "N+"s to go through an agile project in the first place? Do they operate as commanders or cooperators? And so on.

The Agile manager needs to find ways to make these balances - to arrange the optimal working environment for the team and comfort level for the client.

Assemble good n+ teams (compatibility)

What makes a good team under these conditions? People who have skill and emotional sets that are geared toward success (duh!).

Hard to quantify, to pin down, to make useful, this ends up becoming yet another management edict to spot talent. You want a team that will, to the extent possible, feed off each other's energy and build team inertia.

In general, here you want people who will actively not bring down the process. Obviously people don't have their N+ values logged in a book somewhere. So the good Agile Manager must...

Build external systems to reduce n+ strain.

Now we can get a little meaty. As with the Mariners whose winning ways came arguably to an end when the strain reached a certain point, so too can teams easily be derailed by externalities.

The team can be demoralized by bad reviews, cut budgets, lack of communication, and so on. The team is generally energized by:

1. A sense of urgency
2. A sense of purpose
3. A sense of direction
4. A lack of unnecessary hindrance

Agile managers can give these easily. First off, all projects need a timeline. People generally don't hurry unbidden as individuals and certainly don't as a group.

Agile managers can set timelines. This combined with the feature set (usually more than is comfortably possible) creates a sense of urgency.

Agile managers can set the parameters of negotiation. Hopefully your project isn't too horribly boring. Most development projects have some sense of discovery that can get people energized. The team being intimately involved in the look of the finished product combined with control over their daily tasks, creates both purpose and direction.

So they are rolling. The Agile Manager now needs to get out of the way as much as possible and turn attention to things that could derail the group.

• Are the tools of internal communication working correctly?
• Are the tools of production working correctly?
• Is the team showing signs of pain in a given area?
• Is the client participating in the development process?
• Is external communication proceeding appropriately?
• Is the burn rate acceptable?
• Is the burn-down rate acceptable?
• Are releases happening at appropriate intervals?
• Is the defect rate acceptable?
• Are release planning sessions changing the direction of the project radically?
• Are release planning sessions not overlooking features that need to be of higher priority?
• Are there external elements that may impact the schedule?

Being able to understand these types of issues quickly and deal with them helps avoid unnecessary hindrances. But how does information flow?

Churn What You Learn

Information that stops at a given individual helps no one. The Agile Manager should design social media systems to churn any information received during a project. All people throughout a project should be able to rapidly tag, store, and disseminate information throughout the team. Information that has been noted as important for the team should always be easily accessible.

Teams that vaguely remember weeks later reading a webpage with pertinent information cost time, money and momentum. Internal team sites with tagging engines can be built on any number of platforms today such as Drupal, MediaWiki, or Wordpress. Personally, I prefer using del.icio.us for team tagging projects.

Internal wikis and blogs make rapid data storage and project-long data retrieval easy. I believe that del.icio.us combined with SocialText is the ultimate project social media system.

If a team is using systems like this, they tend to be self-supporting. Individuals may resist these tools at first, but the team will pull people along and notice non-performers.

Social Media should be augmented by some type of contextual project dashboard, this will automate the learn churn. Dashboards are becoming mind-numblingly common, luckily. I like VersionOne's the best, but you can get them from Rally, Basecamp, or Zoho as well. What you want is a dashboard that is in some way providing indicators of all those questions asked in the last section.

Now … grab that old laptop you never use from the corner. Start it up, slap a cable on the back of it, and in the most visible space for your team - put a flat panel on the wall with that screen up all day and all night. Completely remove the luxury of team members not looking at it.

Rub Their Noses In It

Why? Because motivated teams abhor poor metrics. The team will start to game the system in the service of success. During a daily scrum, someone will say "That number is a bit low" and the team will come up with the quickest and least cost fix to satisfy that number. If the metrics are set right, this will only be a win.

If there's a way to cheat, the Agile Manager needs to recognize it and correct the metric.

But one thing is certain, the successful team and all it's N+'s will rise to the challenge in service of the metric. What's more, they'll understand why the metric is there, what it is measuring, and the true impact (quality, timeliness, etc) of the metric's satisfaction. It won't seem like a disconnected, stupid top-down edict.

Due to the pleasure of getting things done and being part of a successful group, this bolsters N+'s for whatever snags may be ahead.  The simple games start the momentum of success.

Close this down

The social atom highlights an important element of Agile Management - that individuals do behave differently in groups. We therefore manage both individuals and groups. Our tactics for individual performance, however, often rely on individual negotiating techniques and coercions, not on an analysis of the group dynamic.

Okay, that's more than enough for one blog post. I'll note that there are many tools at the fingertips of the Agile Manager that I haven't talked about. Perhaps the most important of which is finding tactile tools to add urgency and immediacy to an effort. My friend David Anderson has written extensively about his Kanban approach at Corbis. (My teams are rarely in the same place).

I will also note that David's Kanban approach is a great example of an important thing: Agile is for business, not a subsection of it. Kanban was originally used in the automotive manufacturing industry, not in software. Likewise, what I'm discussing here is meant to be applied enterprise-wide, not just in the Dev group.

Technorati Tags: Social Atom, Mark buchanan, niketown, space aliens, social weight, agile management, management, david anderson, kanban

Comments

[Richard Banks]

That's a fantastic post! Team dynamics and group think (traditionally what managers place under the "morale" umbrella) is something that's very often overlooked, especially in software teams.

You've just given me reason to take a fresh look at how agile teams are put together, and to put more consideration into culture and personalities than I have before. Thanks!

[Jim Benson]

My that's enthusiastic!

My pleasure!