Agile Requirements

Origin of Agility

If you work in systems development, especially if you are developing software, it is unlikely that you have not come across the idea of being Agile. But perhaps you are not aware of where the term comes from. The agile manifesto (a set of principles) is the result of a collaboration, started in 2001, between a group of systems engineering specialists who realised that software development methodologies and documentation were slowing us down. In fact many aspects of the way we were developing software were preventing us from carrying out the purpose of our real jobs: to deliver valuable software that helps our customers to do their work.

Since the birth of the manifesto many systems developers in organisations all over the world have committed to applying the agile principles to the way that they build systems. More recently business analysts and requirements specialists have been considering how the agile principles can be applied when discovering and communicating business requirements.

Users of the Volere requirements techniques often discuss how the techniques can help them to be more agile. In other words how can the techniques improve ability to deliver valuable and relevant software more quickly in their environment? During a recent discussion about this subject on the Volere Linked In group http://www.linkedin.com/e/vgh/2491512/ John Palmer suggested that it would be valuable to draw parallels between the agile principles and how Volere techniques address each one of them. That is what this article is all about.

Addressing the Agile Principles

The following lists each of the Agile Principles (in italics) followed by the ways that Volere techniques address that principle.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Volere is based on well established systems engineering principles. The knowledge model and template provide a linguistic structure for defining and connecting your requirements knowledge at a number of levels. This formality maximises the freedom to work in whatever order or to whatever level of requirements detail will facilitate the earliest delivery of software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

You can’t deal with changing requirements unless you know what you are changing from. Volere techniques provide quick and communicable ways of keeping track of what you know and being able to recognize and integrate changes regardless of when they happen.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Back to the knowledge model which identifies large and small functional chunks that can be delivered independently whilst keeping track of how they connect to other parts of the business problem.

Business people and developers must work together daily throughout the project.

Using the Volere techniques you can group and express requirements knowledge from both a business point of view and a development point of view. And most importantly keep track of the connections.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Project sociology techniques support the differences between individuals and the importance of each project group making a strategy that suits its own sociological mix.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Volere is content driven not form driven. Our approach, whenever possible, is to talk face to face and leave a trail if someone else needs to pick up the information. The trail should ideally be as a result of having the conversation and can be in any form: notebook, video, diagram on whiteboard, photograph, murder book, chosen model...Depending on the project sociology this might be the only documentation you need.

Working software is the primary measure of progress.

Of course. Volere makes all requirements testable so that “working” can be proved. This is also helped by the integration of prototyping and simulation at any stage of your development process.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Volere supports this by encouraging a consistent language so that everyone involved can contribute to and share in the buzz that progress provides.

Continuous attention to technical excellence and good design enhances agility.

Volere techniques provide ways of articulating design alternatives, comparing and choosing the best and recognizing good design patterns.

Simplicity--the art of maximizing the amount of work not done--is essential.

Volere techniques focus on identifying the essence of the problem and selecting the parts that provide the highest business value.

The best architectures, requirements, and designs emerge from self-organizing teams.

Volere provides the means for the self-organizing team to communicate with the overall enterprise.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The Volere techniques address both sociological and technological concerns and prompt people to look for both technical and social reasons for success and failure.

Last Word

To maximise your potential for agility you need to be able to distinguish techniques that support your ability to deliver valuable software and those that inhibit you. Any technique that forces you to do things in a prescribed order, to a fixed level of detail, in a specific form is a technique that will inhibit your agility.

The Volere techniques enhance your ability to be agile by supporting your thinking and communication with your colleagues and encouraging you to be innovative and extemporaneous. The techniques are based on solid systems engineering principles like: partitioning, looking from different points of view, communication of scope, linguistic elements appropriate to the domain, making abstractions, differing levels of detail. You can work in the way that is appropriate for your project and produce a knowledge trail as a result of doing your work.