It’s great that people are starting to realize that trying to accurately define and detail all requirements up front is inefficient and causes more harm than good. However, I’ve come across a fair share of individuals in the past who simply cannot imagine why writing a detailed functional or technical specification in the beginning of a project is bad. “But we need the functional spec so that we know what we’re building,” they say. “How will we be able to accurately measure progress? How can we build a project plan without all the requirements? There is NO room for scope change in this project – we need to get all the requirements now so that the customer can’t change their mind.”
Welcome to Agile, I say.
In the sensible world of Agile, we have learned from and corrected our mistakes. We no longer attempt to predict up front how a system will function or what will be in it, and we don’t put the customer in a position to speculate about everything they might ever need. We now realize that, no matter what we do to try to prevent it, the requirements of a software project will always change. We view this as a good thing. We embrace change and adapt constantly, thereby delivering what the customer really wants and not what they thought they wanted. This makes customers happy.
With Agile, we are able to release working software quickly and often. We are therefore able to deliver business value early and on a regular basis, which means a lot to many customers; they can see what they are paying for. Working software is the only true measure of progress in an Agile project. We have learned that progress cannot be accurately measured by intangible artifacts such as documentation, progress status reports, timesheets etc.
In Agile, we build the system with flexibility in mind. We know that the design will probably change, that already-developed components may be rearchitected, and that new features can be expected. We build a design that will last forever. Because we do not speculate requirements in the beginning of a project, and because we no longer do a Big Design Up Front, we are not bound to technical decisions made early on with inaccurate information: our design is adaptable.
In Agile, our project managers are happy. They can better predict, and they have more control. Progress measurement in an Agile project is accurate and realistic, allowing management to make better informed decisions about resourcing, budgeting, scheduling, etc. Because Agile methods give us more control over the software process, there is less uncertainty, and project stakeholders have less to worry about.
Agile helps us find and fix bugs faster. We do not allow errors to accumulate; they are tested and fixed without delay, which saves cost.
The Agile approach values planning. One would agree that planning is absolutely essential to the success of any software project – Agile embraces this idea by planning constantly, throughout the process. An Agile project requires more planning than other up-front development models such as Waterfall, and this ensures a better end result.
In summary, we realize that by going Agile, projects cost less to build, deliver more value to the customer and quicker, are easier to manage and control, are of higher quality, and are designed in such a way that allow future requirements to be delivered with less overhead.
Pingback: Adopting Agile: Teaching an old industry new tricks « // T3chNicaL.LEad