...copyright Elena Yatzeck, 2010-2017

Thursday, July 7, 2011

The Agile Team Room is a Metaphor!

Can you gain the benefits of applying agile philosophy and practices on teams whose members are distributed across multiple rooms, multiple cities, multiple countries, and even multiple companies? 
From David Barnholdt's blog:  http://blog.crisp.se/davidbarnholdt/
Deborah Hartmann Preuss points out in InfoQ that if we go all the way back to the beginning, the optimal XP work space was described as "caves and commons," where team members had access to each other when they wanted, and to private space when they wanted.  Why, all of a sudden, are we telling people they have to constantly collocate?  Could it be that the agile team room concept has taken on a life of its own?  Is the agile team room a fad?

As someone very wise said to me on Tuesday, "the room is a metaphor," not a specification.  We should build our agile work spaces the same way we build our software:  around functional stories, not around "the system shall..." statements.  When someone tells you "everyone must be in one room," ask them the "5 whys" until they give you back "what" they want, not "how" they want you to give it to them.

So let's look at the the agile team room again from a functional perspective.  Mishkin Berteig put together a nice list of work space needs in this blog post from 2006.  If we remove his assumption that the team work space is literally a single room, we get these functional characteristics:
  1. Light, Air, Nature
  2. Ability for people to work together on something they can all see in real time
  3. Ability for people to have semi-private discussions or make phone calls
  4. Large shared drawing spaces
  5. Ergonomics:  good chairs, tables at an appropriate height, flexibility to allow for individual ergonomic needs
  6. Privacy
  7. Personalization
  8. Visibility to outsiders
  9. Convenience to washrooms, coffee, printers and other common services
  10. Protection of outsiders from team noise
Once you add in the convenience of working in the same time zone where your family lives, fully half the items on this list are better satisfied by putting team members in separate rooms than they are by collocation (3, 6, 7, 9, and 10).  The other five can be mostly handled by phone conversations augmented by technology such as shared whiteboards and shared desktop views. 

Even "visibility to outsiders" can be handled by virtualization technology or "I'm online" icons in shared email or instant messaging clients.  Teams in separate time zones will have significant challenges with item 2, but those problems can be significantly mitigated if teams are mutually respectful, and schedule their work times to allow for maximum overlap across time zones (one zone working early, the other late in the day).

Let's give this problem a little more scrutiny, though. Alistair Cockburn wrote a wonderful 2002 article (very soon after the Agile Manifesto was signed), in which he described the four "core" characteristics of would-be agile processes:
  • using short sub-projects
  • reflecting on their practices
  • working in close location
  • attending to community
As he explains in the article, would-be agile projects can get "half the agility they need" by chopping up work into small, frequent deliveries, reflecting on how to improve team performance, and re-prioritizing scope elements at the end of each iteration.  So that's good news, would-be agile distributed teams!

But what about the other 50% of the potential benefits?  Cockburn says proximity allows teams to build a "tacit knowledge base" where people need to write fewer things down, because they have a rich communication channel open to the whole group at all times--everyone is in the room, in person.  What you forget, someone else will remember.  More time is spent putting the knowledge into automated test cases and working code, and far, far less time is spent writing speculative documentation which will need to be changed later.

Cockburn's functional specification would be "Ability to build a tacit knowledge base."  And make no mistake, this is a real functional benefit that literal agile team rooms have realized countless times over the past 10 years.  But why does it work?  And does the co-existence in the team room have to be constant?  Must you spend 40 hours a week cheek by jowl with the same nine colleagues, hearing the same tired sports stories and fending off lunch invitations?  Cockburn himself says of collocation:  "To make it work, the team members build not only on sitting close together, but also on maintaining open communication among themselves. The tacit knowledge base doesn't track very well if people are being secretive with each other."

Pragmatically, having teams constantly "work in close location" is neither necessary nor sufficient to boost team productivity through shared tacit knowledge, and in terms of workers' need for privacy or for written notes, shared space may actually be counter-productive some of the time.

"Proximity" is incredibly valuable--when it is considered as a metaphor.  Cockburn's fourth core characteristic, "attending to community" is arguably the real functional requirement for building software well.  Teams in a metaphorical "team room" will spend maximum time working together towards a common goal, and minimum time on CYA activities or casting blame.

How do you build this team?  Just as with the ergonomics of the chairs, the answer is going to depend on all of the variables around your team members--their locations, their cultures, their bosses, their organizations, their cultures, and so on.  You likely need to iterate to figure it out for the team, and you will likely make some mistakes along the way.  I guarantee, though, that if you don't attend to the metaphorical team room, you're going to be doomed when you put your grouchy, privacy-loving crew of non-showering misfits into a literal team room and make them stay there.  ("ferrets in your pants legs" comes to mind).

