Defining Requirements the Agile Way

Agile development was a revolution that overturned the rule of the accepted waterfall/V process. As with any revolution, its adherents believe that the best thing to do is the complete opposite of the old ways. In the agile world, action is more important than process, and requirements and documentation do more harm than good. Building on the agile method, organizations feel that they should write code first and deal with the consequences later, making velocity and productivity interchangeable.

 

Over time, many revolutionaries have started to reevaluate their assumptions and realize that the old world may not have been perfect, but there were areas in which they could benefit from their predecessors. In this light, agile and DevOps practitioners have started to understand that requirements and project documentation remain an essential part of the development process.

 

Modern ALM for Confident Software Delivery

 

This article offers guidelines on how you can create useful requirements and relevant documentation. By combining the shift left, collaborative (Three Amigos), and fail-fast approaches, you can define less rigid requirements at the earliest possible stage and use them with modern iterative practices and tools.

 

 

Understanding Waterfall

In the eyes of agile and DevOps practitioners, the waterfall looks like the final days of the French and Russian monarchies. In the bad old days, no code could be written without following a complicated and rigid process that took a long time to complete and frequently resulted in failure. To understand why this model became so hated, let’s take a closer look.

 

The waterfall process is often referred to as V-shaped development. In this model, the coding process is broken down into steps:

  • Discovery
  • Requirements
  • System engineering
  • Architecture

 

Each step must be performed in a series, and you cannot start the next step until the current one is completed. These steps represent the left-hand side of the V and are performed from top to bottom.

 

When the coding stage has been completed, a new series of testing steps is performed:

  • Unit
  • subsystem integration
  • Integration
  • System
  • Acceptance
  • Operational

 

There were a number of problems with this approach. For starters, the success of a V-shaped development project required doing as much work up front as possible and that decisions made in a project’s earliest stages were adhered to as closely as possible. So once all the necessary research had been completed in the discovery stage, detailed requirements were written, and a design was then created that rigidly adhered to those requirements.

 

————

You might also like to read
The Kanban System in Action

————

 

To save time, neither the requirements nor the design underwent any testing until near the end of the development process. And to make matters worse, when issues arose that contradicted the original requirements, or the assumptions on which they were based, dealing with them was delayed until the testing stage. These delayed problems then typically reemerged during subsystem and system integration, leading to big-bang and even bigger-bang integration failure. The final result was a tidal wave of technical debt that overwhelmed the available resources and often led to the project’s premature end.

 

 

Fixing Waterfalls by Shifting Left

Fixing the problems of the waterfall/V-shaped model requires a preemptive approach that involves process (shift left), collaboration (Three Amigos), and implementation (fail fast).

 

Shift Left Testing

Shift left testing moves tasks performed at the later stages of the development to as early as possible in the process. In other words, shifting them from the right-hand side of the V to the left. There are four types of shift left testing: traditional, incremental, agile/DevOps, and model based. This approach focuses on structuring requirements to emphasize their value to end users and/or mapping requirements to application features.

 

  • Traditional shift left testing means the bulk of a project’s testing is performed in the early unit and integration phases instead of during the later system and acceptance-level tests.
  • Incremental shift left testing involves breaking down a project into smaller incremental stages and performing tests during each of these stages.
  • Agile/DevOps shift left testing involves creating 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 shift left testing tries to implement testing by creating a test model before any code has even been written.

 

————

You might also like our blog
Agile vs Waterfall – How to Select the Right Tool for the Job

————

 

Three Amigos

This 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. By getting these “three amigos” to meet and discuss projects as early as possible, they establish trust and create a common understanding of the project they are working on. By working together, they define the project’s user stories that implement its features and manage the backlog of implementation tasks. Together, the Three Amigos define the criteria by which the project can be defined as done.

 

Fail Fast

This approach handles the implementation aspects of a project. In this model, test-driven development is used by developers to write tests before they write any code. Code is stored in common version-control repositories where it can be accessed by any developer involved in the project. Fail fast also encourages the use of continuous integration, delivery, 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 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 hands of users.

 

Modern ALM for Confident Software Delivery

 

Requirements and Documentation: The Missing Pieces

Implementing shift left, Three Amigos, and fail fast is not enough on its own.You still need to take care of documentation and requirements. As we have already seen, requirements management has been given a bad name due to its association with the waterfall model. In place of writing detailed requirements, the agile practice of writing user stories has been adopted. A user story is a single-sentence scenario that describes a task that the user wants to perform. Unlike traditional requirements, user stories only handle a limited number of assumptions and outcomes, and, to make matters worse, agile practices emphasize the importance of writing code over any form of documentation. Documentation is often perceived as an unnecessary overhead that, no matter how good it tries to be, is never maintained and quickly becomes out of date. For many agile developers, user stories are thus seen as the only documentation a project needs.

 

Applying shift left, Three Amigos, and fail-fast approaches will make writing requirements and project documentation an essential part of our new agile/DevOps world. Start by shifting left the requirements and documentation processes to the earliest stages of a project. Once you have written the initial draft requirements and documents, share them with the Three Amigos for review. It is important that you write and manage your requirements in a system that facilitates real time collaboration. Many companies still write and share requirements using desktop word processor documents and spreadsheets, which makes it harder to view, update, maintain, and track requirements. Making the requirements accessible to the relevant people will have important long-term benefits and help you get high-quality feedback in a timely manner.

 

————

You might also like our blog
Agile and DevOps Will Change Testing Over the Next Three Years

————

 

By making requirements and documentation available as early as possible, defective assumptions and requirements can be found and fixed before your developers ever write a line of code. Doing this per fail-fast principles will have a dramatic impact on the entire development process. Specifically, you will see a large reduction in the number of testing and defect-fixing iterations performed before your software is released into production.

 

Putting It All Together with Panaya

One of the best ways to put into practice all elements discussed in this post is with Panaya. Panaya’s Release Dynamix [RDx] solution supports an agile enterprise delivery approach based on shift left principals. Release Dynamix [RDx] manages all stages of the development process from inception to deployment, and it provides a Three Amigos approach to enterprise-wide collaboration. RDx also gives you continuous management of requirements and documentation and includes powerful tools for analysis, change management, and issue tracing.

 

 

Conclusion: Shifting Left & Moving Up

Like many revolutions, agile development started as a fringe movement that eventually defined the mainstream. Overall, the changes implemented by agile and DevOps movements have greatly improved the software development process. However, despite some major issues with the older waterfall/V-shaped models, there were also some merits of their approach to requirements management and documentation.

 

Applying a combination of the shift left, Three Amigos, and fail-fast approaches can greatly improve any development process. And applying these approaches to areas such as documentation and requirements is very useful to modern agile and DevOps practices. Writing requirements and documentation as early as possible and ensuring that they are tested and reviewed by all stakeholders reduces the number of pre-release interactions, which in turn helps you release more reliable products as well.

 

Following this article, look at your existing development process and try and find the parts that need improvement. Learn more about the shift left, Three Amigos, and fail-fast approaches and think about how they can help you. Find a way to use these approaches to improve your current requirements and documentation processes and deploy an integrated solution such as Panaya’s Release Dynamix [RDx].

 

Modern ALM for Confident Software Delivery