Click to learn more about author David Binny.
The Agile revolution effectively overhauled the traditional waterfall/V-shaped process, purging the new methodology of any semblance of the old. In the Agile world, action trumps process, and it’s often thought that the old ways of requirements and documentation carry more burden than benefit. Today, user stories, a leaner, modern version of requirements have taken over and most organizations adhere to the agile methodology, writing code first and managing the aftermath later. This is thought to boost productivity and efficiency.
However, we’re seeing developers reevaluate their strategies. As they say, hindsight is 20/20, and the traditional methods may have had their benefits, especially with regard to requirements and project documentation. It’s becoming clear they’re an essential part of the development process, but how can we modernize them?
In this article, I’ll outline some methods for creating useful requirements and relevant documentation that incorporate into existing Agile processes. By combining a number of approaches, you can define less rigid requirements at the earliest possible stage and use them with modern iterative practices and tools. These include the Shift Left, fail-fast and Three Amigos approaches (the three amigos include the Product Owner/Business Analyst, Dev Owner and QA owner).
The Downfall of Waterfall
To Agile and DevOps practitioners, the V-shaped waterfall approach drew disdain as a rigid, complex process that hindered the speed at which they could write code. On top of that, it often resulted in failure. With 4 steps for coding followed by 6 other steps that needed to be performed in a series, waterfall was extremely time intensive.
Other issues with this approach include:
- To ensure success, V-shaped development requires heavy work to be completed at the beginning of the project (Discovery stage) and most decisions to be made and closely followed throughout. And in order to reduce the time of the project, neither the requirements nor the design underwent any testing until the end of the development process.
- When issues arose that contradicted the original requirements, they were not dealt with in the testing stage. This delayed problems and that would often reemerge during later stages of the process, leading to big-bang and even bigger-bang integration failure. In the end, practitioners were often left with a bulk of technical debt that muddled the final stages of the project and cut the process short.
To solve the issues that made the waterfall/v-shaped model so unsuccessful and incorporate the beneficial aspects of requirements and documentation calls for a preemptive, three-pronged approach: Process (Shift Left testing), Collaboration (Three Amigos) and Implementation (Fail Fast). Applying these approaches will make writing requirements and project documentation an essential part of our new Agile/DevOps world.
Shift Left Testing
Shift left testing brings tasks that are typically performed at the later stages of development to the front of the process – essentially from the right side of the V to the left side. This method restructures requirements in order to maximize their value to the end user. There are a few different approaches, including:
- Traditional: Enables most of a project’s testing to be performed in the early unit and integration phases instead of during the later system and acceptance-level tests.
- Incremental: Involves restricting a project so it’s composed of shorter, incremental stages with testing in each stage.
- Agile/DevOps: Requires practitioners to create a number of short iterations that include their own tests. These iterations can be thought of as a group of individual V-shaped processes. This model is heavily influenced by Agile practices such as test-driven development (TDD).
- Model-based: Tries to implement testing by creating a test model before any code has even been written.
Three Amigos
The Three Amigos approach fosters collaboration between the three primary parts of a development organization: the business itself as represented by stakeholders, business analysts, and product owners, developers and testers. Here, the Product Owner/Business Analyst acts as the voice of the customer, the Dev Owner owns the coding and the QA Owner is accountable for testing and validating the code. When these three parties collaborate and share information and resources earlier on in the project, we see increased trust and understanding of the project. Working together, each body involved in the project agrees on what criteria need to be met to consider the project complete, as well as define the project’s user stories that implement its features and manage the backlog of implementation tasks.
Fail Fast
Fail Fast is especially beneficial for enterprise IT, as it involves the implementation phases of a given project; wherein developers use test-driven development to write tests before any code is written. Code is stored in common version-control repositories where it can be accessed by any developer involved in the project. This encourages the use of CI/CD and deployment systems that can rapidly build and deploy code. These systems are triggered when a developer commits their code into a source management system, runs automated tests against it to ensure that it won’t break when put into production, builds a new version of the application, and then immediately releases and deploys it. Releasing software frequently to end users, or in the case of enterprise organizations and internal business users, creates a feedback loop ensuring that developers can notify the development team as soon as a user finds a defect. In this way, they can fix the code and quickly get it back into the enterprise’s IT team and their business customers.
Making Room for Requirements and Documentation in Agile
Since it was so closely associated with the V-shaped/waterfall approach, requirements management has garnered a less than favorable reputation. Where writing detailed requirements was time-intensive and sometimes futile, Agile has adopted the practice of writing user stories – a single-sentence scenario that describes a task that the user wants to perform.
In Agile methodology, user stories have been designed to handle a limited number of assumptions and outcomes. Agile practitioners also emphasize the importance of writing code over any form of documentation, which is seen as unnecessary and difficult to keep up to date. As a result, user stores are considered the only documentation a project needs.
To make the most out of your requirements and documentation in Agile, you need to go beyond just implementing Shift Left, Three Amigos and Fail Fast.
- Phase 1: Begin by shifting the requirements and documentation processes to the earliest stages of the project.
- Phase 2: After writing the initial requirements and documents, present them to the Three Amigos to ensure agreement. This is most effective if done on a platform that fosters collaboration in real-time and makes it easier to view, update, maintain, and track requirements, in essence create clear requirements traceability for each stage of a release pipeline. If they are accessible to the right people at all times, you’ll receive productive and timely feedback to ensure momentum throughout the project.
- Phase 3: Since requirements and documentation have already been shifted left, defective assumptions and requirements can be identified and fixed before developers ever write a line of code. Additionally, implementing impact analysis, code quality review and risk-based testing at this stage will decrease time, improve quality and remove inherent change risk. Following these fail-fast principles can be integral to the success of the development process, as there is typically a significant drop in the number of testing and defect-fixing iterations performed before the software is released into production.
Conclusion: Shifting Left & Moving Up
Before Agile dominated the mainstream, it was seen as an unpredictable alternative to traditional methods. Now, thanks to influence from the Agile and DevOps movements, the software development process is greatly enhanced. Even with the issues that plagued the waterfall method, it’s important to recognize the benefits of how it approached requirements and documentation.
There’s always room for improvement in any development process, and applying this trio of approaches can greatly improve any development. This, in turn, will help you release more reliable products.