One last note:  in almost all cases, as has been proven with data multiple times, the project inception activity at project start-up requires shared, real-time joint modeling for the team which goes on for several weeks.  I can't think of any way to do this except in person.  So for purposes of inception, the agile team room is a real room.

Friday, July 1, 2011

Agile Team Roles: De Jure and De Facto Distribution of Responsibility

It's totally uncool on any agile team to use the phrase "that's not in my job description."

Theoretically, the way to measure the effectiveness of an agile project is to look at how effectively the whole team is at working together.  Teams that work well together can often beat other teams composed of selfish individual achievers.  (Take for example the 1992 American "Dream Team" in basketball at the Barcelona Olympics, composed entirely of individual superstars such as Michael Jordan and Magic Johnson.  Oh, wait, no, never mind.)

At any rate, much digital ink has been spilt arguing over topics like:
  • Do we need Business Analysts in Agile?
  • What's the difference between User Experience Design and Business Analysis?
  • If our Testers can't Automate, how soon can we fire them?
  • Is there anything our Developers can't do?
  • What's the difference between a Project Manager and an Iteration Manager?
  • Is our Director a Pig or a Chicken?
and so on. I myself have squandered a few pixels on some of these topics.  But let's look at this in a new light.

As working individuals, we have de jure job titles which put us into play in a particular competitive economy, within our particular geographic region.  Before we ever get put onto any agile team, someone has to hire us.  It behooves us to get hired with a job title that will maximize our income.  So, for example, in Chicago, project managers get paid more than business analysts, at the same level.  When we're talking about de jure job titles, we're talking about what things we can put on our resume to get us hired at a certain rate.  These things are a reality at my house, and I bet they are at yours as well.

So let's say you ask questions like "is Business Analysis dead." At the de jure level, if I can't spin my resume to make me look like a developer or a project manager, yes, I'm going to get a tad emotional.  That cave-girl fight-or-flight reflex, involving protecting my young and whatnot is going to kick right in, and I'm not going to hear a word you have to say about "the business analyst just gets in the way when the developers try to talk to the customer, blah blah blah."

On the other hand, once we're actually in place on a specific agile team, we are constantly faced with the issue:  how can we best get the work done?  De facto, there are a bunch of different types of things that the team needs to do (which vary over time), and it would be best if we could optimize the way that we'll all chip in and get those things done.  In fact, this is true in any work environment, not just an agile one.
  • An absentee power-vacuum-creating manager creates a de facto arrangement whereby the team works out its own priorities without her (like in Lord of the Flies!).
  • A person appointed to her position for political reasons (whether "Friend of Bill Clinton" or "Niece of your boss") is going to need someone else to pick up her slack--she's not going anywhere and her work has to get done.
  • More benignly, whenever we ask someone to train their own replacement and move into a different role, both trainer and trainee are going to be less effective during that transition than they will be a little later.
On an agile team, that means that it's helpful for everyone to have a shared mental model of all the roles that need to be in place in order for the team to succeed, and a shared agreement about who will play those roles de facto: that is, for the purpose of this team, and for this project.  For best results:
  • It's helpful if everyone really wants to optimize the team's productivity.
  • It's helpful if the team doesn't insist that roles must be aligned 1:1 with individuals holding specific job titles, or even having specific experiences in their past.
  • It's helpful to cast a very wide net initially to look at all the things that need to be done, and the skills and inclinations of team members.
  • It's helpful for at least one person, a de facto project manager, if not the named one, to be able to identify skills gaps and seek help from the de jure authorities to get additional needed skills onto the team.
Agile teams, like any work teams, always involve constant little adjustments on everyone's part to make for a shared, somewhat harmonious, existence.  Especially in considering "here's what my PO ought to be doing" type situations, you can lower your blood pressure a lot by changing your frame to "here's what needs to be done.  De jure, Sandy ought to be doing X, but de facto, here's a different way that need could be filled, utilizing Dennis's talents instead."

In case you were wondering, I was attracted to the image I included in this post because it kind of looked like a full-frontal rendering of a judge's gavel, and I was going to use a lot of Latin today.  But in fact, it's a plunger design which was discussed in a legal blog about an unfortunate decision whereby the person who designed the plunger didn't get to claim the design as unique intellectual property, because he had patented the functionality, not the appearance.  A sad, cautionary tale for all of us.