Communication Plans and Agile

At a recent meeting I was prompted of the need to map the informal communications of everyday collaboration with the more formal expectations of project management – as the adage goes: ‘two monologues do not make a dialogue’. On the other hand two equally weighted discourses directed at the same referential object (or theme) must intersect and enter into a semantic bond (Bakhtin, 1984). While ideologically I might hope of encouraging innovative collaboration through renouncement of monologic habits and primitive definitiveness, in a practical sense I needed to integrate the formal plan with dynamic feature delivery. For me AGILE approaches better capture everyday collaboration while PRINCE2 better handles the formal project staging (taking the best bits of both).

The project, as most of mine do, involves the implementation of an integrated Moodle / Mahara platform enhanced with a range of customisations. So some features are delivered out of the box by the software and some require bespoke development.  Rather than sharing spreadsheets and (un)versioned documents, we have implemented Pivotal Tracker (@pivotallabs) which has proved effective in its simplicity. In order to transform a 20+ page document of requirements into a deliverable items requires a quick review and mapping of how we label and score stories. Using a macro to get the original document table into a workable spreadsheet, one can then apply a workflow mapping between the methodologies before importing into pivotal.

Icebox New ideas to be scoped for future iterations Requirements for later stages
Backlog Scheduled items for next iteration (outside current velocity) Requirements in the next work package
Current To be delivered in current iteration Requirements in the current work package
Done Features accepted as delivered Signed-off requirements

The other area I needed a mapping was between the notions of implementation (what the software does) and development (what we need to change). We also extended our point scale for development to map implementation items onto this (it remains to be seen if the value mapping is equivalent as velocity starts to be recorded).

Score Development Implementation
0 No action No action
1 Language string change Default feature / configuration
2 Minor interface change 3rd party plug-in
3 Exact requirements understood Module combinations / learning design
5 Good idea of requirements – refine through iteration Multiple options / possible training need
8 “Epic” – further investigation required Further investigation required

With a sensible labelling system to cross-map the system aspects (e.g. core, 3rd-party, development) to the requirements sections (e.g. content, assessment, communication) one can  filter on the key aspects in groups and check their status. The significance of tagging over categorisation for linked data approaches should not be underestimated here, as it allows the information to be presented within different hierarchies. A weekly review of the current and next iteration now simplifies the communication process.

I don’t claim to have done anything radical here, other than reinforce in my mind the importance of keeping the project focus on communication. Tools, methodologies and most importantly documents are only as good as the dialogues they mediate. While creative (or productive) ideas will originate in the informal everyday collaborations, if they cannot be scoped into the project then they may disappear – worse yet, this may then discourage new ideas and limit overall project innovation.

Once upon a time the most agile prince was a frog:

‘Its very funny to be a frog
You can dive into the water and cross the rivers
And the oceans
And you can jump all the time and everywhere’
M83, Raconte-Moi Histoire

I hope that the project can instil this light-hearted approach to its management.


Bakhtin, M. M. (1984). Problems of Dostoevsky’s Poetics. Minneapolis: University of Minnesota Press.