Feeds

Do large projects silence osmotic communication?

Or can you still be agile?

High performance access to file storage

Comment Put a bunch of people together in a room and they'll be able to communicate more easily than if they were in different rooms. Walls place barriers between people, after all.

This announcement may have come from the Department of the Bleeding Obvious, but the principle of grouping people together and letting them get on with it is central to the idea of agile software development.

head shot of Matt Stephens smilingThe principle is summed up by OO/use case guru Alistair Cockburn in Agile Software Development:

"It is difficult to build extensive tacit knowledge without good osmotic communication, and that is hard to do with more people than can conveniently fit in a room."

"Osmotic communication" refers to the general drift of information that takes place in a software development room - a couple of programmers discussing a design issue may be overheard by several other programmers, who thus latch onto the latest burning issues in the ongoing project, or a business expert is overheard discussing the problem domain with some developers.

In agile projects it's common to optimise the office layout around open communication. Similarly, prominently displayed diagrams, wall-charts, etc, all help to increase the flow of communication between developers by acting as "information radiators" (a communication-rich office setup isn't without its problems, though. I'll cover these in a future article).

Not that any of this precludes the need for requirements analysis and effective up-front design, of course, but such a setup can certainly help a team work more effectively together. But what happens when the number of people on the project goes beyond a certain size? As soon as you have more developers than can fit in one room, you instantly lose many of the benefits of osmotic communication.

Project size has always been a contentious issue with Extreme Programming. At its outset, XP's creator Kent Beck stated that XP shouldn't even be attempted on large projects, and that the process is best geared towards small teams (up to about 12 people). Since those heady early days, though, many teams have had a go at applying XP on large projects, with varying degrees of success.

The most common trait among these projects seems to be that each team has tailored the process to make it work (not a bad thing, as XP - at least as described in the Second Edition of Beck's book - is meant to be tailored).

For example, there's a case study of the high and low points experienced by a 50-person XP team at ThoughtWorks, Inc. (Side note: despite observations such as "code is definitely worse than we started" [sic], their rather surreal conclusion is that "XP, or our evolved version of it, has done wonders for us as a team".)

Osmotic communication isn't the only quality to suffer when a project scales up in team size, but it's certainly the most palpable effect. So it's understandable that the first modifications to the process that XP teams typically make centre on fixing this decay in communication. And the "fixes" that they apply generally involve improving the level of documentation - replacing verbal communication with written. Documentation may be in the form of a project Wiki or emails at one end of the scale, and functional specifications, UML models, use cases etc at the other.

Put another way, if you have a small team of just a few developers and a business expert all in a single room, you may be able to get away with a lack of documentation. But as the project scales up, or as the team becomes more distributed, written documentation quickly becomes essential, even for XP teams.

I would be interested to hear about the success stories and problem points that you've experienced in adapting agile projects (not just XP!) to work with more than a roomful of people. ®

High performance access to file storage

More from The Register

next story
Android engineer: We DIDN'T copy Apple OR follow Samsung's orders
Veep testifies for Samsung during Apple patent trial
This time it's 'Personal': new Office 365 sub covers just two devices
Redmond also brings Office into Google's back yard
Batten down the hatches, Ubuntu 14.04 LTS due in TWO DAYS
Admins dab straining server brows in advance of Trusty Tahr's long-term support landing
Microsoft lobs pre-release Windows Phone 8.1 at devs who dare
App makers can load it before anyone else, but if they do they're stuck with it
Half of Twitter's 'active users' are SILENT STALKERS
Nearly 50% have NEVER tweeted a word
Windows XP still has 27 per cent market share on its deathbed
Windows 7 making some gains on XP Death Day
Internet-of-stuff startup dumps NoSQL for ... SQL?
NoSQL taste great at first but lacks proper nutrients, says startup cloud whiz
Windows 8.1, which you probably haven't upgraded to yet, ALREADY OBSOLETE
Pre-Update versions of new Windows version will no longer support patches
Microsoft TIER SMEAR changes app prices whether devs ask or not
Some go up, some go down, Redmond goes silent
Red Hat to ship RHEL 7 release candidate with a taste of container tech
Grab 'near-final' version of next Enterprise Linux next week
prev story

Whitepapers

Securing web applications made simple and scalable
In this whitepaper learn how automated security testing can provide a simple and scalable way to protect your web applications.
Five 3D headsets to be won!
We were so impressed by the Durovis Dive headset we’ve asked the company to give some away to Reg readers.
HP ArcSight ESM solution helps Finansbank
Based on their experience using HP ArcSight Enterprise Security Manager for IT security operations, Finansbank moved to HP ArcSight ESM for fraud management.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Mobile application security study
Download this report to see the alarming realities regarding the sheer number of applications vulnerable to attack, as well as the most common and easily addressable vulnerability errors.