There are a number of methodologies that have been developed to scale Agile to the enterprise, including the Scaled Agile Framework (SAFe), Disciplined Agile Development (DAD), Large-Scale Scrum (LeSS) and Enterprise Agility. These methodologies may each have advantages and disadvantages in terms of addressing Agile non-functional requirements, but in this article I will do my best to avoid the “method wars” and instead offer a few techniques an organization of any size and complexity can employ without requiring the organization to abandon the Agile practice they have in place.
Consider Agile Non-Functional Requirements Early
It is important to address non-functional requirements early in the development process. In many cases, it is difficult or next to impossible to refactor code to address shortcomings of non-functional requirements.
To address these requirements up-front, it is important for teams to have an understanding of what the goals should be and a similar understanding of the priority of addressing each system quality attribute. In a waterfall approach, this might be done by an architect, but in an Agile environment, the responsibility falls to the development teams themselves. In the spirit of a self-organizing team, it’s important for individual team members to collaborate with their product and business partners to understand the tolerances for various attributes, combined with the experiences of senior engineers.
Encapsulation
Encapsulation of system quality attributes into re-usable code modules is an effective way to absorb the complexity of communicating and building software to meet non-functional requirements. Examples of encapsulations might include:
- Building wrappers around cryptographic algorithms for security
- Building asynchronous, distributed message bus wrappers for fault tolerance, reliability, recoverability or performance
- Using Publish/Subscribe architectures to improve extensibility by having developers create discrete modules to implement features, reducing the number of dependencies in a platform and thus reducing measured complexity. Publish/Subscribe architectures also can be designed in a manner allowing for scalability as needed, rather than after-the-fact
Identification or Appointment of Subject-Matter Experts
A true Agile team is self-organizing and should rely on making development teams responsible or the software that is developed. To scale a larger Agile team, a single individual in an architect role will find it difficult to participate in every scrum and every code review to verify all aspects of non-functional requirements are met across the board. To ensure no individual team member is over taxed, subject matter experts (SMEs) can be appointed to represent various facets of system quality.
A security SME, for example, can participate in sprint planning or sprint reviews (in a Scrum project) by acting as a product owner, requiring demonstrable stories when warranted. A security SME might create a story to build a software module that encapsulates encryption, password hashing, cross-site scripting prevention and others. The correctness of the encapsulation can be verified through black box testing and code review. Of course, such a module would be re-usable by other teams.
A distributed communications SME can similarly participate by acting as a product owner early in development to ensure that messaging between applications will be done in a scalable and reliable fashion. After the initial development of a communication bus wrapper has been developed, the SME will participate in code reviews or as necessary afterward.
A reliability SME might define system idempotency as a design goal and require the development of features that enforce the policy by creating stories to develop code to mask the complexity of such a feature. Perhaps the reliability SME creates stories to build software enforcing multi-phase, transactional processing through inversion of control techniques.
In all of these cases, the goal of having SMEs is to identify discrete, testable and demonstrable units of code that can easily be broken into stories and built as stand-alone development tasks, in keeping with the spirit of Agile development. These tasks should be readily re-usable across a much larger development team; having a toolkit of re-usable components goes a long way to reducing cross-team and cross-functional development complexity while ensuring that non-functional requirements are addressed.
Assigning Quality Tax
A quality tax is similar to time-boxing in that development effort is set aside to ensure that non-functional requirements are addressed. Extra, non-feature specific time may be required outside of pure feature development. Quality taxes should only be applied after as many system quality attributes have been encapsulated as possible. Allocating too much time to quality tax erodes the benefits that agile development provide, much the same way that allocating too much time to time-boxing would. This time can be used to perform additional reviews or used to conduct brief subject-matter specific team training.
