In a waterfall based project distinct project phases are clearly defined, one of them being requirements definition. This phase very tedious and requires a lot work and attention from the business side. Everyone has to dive deep into the business processes, understand them, even optimize and improve them, before handing them over to be implemented. This also means, that the goals for the product have to be clearly set and all the major decisions made.
In enterprise level companies the processes complex and not always clear, responsibilities even less transparent and management tasks swallow a significant amount of time. So you hire Business Analysts, give them a visionary sentence or two, let them gather the information around your organization and as a manager keep your hands out of any decisions, which could be traced back to you in a case of failure. The project ends up with a more or less clear list of requirements, which are then passed to the software engineers.
After engineers start implementing, they find out contradictions, loopholes and different goals being set for the project and usually no one to clarify these problems with. In the best case the Business Analyst is still there and if they are really brave, they clarify the questions with the management and the other business experts. Everyone is irritated, that the developers don’t understand the requirements, and that they are coming along so slowly.
And then, business side discovers agile… The methodology, which has no distinct phases, especially no business analysis and requirement definition. This surely is a blessing in their eyes. A very time consuming and expensive activity is just not needed anymore. They can pass their visionary sentences to the developers, they will intuitively understand what the business meant and implement it in two weeks. Let’s go agile!
When the reality of agile hits, only then they realize, is that the User Stories used in the most agile frameworks are the basis for even more elaborate and precise requirement definition, then it was the case in the waterfall model. Ideally being based on the Behavior Driven Development, the user stories have detailed acceptance criteria. These acceptance criteria must be crystal clear to both the Product Owner and the developers and are ideally formulated to be used as test cases. Not all of this has to be documented in detail in the user story itself, but at the end of the day it is documented in the implemented code and the test cases at least.
To implement high quality software, it doesn’t suffice to exchange the murky waters of waterfalls with even murkier agile waters. The key to success are cold clear waters of user stories and sharp acceptance criteria with defined test cases. And none of this appears out of thin air, but is a result of intense communication between the business and the developers. Which in the end means, that the business experts have to be available as long as the project is running and must be able to make important business decisions. Once the managers realize that their decisions are becoming transparent and results are almost immediately measurable, some of them regret the idea of introducing the agile methods into their organization.
Cold clear water of agile is a blessing for the company, developers and the customers. But agile is surely not there to enable anyone to cut corners. You have been warned.