Tuesday, March 15, 2011

Agile Value- Working Software over Comprehensive Documentation

I remember days when the project manager used to ask the team members about the progress of the tasks and he gets the reply that it is “50% complete” or “82% complete”. Nobody knows what does “50% complete” or “82% complete means. Only the team member is aware of the status. Finally the project managers does some guess work about the completion status and projects the overall status as some x% as part of the project status report. The stakeholders are happy about the progress without knowing the underlying truth about the real progress of the project. In the Agile Model of Development if there is any need for status projection the status is always reflected in the latest build of the Continuous Integration Server. The feature which is not available as part of the build means the progress is not there. So the things are quite clear in agile mode of development.
Many times there is a myth we have observed that “Agility means no documentation”. Here we would like to bring our experiences into effect. It is to be noted that Agility is not a rule book where somebody can specify about how much to be documented at specific scenarios. Each project is different and situation also is quite unique. No experiences or scenarios can be compared. Now setting this context we would give the background. There are experienced Agile practitioners who feel that there is no need of requirement or design artefacts; they can directly sit with the customers and do the coding. There are set of experience agile practitioners who feel there should be some basic documentation of requirements and further to that the coding and testing process can start. And many such different experiences.. We can do search over the net and we can find many such experiences. There is nothing wrong in reading such experiences. But we should not get drifted with such thoughts or experiences. How much documentation or how detailed the documentation should be a call which team or organization can take based on the specific condition in which the teams are operating. We should not overdo neither should we underdo. It should be a balance. To find out the right balance is the challenge. The need of right and enough documentation depends on factors like criticality of the projects, experience and skill sets of team members, availability of right tools, maturity level of team and other factors.
In Agile Teams, the working building is always available. Continuous Integration practice is being followed by teams where integration is a non event. Each Build compiles the source code , runs the necessary test, inspection tools, other necessary tools and have the completed build multiple times a day.

No comments:

Architecting for Continuous Delivery

This short article will provide details about the various architecture specific requirements for good implementation of continuous delivery...