USER-EA: Managing by Requirements
The Problem
A while ago, I started to ask the question – why doesn’t agile development scale for large projects / programmes? Most agilists answer this question by turning it on its head and saying that you should break the problem down into smaller chunks, so that agile can deal with the problem.

Great in principle, but some problems (such as legacy system migration) just can’t be sufficiently disaggregated. As I do a lot of work in Central Government, I went onto GOV.UK and had a look at some of their collateral relating to Agile. For example, take the core Agile construct, the User Story. The following is extracted from the guidance on GOV.UK: “A user story is represented through a story card that has a title and a few lines of text.”

GOV.UK then asserts that User Stories only work with face-to-face engagement in an Agile team. Now, I absolutely support the benefits of face-to-face engagement – I have written elsewhere of the massive advantages we enjoyed when I first started in IT (in 1978): a very small set of technologies, merely a handful of job functions, and invariably co-location of technical staff and business users (many IT departments evolved initially as part of finance or R&D etc.) Since then technology has diversified and hence skill sets and functional groups have branched and we have witnessed the development of outsourced and remote-working teams, resulting in massive communication problems

Couple this with the nature of the problem space of legacy systems migration, and my initial temptation was to conclude that agile is not applicable to these large-scale, hoary problems. Legacy systems have:

• multiple components which are
• tightly-coupled and therefore have a
• mesh of inter-dependencies.

Yet I couldn’t accept that something with such strong advocates could have this major gap in its applicability, and I my thinking led me to believe that the problem is not the method, but the interpretation of it.

The User Story has great value as a communication tool between the technical and non-technical. It is a good way to express the bedrock of IT – REQUIREMENTS. Almost every software engineering approach emphasises the need to elicit high-quality requirements, and almost every project disaster can be traced back (at least in part) to requirements that have been defined inadequately.

Requirements are the way that Technical and non-Technical people communicate. User Stories are an excellent way to do this because they focus on the user’s perspective (As a …..) and they are Outcomes-focused (I want to….so that….)

Requirements are also the lingua-franca of communication between various technical groups. This is especially so when we embrace the world of Service Oriented Architecture, which is founded on clearly-defined contracts (expressing reciprocal obligations or requirements.)

Yet, to quote GOV.UK again on the topic of User Stories: “You might (my emphasis) want to include a list of acceptance criteria…Sometimes writing acceptance criteria on the story card is useful where the user or user representative is not immediately available but is no substitute at all for face-to-face conversation.”

“You wouldn't go shopping without a shopping list”

My comments on the above:
• There are other “Users” of a solution, such as the Call Centre Operator, the System Administrator, the Security Administrator etc who all “use” the system. The wants and needs of these users does not have to be a trade-off with the wants and needs of the Citizen. In other words, User Stories (Requirements) need to address a number of different perspectives

• If you apply the principles of Lean Management to Requirements Gathering, why wouldn’t you capture Acceptance Criteria at the point where you are discussing requirements with the user? Having managed to get some (usually rationed) time in his / her diary, why wouldn’t you want to capture Acceptance Criteria?

• An emerging trend in Operational Management is to minimise the number of “hand-offs” in a business process. One of the problems with User Stories is that they tend to equate with a task. However, think of a call to a utility company or mobile phone provider about a query that is just slightly out of the ordinary? Each person you deal with is very polite and efficient, but what is the overall effect of hanging around in queues and listening to the same music over again, and then repeating the same answers to the same questions each time you are passed from one group to another? Any user of a solution will tell you that it is the navigation through a process, and the number of steps taken, (i.e. the process) which causes the frustration / dissatisfaction.

• It is established good practice that “design-up-front” is the most efficient way to deliver solutions. Re-work of a solution through badly or inadequately articulated requirements, is far more expensive than “right-first-time”

• Many users have used their business systems for 10 to 15 years. They know the world of technology has moved on (because they have modern technology at home) but they currently perceive that is a different world. They do not know what modern business systems can do for them. Users do not know what they don’t know.
The Solution
Our approach is based on a marriage of agile prototyping to elicit requirements, and the construct of the Zachman Framework. By aligning the User Story (with some extensions) to the Zachman Framework, and by following a plan which emphasises design-up-front, we are able to:

• Identify outcomes-focussed solutions that have “buy-in” from all types of users
• Inform project planning with priorities based on User Needs and business “Pain-points”
• Identify technical dependencies
• Establish early visibility of acceptance criteria and the core components of a test plan
• Provide the baseline from which it is possible to provide Impact Assessments in response to Change Requests
• Be able to trace the above back to the original Business Case
Concluding Comment
When people are subjected long-term to the effects of something that is badly broken, they are ultimately driven to "an equal and opposite reaction." This reaction is sometimes necessary to "break the mould" but experience has shown that, ultimately, the optimum solution is a compromise (or hybrid) - the pendulum comes to rest at the perpendicular. The approach outlined above provides an approach which is a hybrid between Agile and more traditional requirements management. It retains the benefits of Agile in terms of eliciting requirements, but marries that method with the ability to maintain traceability from business case to delivered solution.

If you want to know more, please contact us on:


Sign up for extra content

Register here to access premium content - the only information we require is your user name and a valid email address

Follow me

Latest private posts

Latest public posts

—1st July 2014
—18th April 2014
—9th April 2014