I was working through a requirements session with an IT team from a large global company this week, and several times the topic of agility came up. There are as many perceptions of where analysis practices fit within the ill-defined boundaries of agile practices, which always makes for interesting discussion. One of the areas where this occurred is the analysis of the quality requirements for a system, which led me to consider the notion of a quality spike.
For all the companies I have worked with as an employee or as a consultant, whether they suggest they are agile or not, there have always been issues in the area of understanding the scope of work. One of the recurring areas where many teams fail to specify the needs of what they are about to build (or indeed, buy), is the area of quality. Everyone will suggest that quality is of utmost importance, yet most fail to precisely quantify what quality means to them in the context of this product.
There are many reasons for this deficiency. Some take the term quality to align with qualitative, and therefore don't grasp that these can and should be expressed quantitatively. Suggesting that a system needs to be fast or user-friendly or secure just doesn't cut it when we are trying to test against these terms, sorry. Others struggle to make the leap from the taxonomies that generally cover the landscape of quality, but are not easily expressible in quantified terms. It can take a great deal of time in the school of hard knocks to recognize that user-friendly needs to be expressed as a combination of a wide range of quantifiable ideas: acceptable response times and feedback, adherence to GUI standards, consistent error-handling mechanisms and a host of others. Again, most teams don't do a good job in this area, and the results are often either accidental adequacy, or more often a trip back to the drawing board.
With agile teams, there is a notion of an architectural spike: the idea of analyzing just enough of the necessary architecture of the system that will allow you to progress forward with the current set of stories so that the risk of major refactoring is minimized. A powerful concept that can work very well for the functional considerations of the system being built. I would suggest that there is a sister spike that should take place around the same time: a quality spike can give us just enough insight to ensure that we are building to meet the quality needs of our system.
Indeed, if we perform a reasonable quality analysis at this point in the game, agile practices actually put us ahead of the curve when compared to traditional approaches (it pains me to express it that way - constant readers will know that I don't see the world in these black-and-white, us vs. them terms). If maintainability is a quality attribute that is of interest to us, then the principles of a shared code base, ongoing refactoring and frequent releases play to our favour. Indeed, these practices can be expressed as requirements (if you don't have a strong distaste for that term) that support our building a system that is maintainable. Similarly, test-driven development and a unit test infrastructure support the testability of the system (as does the frequent releases practice - these individual practices do not necessarily only support one attribute of quality for our system). Refactoring supports reusability, the list goes on. For those quality attributes that are of interest to the development organization, agile practices serve to inherently produce a higher quality system.
For those quality attributes that are of interest to the end-user, though, there is value in performing that analysis as a quality spike. As these attributes are strongly domain and application dependent, and will vary in importance dramatically, we cannot simply rest on our development practices to ensure that we meet these quality needs. We need to sit down with our customer and decide which attributes are most important (or even relevant) and translate these into a series of measurable characteristics (as best we can at this time, remember it is a spike) that we can then build to as we flesh out our stories.
As many of these attributes (such as security, usability, interoperability, and others) weave throughout all of the stories we are building, consciously articulating these alongside our architectural spike gives us a much higher likelihood of efficiently meeting our goals. Indeed, some of these may be critical enough to drive stories of their own, stories we might otherwise only consider much later in the game.
Take advantage of special member promotions, everyday discounts, quick access to saved content, and more! Join Today.