Clear Non-Functional Requirements
Organizations that adopt an Operations Mindset set clear, non-functional requirements (NFRs) for digital experiences. The Scaled Agile Framework® defines NFR’s as:
Non-functional requirements (NFRs) define system attributes such as security, reliability, performance, maintainability, scalability, and usability. They serve as constraints or restrictions on the design of the system across the different backlogs.
The ideal state organization does not stop at simply defining what the NFR’s should be but also building a way to monitor them in staging and production in near real time.
With this focus on NFRs, organizations can more clearly delineate the point at which a code commit caused an application to not meet a specific NFR. Organizations that don’t adopt this mindset rarely get to that granular level of detail for determining causality.
Organizations that adopt this mentality will have a healthy DevOps practice within the organization. As DevOps exists to bridge the gap between development and operations, part of their responsibility related to development is covered in the Continuous Delivery Mindset. The other portion is directly tied to operations.
As a part of the operations process, the DevOps team will work to ensure that applications are constructed with the longer-term maintainability in mind. This will include a focus on adherence to NFRs, complete stack log monitoring, and scalability planning and testing.
Test-driven development is a cycle of testing, coding, and refactoring that is used by developers to reduce defects and increase code readability and maintainability.
Building quality into every phase of the development process using continuous testing instead of waiting to test in a large batch at the end of a development cycle can substantially improve quality and costs, especially when NFRs are tested alongside functional requirements.
According to one study, test-driven development can increase initial development time by 15-35%, but that initial cost is offset by reduced maintenance costs and 40-90% fewer defects.4
Definition of Done
A Definition of Done is a checklist used by Agile teams to verify that a user story or feature is “done” and ready for acceptance. At a team level, it typically requires developers to ensure that automated tests are in place, that code has been peer-reviewed and that code has been checked in.
A more robust Definition of Done can be developed in conjunction with operations teams to ensure that a solution will be supportable once it is public. Such a pre-release Definition of Done may require support documentation to be complete, training and monitoring plans in place, or formal testing of NFRs through performance or availability testing.
Maintenance Capacity Allocation
Organizations that adopt the Operational Excellence Mindset take a purposeful approach to planning for maintenance development by setting aside team capacity to deal with unexpected production issues.
This can mean either creating a dedicated team of maintenance developers that is solely responsible for production support, or reserving maintenance capacity on a development team that is otherwise tasked with new feature development. For example, capacity allocation can be used during sprint planning to set aside 25% of a team’s time for unplanned maintenance, compared to 75% for sprint commitments.
Maintenance development need not be managed using Scrum in order to follow Agile best practices. Kanban is often a popular alternative for managing a team’s maintenance work because the flow of production issues is often unpredictable and not suited to formal planning cycles.