posted on Wednesday, July 06, 2005 9:36 AM by Simon Thorneycroft

It's about communication...

Recently I have been rereading Alistair Cockburn's excellent Agile Software Development and it led me to think again about Extreme Programming and development projects in general. In Extreme Programming, Kent Beck makes the following statement:

'We will control four variables in our projects - cost, time, quality and scope...'

of the four control variables, he rates quality as one variable that should not be altered. Nobody wants to deliver poor quality software, right?

However, Cockburn points out that facilitating communication is another variable that can be controlled for better or worse in a project. Getting the right sort of communication within and from outside a project team is an invaluable and often overlooked tool in delivering software. Cockburn suggests that some of the better forms of project communication are helped by:

  • Convection currents of information: Simply put, sitting people together in an environment where information and ideas can flow between team members.
  • Learning by osmosis: A second form of learning that occurs when people are colocated. Without listening the project team learn as others in the team - or business users visiting from outside the team - converse. The corollary of this idea is an 'information draft', whereby misleading information is introduced.
  • Information radiators: Whiteboards, posters, intranet sites can all be used to display information such as requirements and project progress, so that the team and external auditors can understand the successes and challenges that the team faces.

Interestingly, these forms of communication can be facilitated with little or no impact on the cost and time of the project. Even the costs of moving the project team to a vacant area of the office should be vanishingly small when weighed against the high cost of the delivery as a whole.

For other interesting view points on team communication, have a look over on DevUtopia.

    Comments

    # re: It's about communication...

    Tuesday, July 19, 2005 5:07 AM by Nick Drew
    You say that communication is something that can be controlled for better or worse in a project (I agree). You also say that it can be optimised without impacting the time/cost of a project (I agree). So, communication is a variable independent of the other four. It is not something that you tradeoff against the others. It isn't a driver for the project.

    Put another way, can I say: "OK, if my team commicates less, can I reduce the time/cost/scope/quality of the project"? Personally, I don't think so.

    Communication is a tool for managing those four drivers. It is just as important to get right as tools, hardware resources, etc. But you don't drive the project that way.

    By the way, there at lease two other drivers that I can think of:

    Visibility: one developer locked in a room can produce software that is on cost, time, quality, and scope. But no one would know that they had finished, until they had finished.
    Equally, some projects demand high visiblity (via a rigourous sign-off process), than can adversly affect the cost/time/quality/scope of a project. Thus visibility is one of the tradeoffs you make when structuing a project. I think Agile approaches optimise for visibility while having minimal impact on other drivers.

    Risk: the average case is probably that a project will be delivered slightly over time and over budget. The variance of delivery time/cost/etc is probably as high as 50%. By taking risks, however, it is possible to make the project quicker, but also increases the chance of more overrun. By reducing risk, you increase the average case, but decrease the variance.
    I think Agile approaches allow risk to be driven down by continuous improvement and feedback, both from within a project team, and within the community at large.

    # re: It's about communication...

    Tuesday, July 19, 2005 4:28 PM by Simon Thorneycroft
    Nick,

    Thanks for your interesting comments on this post. I understand the assertion that communication is a variable unlike the other four and to some extent I think you are completely justified in saying this, especially in stating that communication is something that can be used to manage the other four.
    Since the inspiration for this post came largely from Cockburn, I feel it correct to try to justify the points with reference to 'Agile Software Development'.
    In his chapter on development methodology design, Cockburn quotes seven principles that he has personally found to be true over his many years in the 'game', some of these resonate here:
    1. Interactive, face to face communication is the cheapest and fastest channel for exchanging information
    2. Excess methodology weight is costly.
    5. Increasing Feedback and communication reduces the need for intermediate deliverables.
    Cockburn states in the extended text for principle one that “people sitting near each other with frequent, easy contact will find it easier to develop software and the software will be less expensive to develop”. So, from this is he not saying that communication is a variable that directly affects the other variables; i.e. increase communication to lower costs, decrease the time to deliver the software, increase the scope or improve the quality. I would suggest and Cockburn’s second principle lends weight to this; if I have a geographically dislocated team, then further documentation must be produced to bridge the communication gap, this costs time and money. However, I do re-iterate the statement I made earlier and that I tried to make in the post, that communication is a variable that is somewhat different to the other four. Communication can be varied without a trade off from all of the others, although as the scope of the project increases, the subsequent increase in development team staff directly reduces the chance for good communication.
    Of the two drivers you state, I would suggest that visibility is communication but just stated another way. The developer locked in a room could produce his software to the required variables and he would then communicate the completion to the outside world. Indeed, the rigorous sign off you suggest is a form of project communication.
    The risk driver though is in my view an excellent point, although it is by definition, risky ;-)
    Once again, thanks for your comments, it is a real delight to feel that there are people listening out there and anyway I just love a well reasoned argument! If you have more to say on this, please reply here or preferably (since I get the comments faster) just mail me direct at simon.thorneycroft@syncadia.com.