Lightweight methods

January 16, 2007 by Artem

Agile software development methods tend to be lightweight. That is, while agile project can produce extensive user documentation, there is usually very small amount of internal documentation and bureaucracy. There is almost never any heavy architecture and design specification and even if there is, it is never produced upfront, but rather evolves iteratively.

Teams don't just skip the boring documentation. There are reasons for using a lightweight process:

• Agile teams focus on adding value for the end customer.
  While customers might find a user guide useful, in most of cases they don't care about the internal design documents. Therefore if it is possible to work without the heavy upfront documentation, it actually saves some customer money.
  
  
  
  
• Agile teams evolve the solution design over time
  Even when the agile process used requires some amount of internal documentation (it might be especially necessary, if multiple teams work on the same project in the multi-site environment), it cannot be produced at the beginning of the projects, because agile teams develop software feature by feature and embrace change.
  
  
  
  
• Agile teams compensate the "missing" documentation by other means
  The purpose of the internal documentation is always to fix the concrete solution, to make sure that system is going to conform to the given technical and customer requirements. Agile teams tend to use test-driven-development and automated testing for the technical part and frequent communication with the potential user for the customer part.

What do you think about these reasons? Where is the border between too lightweight and too heavyweight project? What amount of documentation is good for your team?

Permalink