The Ideal Agile Toolset

My last presentation for Tuesday was a talk by Brad Appleton (who was using crutches because he hurt his leg while breakdancing, true story!) about the characteristics of the ideal Agile toolset. Appleton feels that the current tools we have that support the Agile process (e.g., Eclipse, Confluence, TWiki, Trac, Jira, zAgile) all fail one way of another to deliver proper Knowledge Management.

Most current Agile toolsets treat source code as the primary deliverable of a project. This means that the source code gets special treatment: branches, labels, history, dependencies, etc. However, Appleton asserts that source is not the product: knowledge is the product delivered on a project. Source code is only one way to represent knowledge, it is a knowledge format. What follows is that the ideal toolset should manage all knowledge the same way, allowing tight revision control on diagrams, wiki entries, tests, etc.

Appleton then raises some interesting questions:

• How can we define "done" for non-code artifacts (e.g., a UML diagram)?
• Is it possible to apply TDD (test driven development) to non-code artifacts?
  

This talk by Brad Appleton got me thinking about a practice we have in our department. We usually manage our designs by checking in a complete design document (a Word .doc file, or a EAP file) in our VCS. Maybe we should try to have a finer level of control on those designs by splitting the documents into individual diagrams, or sections, etc. This would allow for a better management of dependencies (e.g., between code and individual diagrams), branches, etc.

On a final note, the presenter mentioned a book that could be an interesting addition to our library: The Laws of Software Process, by Phillip G. Armour. (I don't think we have it, but I could be wrong...)