Why Agilists think Up-Front Analysis is inherently un-Agile
Most people have the perception that the deliverable from the “analysis phase” is a set of “analysis” documents and artefacts. This perception is a result of waterfall practices. For Waterfall, the deliverable is an analysis document. Waterfall methodologies believe that the status of a project can be determined from these interim deliverables. The main reason is that they are tangible and can be measured by “thud factor” and the complexity of their contents. The analysis documents do not show what is unknown about the project, that is, the true risks associated with the project. The analysis documents also state the requirements as absolute that makes them difficult to challenge by the development team. Users place undue confidence in the documents because so much effort has been placed in them. Business Analysts in Waterfall methodologies invest significant effort in the documents because they are the visible means by which they will be judged. Business users, project managers and business analysts all focus on the documentation which causes a reinforcing sprial. Huge amounts of effort are placed in making sure the last T is crossed and I is dotted. None of this effort makes its way into the final software. The end result is that business analysts spend a majority of their time on creating documentation rather than performing analysis, that is, learning about the problem.
Agilists see the Analyst role as creating documentation. This is because Waterfall Business Analysts spend the majority of their time creating documentation. They do not see real value activity that is learning about the problem.
Agile Analysis
Agile analysis focuses on the learning of a business problem, reflecting the knowledge to the business user, and then transferring that knowledge to the development team. The Agile Business Coach’s deliverable is a developer trained in the business problem, and the trust of the business user that they fully understand the problem. The only measure of success is software that the business users can use to release business value. Focusing on a proper measure of success de-emphasises the interim analysis documentation. In fact, the Agile Business Coach aims to prepare no up-front analysis documentation. (Zero Documentation) The only documentation they prepare is to record their knowledge. They will generate documentation as part of the learning / analysis process. None of this documentation should be regarded as a deliverable.
Anyone who has attempted to write an article for general distribution will appreciate that it requires several orders of magnitude more effort to write the ideas down than it does to explain it to someone face to face. Agile Business Coaches aim to coach developers in the business problem using reflective teaching practices rather than leave the transfer of knowledge to documentation. This reduces the amount of effort required to transfer the knowledge by several orders of magnitude. The saved effort can be spent on learning and building relationships which are much more benefitial to a project.
I ran an experiment with the last three business analysts, Tim, Kevin and Senela when they started working with me. I spent between 10 and 20 minutes training them in the business rules relating to the credit risk associated with selling a commodity. In Kevin’s case, he had no previous experience of credit risk concepts or commodities. I then gave them a 40 page specification of the same rules and asked them to tell me if it contained the same information I had given them. The specification was one of the better ones I have seen. After a few hours they came back to tell me that the document did not explain the same idea, and that there were several mistakes in it. The document had taken at least 4 weeks to prepare.
Posted by chrismatts at October 29, 2003 2:00 PM