Individuals

Individuals are pretty much the smallest chunk of humanity available for doing software development, and  probably for a lot of other things too. Individuals are a key part of software development. Regardless of what we disagree about, we can hopefully agree that at some point an individual has to do something, or we end up with no development – no new software.

Communication

When there is more than one person involved in a software development effort (and there almost always is), communication must happen.  No communication = no result.  Let’s agree that at least some communication must happen.  The “customer” communicates with the “developer” about a feature, a “developer” communicatoins with another “developer” about some technical concept, and so on.

Document Driven Development

In the phased (Waterfall) approach communication is typically done via documentations of some sort. There are many failures with Document Driven Development and I’m not going to cover much of that here. A critical failure is that the thinking that goes into a document becomes stale very quickly.  There is no way to prove that it is correct and complete until someone does some REAL WORK based on that document – and that can be weeks or months later.  I have also found that the “original thinking” we are trying to capture does not typically translate well into a document.  It becomes more misleading than helpful for the “user” of that document.  Why waste time and effort on something like this?

[NOTE: I am just talking about Software Development.  There are likely many situations where documents are useful.]

Something Completely Different – Interactions

In Agile Software Development we take a different approach.  Most communication is done “face-to-face”.  Two people talk to one another, or a group of people gather to discuss something.  This communication is best done at the time that the work being discussed is ready to be coded.  Discussion has a shelf life that is pretty short.  In about a day or two, and sometimes within an hour or two, the clarity and meaning starts to diminish.  So we want to go from commuication to code we can run as quickly as we can. Let’s talk and code, code and talk. Make something that works, make sure it works, try it, tweak it, tune it, adjust it.

There are many ways we can enhance this sort of commuication: Draw something on a white board, use some sticky notes, use some 3 x 5 cards, code up a test, code an experiment, move things around.  Settle on something to try, and then CODE IT and run it. Revisit, re-discuss. None of this turns into documents.  All this stuff is just part of the communication which culminates in Working Software.

If you still need documents

If you need documents, then make sure they are at a high level, and make them as short as possible.  “We need a sales report” is a good document. The rest of the commuication about that Sales Report can happen when we are ready to code it.  Then that original document can be thrown away.

Communication is not a Result

In the end, communication of this sort is not a result – it is a critical component to getting a result, but it is not the thing we are after.  The result we are after is Working Software.

And don’t forget my Agile Maxim #4: “Working Software” is software that users are actually using. Until it’s in use it is truly useless.

Radical?  I hope not.

Does this sound radical?  I don’t think it is.  My suggestion: Try a few things this way and see how it works for you.  Then, you can blame me.  Okay?

The Agile Maxims:

If you want to read some of my other Agile Maxims, they are here: http://bit.ly/AgileMaxims