Diana larsen

As a result of its base in a Ph.D. dissertation, The OpenXP Solution: For the Strategic Consolidation of Multiple Diverse Perspectives on Agile Software Projects, demonstrates a step forward in business analysis for understanding requirements and in the practice of structured self-organizing for software development and other knowledge work. Moving beyond traditional requirements engineering, Dr. Sandra Walsh gives business analysts a substantive framework for gathering stakeholder perspectives and forming those perspectives into a unified place to start, then continue, as teams build software to meet a shared need. Dr. Walsh’s theory-based approach supports her assertions with confidence-inspiring detail. For product managers, business analysts, and project managers who are wondering where they can add value in an Agile development environment, this book points the way!

Ian Alexander

Dr. Sandra Walsh’s research areas include “Open Space Technology (OST)”, scenario-based development, and eXtreme Programming (XP). These three things are combined in her OpenXP, a new method for agile requirements engineering, presented in this clear and well-organised book. The basic idea is a workshop-based approach to cope with multiple stakeholders, who don’t necessarily all agree.

The book begins with a crisp introduction to requirements engineering, summarizing the challenges it was created to meet and the techniques it uses. That section ends tellingly with the statement that “challenges facing RE cannot be resolved by developing a new tool or selecting the appropriate process model, instead research needs to focus on [what Didar Zowghi called] ‘the complex interplay between a number of organisational, cultural, technological and economical factors impacting the RE process‘.” The introduction looks also at software development models such as the “traditional” (read: rusty) waterfall model, before moving swiftly to agile methods including agile RE.

Walsh then sets the scene with a chapter on research design, and a chapter named “Requirements… Grasping the Problem?”, a literature review with some degree of bite on what we used to do. My Discovering Requirements gets a couple of mentions (Walsh is clearly well-read even in the more obscure corners of RE, then) for its definition of non-functional requirements as qualities and constraints on functions, and for its onion model, though I first published that model in 2005 actually. The chapter works its way through the issues to agile methods, coming round to admirable theories of action such as Donald Schön’s “reflection-in-action”. An obvious issue is that Kent Beck’s original XP was not intended for multiple conflicting stakeholders – basically, Beck thought you’d get user stories (scenarios) one at a time from your user. Instead, one might use an empirical approach, with reflection-in-action, improvisation (as Mahaux and Mavin propose), and – take a deep breath now – a completely amethodical approach, in contrast to the old combination of rationalism, technical problem solving, planning, and plan-driven development, all anathema to agile folks.

Walsh then describes an “exploratory case study” involving an agile team; the findings are very much to do with stakeholder management, communication, and interestingly the quality of the stakeholders themselves. Walsh notes with precision that getting an unsuitable stakeholder is “generally unforeseen”, in other words a horrible surprise, and a really difficult thing to do anything about if they’re part of the customer’s organisation and you’re looking at it from outside.

The next chapters describe Harrison Owen’s (1985) Open Space Technology, with roles for facilitator, convenor, scribe, and participants, using a fictional example, and how to link up OST with XP to form OpenXP by developing “usage scenarios”, though the chapter actually talks about agile methods in general, not only the grand-daddy of them all, XP itself. OST, Walsh claims, “complies with all of the XP values, four of the XP principles, and six of the XP practices.” To state the obvious, OST couldn’t possibly be pure XP or it wouldn’t be adding anything to that approach, and the ability to cope with multiple stakeholders is a critical weakness in the original XP idea.

The book then moves on to two “confirmatory case studies” and two “independent expert reviews” to validate the OpenXP approach. One of the experts was a QA and test person, the other a software engineer. Both made suggestions, but were generally happy. The book ends with a chapter putting the whole thing together, the four facets of Walsh’s OpenXP Solution explored in the chapter being stakeholder coordination, business and IT alignment, adaptability integration, and effective communication, forming a cycle. The oddly-titled “adaptability integration” is in a way the key to the thing, as it demands that “existing RE models, methodologies, approaches and elicitation techniques” – the whole shooting match, in fact – be adapted for use within the new framework. Thus, while OpenXP may look like a stakeholder workshop method with an agile flavour, it actually allows anything from traditional RE to be woven in, if there is a need for it. This does not mean carrying on as before under a new name, as agility, since method (and its sometimes gigantic hierarchy of documentation) is no longer guaranteed. Instead, dialogue with the stakeholders becomes paramount – shouldn’t it always have been? – and OpenXP appears as a method in which the people who need something drive development. Everyone can surely say amen to that. A key question is whether this kind of thing can be scaled up.

Walsh states plainly in the final, conclusions chapter that agile development teams consist of at most ten developers, and her case studies seven at most, so OST applies to “small teams currently practicing [Agile Methods]”, and she only considers software development. Still, the integration of traditional RE with agile is an important advance, and Walsh’s analysis of the issues is incisive. Everyone grappling with the improvement of the system development life-cycle should take a look at her book.

The book has 220 pages, including some 30 pages of references; there’s no index. There are both black-and-white and colour illustrations which make the text easier to follow, along with some well-designed and helpful tables.