Do you have a “constitution” or some other guiding principles document for your collaboration space? I have found that a short list of shared values for the team working in a collaboration space can be a valuable tool. It allows new team members to quickly get in the groove and reduces friction among team members whose personal tastes may be in conflict.

One of my favorite rules is “There must be food.” Having been on a bit of a get healthy kick lately I might modify this to read “There must be healthy food.” What ever your choices be they Oreos and Licorice or fruits and vegetables I think you will find this a popular and useful principle.

The opportunity to take a small break and wander over to the snack table while contemplating a tricky bit of coding can be invaluable.

No I am not off my rocker or renouncing my beliefs and experiences with agile practices. I am a fan of precision. I like well engineered gadgets, cars, motorcycles, and systems. I prefer that our use of language is chosen with care to convey precise meanings. The term “War Room” is commonly used to describe a team collaboration space. Unfortunately teams generally go to a “War Room” during unusual activities – a bug bash, a production problem, a security breach. All of these are a crisis event. This is the root of why I don’t like the term “War Room.” For movie fans the quote from Dr. Strangelove is very apropos:  

“Gentlemen, you can't fight in here. This is the War Room!”

I believe the default state of a development team should not be in crisis. The natural state of a productive development team is in collaboration. This is accomplished by having the team do the majority of its work together. One of the most effective ways to facilitate this is by putting the team in a common shared space. Calling this space a “War Room” commutates the team is in crisis when it isn’t, or shouldn’t be.

So what should this space be called? One of the neat things about language is that sometimes precision is emergent – it takes time and use of imprecise terms to get the collective social consciousness to reach agreement. I have seen these spaces called “Team Room”(bland), “Collaboration Space” (unwieldy), Pit (short but certainly not sweet); the truth is that the term “War Room” has what an oenophile would call good mouth feel. I am hoping that a good collective term becomes emergent soon.

If you have a better term please drop me a line. I would love to hear it.  

Now playing: Antigone Rising - Hello

I am a big proponent of agile software development methods. The combination of software engineering discipline and lightweight project management processes has been very successful for many projects that I have been involved in. I tend to be a bit of a closet methodologist and I am very interested in the characteristics of different methodologies and successful implementation strategies. If you are looking for a good discussion of software engineering methodologies I recommend Balancing Agility and Discipline: A Guide for the Perplexed.

The p&p group in general uses development practices inspired or adopted by the agile community. When implementing these techniques it is common to focus on the process and tooling when implementing agile practices. Often the relationship of the physical space to the effectiveness of the methodology and the productivity of the team is not a major concern. The team is generally forced into making ad-hoc modifications to their space configuration or settling for a “good enough” solution. Herding the team into a large conference room and buying snacks seems to be the common solution. Acquiring a shared resource like a conference room that is dedicated to a single project team requires painful justification with the facilities management.

Here at Microsoft the notion of one brain in one office has been enshrined as a central tenet of facilities planning and administration for 15 years. This is largely based on research around how an individual achieves the state of thinking called flow. Interruptions to flow are seen as the ultimate evil and to be avoided at all costs. In this model software development has been viewed as a solitary and focused effort requiring a private space to operate at peak efficiency. The agile community has challenged this notion with practices like pair programming, common ownership, and continuous integration. The agile premise is that if you can get a team into a flow state you can get a greater amount of productivity than if you got each individual into flow state.

Obviously to achieve this team flow state you need a team communication mechanism that supports good communication types and limits bad communication types. The physical configuration of the space can help or hinder both good and bad communication types. Our goal will be to create spaces that promote the flow state by enabling good communication types and hindering bad communication types. This of course is not the only aspect of achieving enhanced team productivity.

You might find interesting parallels in the alien dog packs in the 1991 Hugo award winning novel A Fire Upon the Deep (Zones of Thought) by Vernor Vinge. The aliens are not sentient as individuals but in small groups they can form a sentient intelligence. The trouble is they use sound waves to create the personal area network that enables the emergence of a sentient intelligence. This has certain proximity implications. For example, two packs can’t maintain their sentience if they are too close to each other. The interference from too many sounds removes the cohesion necessary to maintain sentience. When we try to co-locate two agile teams in the same space without sufficient sound considerations we can see both teams struggle to achieve flow state.

So stay tuned as we embark on this journey to create spaces that promote agile practices and prove that they improve our productivity.