Agile Development – A Curse or a Blessing for Requirements Engineers?

Last week, the BCS Requirements Engineering Specialist Group organised a workshop on “Agile Development – A curse or a blessing for requirements engineers?”. This was held in a fully packed room at the BCS headquarter in London. By coincidence, there was another talk an agile organised by the BCS Central London branch in the very next room, so discussions in the hall were all buzzing about agile and some people weren’t quite sure which room to go to. The demand for information about agile keeps growing. This is probably due to the growing pressure to ditch large-scale projects with rigid contracts in favour of smaller-scale agile projects notably for Government IT projects, but also to the still widespread misunderstanding and misuse of agile methods, the difficulty of sorting out facts from hype in many agile presentations, and a legitimate concern of requirements engineers and business analysts about the impacts that such methods would have on their work.

The event kicked-off with a talk by Keith Braithwaite who described how requirements are discovered in agile projects through user stories and acceptance tests with a greater emphasis on conversations and less on documentation. But what makes a good user story? To be accepted for implementation, user stories have to satisfy the INVEST criteria; they must be Independent, Negotiable, Estimable, Small and Testable. To discover and organise user stories, one typically starts from larger “epic” and organise them in story maps that provides an end-to-end description the users’ tasks and goals. Keith explained he first discovered the benefits of test-driven development that is central to agile development many years ago while working on system to optimise the placement of GSM antenna for which he was developing UML models and Z specifications. He used this system as example to illustrate the technique of story mapping. He contrasted this form of “low resolution model” –a phrase that I liked– to the more detailed UML activity diagrams or BPMN models one could also write for such models.

There were lots of discussions during and after the talk questioning some of the assumptions behind agile methods. As usual, it is impossible to go to the bottom of things in one short evening, but I found the event interesting in teasing out different sensibilities on this topic, from the young enthusiasts to the veterans who’ve seen it all before.

One thing that wasn’t discussed so much during the evening is the impact that these changes have on the work practices of requirements engineers. This is something I’d like to come back to at some point. In the meantime, I would recommend the research done by Angela Martin, Robert Biddle and James Noble described in their paper “An Ideal Customer: A Grounded Theory of Requirements Elicitation, Communication and Acceptance on Agile Projects”. It describes the many roles requirements engineers play in agile projects (geek interpreter, technical liaison, negotiator, diplomat, customer coach, super-secretary, etc.) and the difficulties they face in fulfilling these roles, notably in sustaining the pace of having to deliver quality user stories at regular interval while keeping constantly engaged with both developers and large numbers of stakeholders in the client organisation. It also describes some of the practices that have emerged to try overcome to these difficulties, for example by having iterations where programmers work on technical tasks (e.g. repaying technical debt and setting up support tools) so that it gives customers time to think ahead, organising customers boot camps on agile processes, and having programmers work as apprentices in the customer’s organisation. These are probably not enough to fully resolve the workload problem for requirements engineers and customers, but they can somewhat lower their impacts.

Goal Modelling with Pelorus

The first paper on goal-driven requirements acquisition was published in 1993. Since then, it has been followed by a very large number of research papers, a comprehensive book, and a growing number of industrial applications, but goal modelling is still something that is mostly done in universities and not so much elsewhere. In industry, current practices are based on use cases, process modelling, and user stories; you will rarely meet a requirements engineer or business analyst who knows about goal modelling. This is despite a broad agreement that existing requirements engineering practices don’t work so well, precisely because they focus too much on the processes and the software (the how) and not enough on the goals (the why). So how can we fix this? How can we make goal modelling more broadly used? Ian Alexander, one of the early adopters, says we’ll know we’ve been successful when we’ll regularly hear analysts saying things like “this use case relates to this goal that contributes to this other goal and relies on this domain assumption.” To achieve this, we’ll need to simplify and communicate better the most essential ideas contained in our technical research papers.

With this in mind, I was captivated by Vic Stenning’s talk “Pelorus: a Tool for Business Change” at a meeting of the BCS Business Change Specialist Group last Thursday. The talk consisted purely of discussions about goals, how to elaborate goal models by asking WHY and HOW questions, how to avoid confusing goals and activities, how to identify stakeholders by asking WHO questions, how to define goals with measurable factors and targets, and how to anchor risks analysis on specific goals instead of doing it in a vacuum. Every concept had an almost direct relation to some of our research papers: goal-driven elaboration process, goal refinements, measures of partial goal satisfaction, obstacle analysis. The only ideas I could see missing from the discussions were conflict analysis and reasoning about alternatives.

And Pelorus even brings something new and exciting to goal modelling. It is a lightweight tool for collaborative modelling. The target domain for Pelorus is the domain of business change initiatives. Studies show that about 50% of all such initiatives fail. There are many reasons for this, but one of the main factors is a failure to engage key stakeholders early enough in the design of the changes. Vic quoted Rosabeth Kanter: “Change is disturbing when done to us, and exhilarating when done by us“—a view I agree with entirely. The focus in Pelorus is on providing a platform that allows large groups of stakeholders to collectively define and manage their goals for a change project. Unlike other goal modelling tools such as Objectiver or jUCM-Nav, it is not meant to be used for a detailed goal-oriented elaboration of complete software requirements specifications.

Pelorus is a web-based tool with a deliberate minimalistic design. The main concept is that of goal, a goal can support other goals, goals must be well-defined and measurable, and—apart from a few of other things such as the goal-based risk analysis— that’s it. This is goal modelling stripped to its bare minimum! Keeping it simple is essential to allow a diverse group of stakeholders to contribute directly to its elaboration, but it also ensures that everyone focuses on the goals and noting else. This minimalistic design is reflected in a clean and simple user interface that you can see in their videos. Oh, maybe it’s a detail, but in Pelorus goal models are not called models, they are maps. This is a term that was also used by another company selling goal-oriented techniques, so there might be something here.

Once the goal map has been defined, Stakeholders continue to use Pelorus to supervise the delivery and harvesting of the changes. This transforms the goal model in a form of “living” business case that, unlike traditional business cases that are written once and then forgotten, can evolve throughout the change delivery. This is another interesting idea that resonates with my current research interests on system evolution.

Pelorus could be a good example of how research ideas transfer to practice, except that Vic Stenning had never heard about goal-oriented requirements engineering. The main influence behind Pelorus, he says, is critical systems thinking –although, as far as I know, critical systems thinking doesn’t include the kind of goal modelling approach present in Pelorus. Sure enough, the concepts of goals, goal decomposition, measurable objectives, and perhaps even obstacles are so common that one doesn’t need to have read or heard about goal modelling to come up with the same ideas. Yet, during the talk, the resemblances with the research papers and tutorial on goal-oriented requirements engineering was striking. One person in the audience observed that these ideas are very much in the air at the moment. As a researcher who sometimes has to justify the public money spent on his research by showing it has an impact, I like to believe that we have played at least a small role in putting these ideas in the air. I hope Pelorus and other similar tools will continue to push these ideas forward.