Aligning Computing Systems with their Environment: An Agile Perspective
Frank Keenan
1
and David W. Bustard
2 1
Department of Computing and Mathematics, Dundalk Institute of Technology, Ireland frank.keenandkit.ie
2
School of Information and Software Engineering, University of Ulster, Coleraine, BT52 1SA, UK dw.bustardulster.ac.uk
Abstract
Ideally, all computing systems should be closely aligned to the context in which they are used. Unfortunately,
although the increasingly popular agile software development methods attempt to be customer oriented,
the practices involved tend to focus more attention on the software product. The purpose of this paper is to
examine this imbalance in relation
to eXtreme
Programming XP and suggest how improvements might be achieved through the use of Soft Systems
Methodology SSM. A process is described that combines parts of SSM with XP while still attempting to
remain within the general agile philosophy. An example is used to illustrate the process proposed.
1. Introduction
All computing systems operate in a specific context or environment. Essentially, an environment is that part
of the world that affects or is affected by the computing system. This is the same concept as Jackson’s machine-
domain relationship [1]. Ideally, a computing system should be ‘aligned’ with its environment to provide it
with optimal support and such alignment should be maintained as circumstances change. In practice,
however, this is a weak area in the development of many systems. A recent report from the Royal Academy
of Engineering [2], for example, identifies the “lack of a clear link between the project and the organisation’s key
strategic priorities” as the most common cause of project failure. This is a longstanding problem, with a
survey in 1996 indicating that less than 25 of systems integrated business and technical objectives properly
[3].
The underlying issue seems to be that developers spent insufficient time attempting to understand the
environment in which a computing system will be used. A recent UK Government report [4], for example,
argues that IT practitioners need an understanding of the business and the processes currently employed, if an IT
system is to achieve the intended outcome. This weakness is also implied in the third cause of failure
listed in the Royal Academy report [2], namely a “lack of effective engagement with stakeholders.”
The agile approach to software
development recognises this general issue by having ’customer
commitment’ as one of its guiding principles, the others being the promotion of individual and group
interactions, a focus on the working product, and the ability to respond to change [5]. Agile methods actively
involve users in establishing, prioritising, and verifying requirements. This close collaboration, supported by
feedback from frequent delivery of software, facilitates the alignment between a computing system and its
environment.
eXtreme Programming XP [6], the most widely adopted and best documented agile method, was created
to address the problems caused by the long development cycles evident in traditional development approaches.
Beck describes XP as a lightweight discipline of software development, based on values of simplicity,
communication, feedback, courage, and respect [7]. Recently it has evolved from a fixed set of twelve
practices [6] to what is now described [7] as a “process of experimentation and improvement,” with no “given
software process that can be pointed to as the one and only definition of Extreme Programming.”
One original key practice of XP was the use of Gilb’s evolutionary development method [8] of short releases,
which is now represented by incremental deployment in the recent definition [7]. This approach allows systems
to be progressively refined from the feedback obtained from each release.
Another original key practice was that of the on-site customer [6], which is now covered by two practices:
real customer involvement and whole team development [7]. An expectation of the person in the customer role is
that they will use their knowledge of the environment to ensure that what is developed is linked to the context in
which it will be used.
Various difficulties have been reported with the XP approach, in general, and the customer role, in
particular. One is that the XP process begins at the requirements specification phase, with no suggestion of
any pre-specification analysis activities [7, 9]. Also, it encourages a focus on short-term product development,
Proceedings of the 13th Annual IEEE International Symposium and Workshop on Engineering of Computer Based Systems ECBS’06 0-7695-2546-606 20.00 © 2006
IEEE
emphasized by the YAGNI mantra You Aren’t Going to Need It. This discourages a consideration of longer-
term business strategy or a detailed analysis of the business context, which is typically more complex than
it appears initially. The recent version of XP has begun to acknowledge the importance of wider issues by
including the quarterly cycle practice, concerned with checking on “alignment with larger goals” and taking
account of the “big picture” as progress is made.
The essential problem is that there are few guidelines on the implementation of the customer role to suggest
how interaction with developers should occur. In particular, it is unclear what models or system
descriptions should be used to build a shared
understanding of both the problem situation and the computing solution being proposed. Various authors
have offered advice. Jepsen [10], for
example, recommends spending a great deal of time and energy in
investigating contrasting stakeholder viewpoints in complex situations to help in “understanding the
business” [11]. Stephens and Rosenberg also highlight the value of spending time ‘up front’ with as many
customer representatives as possible and exhorting developers to “get down into the trenches and find out
the real problems that need to be solved” [12]. Van Deursen [13] similarly identifies benefit for the
customer representative in having “systematic ways for diagnosing problem situations,” which again means
analysing the environment adequately. Without this activity, an XP project can become too inwardly
focused.
The purpose of this paper is to propose a systematic way of analysing an environment in support of agile
development. It starts by examining the concept of alignment between a computing
system and its
environment. This is followed by a brief summary of Soft Systems Methodology SSM [14], a general
technique for analysing any situation considered
problematic. The final sections suggest how the process and models of SSM might be linked to XP to better
define the customer role, which also helps to improve the match between the computing system produced and
the context in which it will be used. This is supported with the use of an example.
2. Computing-Environment Alignment
