What do you mean you don’t have requirements?
One of the key strengths of Agile development is that it focuses on valuable action taken at the right time in the project. Agile drives out wasteful activities wherever they are found. Excessive documentation, and documentation too early in the process are examples of such wasteful development activities. A lot has been written on this topic, so I won’t go over it here.
Companies like to have an amount of documentation around to support a number of legitimate business needs (you can probably think of a few others):
- In regulated environments, the documentation provides a link in the audit process to ensure that work is being done in a way that supports the relevant legislation.
- The documentation supports training curriculum development.
- It is often the only user reference to business logic encoded within the application.
- To guard against the loss key subject matter experts, either due to promotion or turnover.
Another side-effect of the reduced documentation approach is that decisions are sometimes forgotten. When the developers start coding, the debate and resulting decision are distant memories. The team ends up wasting time repeating the same conversations over and over again. When you have a limited time to produce the next iteration of a working system, you don’t have time to cover the same ground again.
I have seen development groups build “documentation stories” into their backlog to account for the effort required to produce the needed documentation. This practice introduces pauses into the development stream, reduces the team’s throughput and can be counterproductive. So how do you support both documentation and execution more effectively within your Agile team?
Our team came up with a solution almost serendipitously, and it was the QA engineers who first thought of it. The team quickly adopted it and it proved to be one of the key productivity decisions we made on our project.
The QA team needed an amount of documentation—business rules, data elements, navigation—to understand how to test each story. They found themselves writing down key statements as the Product Owner rehearsed the story with the developers. Having been burned before, they also took to writing down the decisions made along the way. At the end of the rehearsal they distributed the documentation to the Product Owner and the rest of the team to make sure they captured the information correctly. Sound good? Well that is not the best part!
Since we were doing Test Driven Development (TDD), the QA team also took it upon themselves to provide the development team with mostly complete test scenarios for each story. As the stories were rehearsed, the QA team was busy identifying the specific elements that needed to be tested. These became the developers’ starting point. They coded the tests and progressed until they all succeeded, adding their own tests along the way.
The team was working off just-in-time requirements. There was no delay in getting the requirements documented. Instead the team started each iteration with a great deal of clarity. After a while some of the developers started coming up to me saying, “This is great! It’s a little like getting the answers to the exam before you write the exam.” The company also benefited from the collected requirements. We were able to demonstrate adherence to specific regulations through the log produced by the requirements.
We found a great way to leverage the strengths of the QA engineers in the process.