Operational Quality in Agile

Greg Margolin:

Operational Quality in Agile

Practitioners have a lot of different and occasionally contradicting opinions when discussing non-functional requirements. We are able to detect however two major points of agreement:

a) the term non-functional requirements is universally disliked as a misnomer, b) almost everybody agrees that quality attributes such as: performance, availability, usability, security, scalability, effectiveness, and efficiency etc. are absolutely vital for the business.

Once we introduced a better term -- Operational Quality for non-functional requirements -- a more important question comes up: where in today’s business practice should Operational Quality should be dealt with? As more and more organizations today are engaged in Agile development, we can narrow the question to the the following: what is the best way to deal with Operational Quality attributes in the Agile development process?

Mike Cohn, author of “User Stories Applied” and other essential books on Agile development, took on this question on his blog a while ago. Mike’s post produced an interesting and illuminating discussion. Mike offers a way to incorporate such requirements (he calls them constraints) in a user story writing template -- “As a <type of user>, I want <some goal>, so that <some reason>”. Mike also suggests to treat performance and other Operational Quality attributes as an ongoing tax that should be paid by the team forever. A team is supposed to figure out the best time and way to deal with such a tax. In our opinion, there is a better way to incorporate Operational Quality in Agile development processes.

We believe that responsibility for Operational Quality should be shared by the whole organization, not only development and QA. The recent industry trend of creating devops (development + operations) teams supports our point that the industry is moving to a much closer system centric cooperation between different functional teams. As business pressure on IT to deliver mounts, devops are compelled to share tools, practices and processes. In our opinion business should be involved early on in the Operational Quality process as well. Below we will suggest how this could be done.

Historically Agile development was made possible by better development tools and practices that often originated in open source communities. Similarly, today, virtualization and cloud computing are enabling IT operations to become much more responsive to business needs. While the devops movement constitutes a step in the right direction, we believe this is still not enough. The practice today is a combination of shared practices, tools, and processes. Devops and business owners need to have their own shared management framework to align goals, technical means, resources and practices. We at GQP believe that an enterprise-wide embrace of Operational Quality could serve as such a framework.

In practical terms this means that all teams involved should address user stories as business owners. The question is not only about capturing user requirements and building the right kind of software fast, but also doing it effectively and efficiently. A business owner always has the interests of his users in mind, but he is also sensitive to the costs involved in servicing his users. According to the Agile Manifesto, the eighth of twelve Agile development principles states: “Agile processes promote sustainable development.The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” No organization can sustain development indefinitely if the operation is not efficient, and the cost of producing, deploying, and operating software is too high.

In order to be efficient and effective, in addition to user stories, a team should consider “owner” stories as well. To use the template suggested by Mike Cohn: “As a business owner, I want to be able to scale the system to a specified level, so that the system can sustain the companies current level of business activity”. Or, “As a business owner, I want to be able to provide my customers with a secure way of conducting their transactions at my site, so I can keep their trust”. Or, “As an e-merchant, I need to provide high speed catalog searches at my site, in order to sharply decrease instances of users abandoning their shopping carts”. The owner stories above address key attributes of Operational Quality: scalability, security, responsiveness respectively.

Once stakeholders start to think as business owners, we can think about Operational Quality not as a tax to incur, but as an investment, with the goal in mind to produce a desirable, highly valuable business asset. Stakeholders in the open source development communities are not being told by external business owners when to produce their software -- they make a decision of what to produce, when, and at what cost. People in open source are investors -- they are investing their precious time and they want to see business results.

There is a lesson to be learned by business owners in traditional enterprises as well -- it is all right to demand more from IT, but you can not treat IT as a miracle producing machine. Instead business managers should be educated about the real costs of Operational Quality, and should treat it as a careful long-term investment. We believe that the discipline of Operational Quality with shared responsibilities and shared goals would allow enterprises to collect the right kind of data, to create proper metrics, put people on the same page, and build a lot of business value for business owners and users alike.