Mindfulness and agile Software Development

Abstract

The field of information systems development (ISD) is still not well understood and suffers from a lack of sustainable theories which are firmly based on research of ISD practice. This is also true for agile software development (ASD). In this paper, we develop a framework based on the theory of mindfulness and map the main characteristics of mindfulness to the most prominent features of ASD. By applying the framework to a case study of ASD practice we demonstrate the relationship between the theory of mindfulness and ASD, and show the usefulness of our framework as a contribution to theorizing about ASD and to a better understanding of ASD in practice.

Full text

19th Australasian Conference on Information Systems Mindfulness and Agile Software Development
3-5 Dec 2008, Christchurch Matook & Kautz
638
Mindfulness and Agile Software Development
Sabine Matook
UQ Business School, The University of Queensland,
Brisbane, QLD, 4072, Australia
Email: s.matook@business.uq.edu.au
Karlheinz Kautz
Department of Informatics, Copenhagen Business School, Frederiksberg, Denmark
Information Systems, Technology & Management, Australian School of Business,
University of New South Wales, Sydney, Australia
Email: Karl.Kautz@cbs.dk
Abstract
The field of information systems development (ISD) is still not well understood and suffers from a lack of
sustainable theories which are firmly based on research of ISD practice. This is also true for agile software
development (ASD). In this paper, we develop a framework based on the theory of mindfulness and map the
main characteristics of mindfulness to the most prominent features of ASD. By applying the framework to a case
study of ASD practice we demonstrate the relationship between the theory of mindfulness and ASD, and show
the usefulness of our framework as a contribution to theorizing about ASD and to a better understanding of ASD
in practice.
Keywords
Information systems development, agile software development, mindfulness.
INTRODUCTION
The field of information systems development (ISD) is still not well understood and suffers from a lack of
sustainable theories, which are firmly based on research of ISD practice (Kautz, 2004). This is also true for agile
software development (ASD). The concept ASD serves as an umbrella for a number of pragmatic approaches,
which have emerged out of a critique of traditional, document driven development approaches (Highsmith,
2002). ASD has gained immense popularity among practitioners and academics since the late 1990ties as an
approach, which flexibly deals with change as it is encountered in software development practice, and no
downturn of this interest is in sight (Abrahamsson et al., 2003). However, Conboy and Fitzgerald (2004) state
that in the area of ASD a lack of theoretical grounding exists and they are supported by a more recent literature
study by Dybå and Dingsøyr (2008).
Also Highsmith (2000), one of the most significant proponents of ASD, is aware of the pragmatic grounding of
ASD and recognises the need for theoretical grounding as, “techniques without a theoretical base are reduced to
a series of steps executed by rote.” He asserts that complex adaptive systems (CAS) theory builds the basis for
agile development methods (Highsmith, 2002). However, this claim is a post-rationalization, as the theory, for
example in Highsmith’s own writing (Highsmith, 2000; Highsmith, 2002), is used in a very lax manner to justify
what is done in practice (Vidgen and Wang, 2006).
Against this backdrop, in one of the few attempts to provide a theoretical grounding for ASD, Vidgen and Wang
(2006) used CAS theory to built a framework and showed its usefulness in a case study where they found a
strong correspondence between CAS theory and ASD practice. In a follow-up study they (Wang and Vidgen,
2007) developed another framework, which takes as a starting point the four pairs of values, which according to
the original advocates of agile development guide ASD and which can be found in all agile development
methods.
These values have been put down in the so-called agile manifesto and they are: (1) individuals and interactions
over processes and tools, (2) working software over comprehensive documentation, (3) customer collaboration
over contract negotiation, and (4) responding to change over following a plan (see www.agilemanifesto.org).
Based on a comparative case study, which investigated two projects Wang and Vidgen (2007) concluded (1) that
an agile process is able to balance order and chaos and to poise at the edge of chaos, in the region of emergent
complexity and (2) that agile processes are not the opposite of structure and planning, rather, structure and
planning are integral elements of agile processes.

19th Australasian Conference on Information Systems Mindfulness and Agile Software Development
3-5 Dec 2008, Christchurch Matook & Kautz
639
Recently, Butler and Gray (2006) put forward an alternative theoretical grounding. They argued that the recent
interest in ASD methods also reflects a desire for techniques that promote mindfulness. Mindfulness includes
the attention to detail, the willingness to consider alternatives, and responsiveness to changes (Langer, 1997). It
endorses openness to novelty and an orientation in the present. As such, it shows some similarities to the four
privileged agile values. Butler and Gray (2006) continued their argument and stated that mindfulness theory
might provide a way to explain how ASD can contribute to the production of reliable information systems, and
why developers’ departures from structured methodologies may benefit their projects. They, however, did not
provide any framework for studying the relationship between mindfulness and ASD, neither from a theoretical
nor a practical perspective. In this paper we develop such a framework and map the main characteristics of
mindfulness on the four pairs of agile values. By applying this framework to a case study of ASD practice, we
demonstrate the relationship between a theory of mindfulness and ASD and show the usefulness of our
framework as a contribution to theorizing about ASD and to a better understanding of ASD in practice.
The remainder of the paper is structured as follows: In the next section we present the theoretical background on
mindfulness and agile system development. We then introduce the case setting and the research approach, which
we applied. Following, we present instances of mindful behaviour from our empirical data and briefly discuss
our findings. Finally, we provide some conclusions.
THEORETICAL BACKGROUND
Butler and Gray (2006) present a conceptual essay, in which they discuss the relationship between reliability,
mindfulness and information systems and its implications for IS use and development. They base their argument
mainly on the work of the social psychologist Langer (1992, 1997) and the organisational theorists Weick and
Sutcliffe (2001)1. The following presentation of the concept of mindfulness and its relationship to agile software
development, which provides the grounding for the theoretical framework of our study largely follows these
texts. According to Weick and Sutcliffe (2001) mindfulness stresses situated human cognition as the solution to
individual and organizational problems and Langer (1997) puts forward that a mindful response “to a particular
situation is not an attempt to make the best choice from among available options but to create options.” Thus,
Butler and Gray (2006) suggest that mindfulness-based approaches to problem solving, such as ISD, explain the
ability of individuals and organizations to achieve performance in changing environments. The ability depends
on how both, individuals and organizations cognitively think: how they gather information, how they perceive
the world around them, and whether they are able to change their perspective to reflect the situation. To reflect
the distinction between individuals’ and organizations’ abilities they distinguish between individual and
collective mindfulness. In the subsequent subsections we will introduce these concepts in more detail.
Individual Mindfulness
According to Langer (1997) at the individual level, mindfulness lays emphasis on the ability to constantly create
and use new categories in the perception and interpretation of the world. In contrast, Chanowitz and Langer
(1980) describe mindlessness is a state of reduced attention, which results from premature commitment to
beliefs that may not accurately reflect the phenomena at hand.
To conceptualize mindfulness, we follow Langer (1997), who distinguishes five constituent components, which
are presented in Table 1: (1) openness to novelty, (2) alertness to distinction, (3) sensitivity to different
contexts, (4) awareness of multiple perspectives, and (5) orientation in the present.
Openness to novelty is the ability to reason about and to cope with novel kinds of stimuli. Alertness to
distinction is the ability to compare new categories with existing ones and decide if things are the same or
different. This is specifically important when defining the nature of a problem as it can help to decrease the risk
of misdiagnosing a problem. Sensitivity to context is an awareness of the characteristics of any specific
situation, which an individual faces. This is a prerequisite to being able to notice when situational traits change.
Awareness of multiple perspectives enables people to perceive and analyse things from different and opposing
points of view. Finally, individuals, who are oriented to the present, devote more of their attention to their
immediate situation. In this context Sternberg (2000) argues that people, who pay attention to their actual
surroundings, behave more mindfully than those, who are careless about what is happening.
People, who are mindfully engaged in a procedure, perceive changes in an environment. Therefore, there is a
probability that they are more creative and that they are more likely to adopt new ways of working. Thus it is
also more likely that they find innovative solutions to problems and that they by altering their actions will take
advantage of new situations.
1 The idea of mindfulness is however much older; it is an ancient Buddhist concept linked to Buddhist
meditation and has been related to ‘the art of conscious living’ (see Kabat-Zinn, 1994).

19th Australasian Conference on Information Systems Mindfulness and Agile Software Development
3-5 Dec 2008, Christchurch Matook & Kautz
640
Table 1. Aspects of individual Mindfulness
Aspect Characteristic
1) Openness to novelty Ability to reason about and to cope with novel kinds
of stimuli
2) Alertness to distinction Ability to compare, contrast and judge about how
things are the same or different
3) Sensitivity to different contexts Awareness of situational characteristics to notice
when and whether a setting changes
4) Awareness of multiple perspectives Appreciation of things from different and opposing
points of view
5) Orientation in the present Individual’s attention to their immediate situation
and their actual surroundings
Collective Mindfulness
The relation between organizational mindfulness and individual mindfulness is like the relation between
collective learning and individual learning. Collective mindfulness presents a theoretical elaboration of the
cognitive concepts related to individual mindfulness on the organizational level such as a business unit, a work
group, or a whole organization. Collective mindfulness is also known as organizational mindfulness (Butler and
Gray, 2006).
In collective mindfulness, existing expectations are continuously scrutinized and refined according to new
experiences in order to be able to invent new expectations for dealing with unprecedented situations to improve
foresight and current functioning (Weick and Sutcliffe, 2001). Examples include hospitals providing services
under tight resource constraints, but also mundane organizations such as restaurants. According to Weick and
Sutcliffe (2001) there are five key aspects, which characterize collective mindfulness. These are (1)
preoccupation with failure, (2) reluctance to simplify, (3) attention to operations, (4) commitment to resilience,
and (5) migration of decisions to expertise (see Table 2).
Preoccupation with failure focuses on the utilization of errors and failures as a way of improvement.
Emphazising errors and failures is helpful to prevent overconfidence in and inattention to a given situation. The
organizational desire to continuously view problems from different points of view is referred to as reluctance to
simplify. This is helpful in order to recognize minor anomalies and errors and to react appropriately to prevent
larger failure in the future. Attention to operations focuses on individuals’ (capability to develop an) integrated
overall picture of the operations in an organization or project. Commitment on resilience as opposed to focus on
planning is the ability to cope with problems and dangers as they occur. Finally, the migration of decisions to
expertise allows for circumventing organizational hierarchies and for migrating the problems to those experts,
who are most capable of solving them.
Table 2. Aspects of collective Mindfulness
Aspect Characteristic
1) Preoccupation with failure Utilization of errors and failures as a way of
improvement
2) Reluctance to simplify Organizational aspiration to perceive problems from
different points of view
3) Attention to operations Individuals’ capability to have an integrated overall
picture of the operations in an organization or project
4) Commitment to resilience Ability to cope with problems and dangers as they occur
5) Migration of decisions to
expertise Migrating the problems to the experts, who are most
capable of solving them, regardless of hierarchical levels

19th Australasian Conference on Information Systems Mindfulness and Agile Software Development
3-5 Dec 2008, Christchurch Matook & Kautz
641
In summary, Butler and Gray (2006) propose that collective mindfulness is associated with cultures and
structures that promote open discussion and it increases organizations’ ability to perform in dynamic, unstable
environments. They put forward that “…collective mindfulness is not simply the result of having individually
mindful personnel. In general, mindfulness involves the ability to detect important aspects of the context and
take timely, appropriate action” (Butler and Gray, 2006, p.216) and continue that “… collective mindfulness
requires organizations to couple the ability to quickly detect issues, problems, or opportunities with the power to
make organizationally significant decisions. This may be accomplished by moving decision-making authority or
creating an organizational environment that enables the smooth interaction of perception and action“. (Butler
and Gray, 2006, p.216).
These are characteristics, which are also associated with ASD. Lyytinen and Rose (2006), for example provide
their understanding of agility in the context of ISD as, “agility can be defined as ISD organisations’ ability to
sense and respond swiftly to technical changes and new business opportunities” and accordingly an agile ISD
organization is “one that develops and maintains information systems has the capability to sense and respond to
unexpected environmental changes and to hone these skills to quickly deliver information systems.” Erickson et
al. (2005) are even more specific when it comes to what agility means in the context of ISD, namely “At its core,
agility means to strip away as much of the heaviness, commonly associated with traditional software-
development methodologies, […] to promote quick response to changing environments, changes in user
requirements, accelerated project deadlines, and the like.” Thus, the concept of mindfulness might offer a
theoretical foundation for understanding ASD. In the following we therefore first map the characteristics of ASD
and mindfulness and then demonstrate its usefulness with a brief case study.
Agile Systems Development and Mindfulness
ASD is guided by the four pairs of values, which were presented in the introduction of this article. In the agile
manifesto they are elaborated further through 12 guiding principles (see www.agilemanifesto.org). In the
following we will map these values and principles to the constituent components and key aspects of individual
and collective mindfulness.
Individuals and interactions over processes and tools
The agile principles underline that business people, customers, users and developers must work together daily
throughout a development endeavour to achieve the project’s goals. Further more, they underline that projects
should be build around motivated individuals who should be trusted and should be provided with the
environment and the support they need to get their jobs done. In this context self-organizing teams are promoted
as the organizational unit from which the best architectures, requirements, and designs emerge. The principles
also state that the most efficient and effective method of conveying information to and within a development
team is face-to-face conversation. Thus, at regular intervals, the team should reflect on how to become more
effective, then tune and adjust its behaviour accordingly.
From a perspective of mindfulness theory this emphasis on individuals and interactions is mirrored in the
concepts of openness to novelty, alertness to distinction, sensitivity to different contexts and awareness of
multiple perspectives, which underline individuals’ and interactions’ capabilities to create and handle novelty, to
assess similarities, dissimilarities and situational change and which salute contrasts and opposition. Taking
collective mindfulness into account the allocation of problems to those, who are most qualified to solve them, is
obviously supported by such an approach as is the skill to handle predicaments as they happen and the
organizational ambition to understand problems from different points of view. This shows that at least
reluctance to simplify, the commitment to resilience, and the migration of decision to expertise are echoed in
ASD.
Working software over comprehensive documentation
Working software is considered the primary measure of progress in ASD and its highest priority is to satisfy the
customer through early and continuous delivery of valuable software. To achieve this objective the frequent
delivery and evaluation of working software, from a couple of weeks to a couple of months, with a preference to
the shorter timescale, is aspired to while continuous attention is paid to technical excellence and good design of
the working software. Simplicity, the art of maximizing the amount of work not done, is essential in that
context. Indeed, ASD does not neglect sustainable development and aims at enabling sponsors, developers, and
users to maintain a constant development pace indefinitely.
From a perspective of mindfulness theory the constant release of working software implies an ability to deal
with novel kinds of stimuli and with change, to appreciate different viewpoints, to compare and appraise
consistency and modifications, to take different view points into account and to be able to focus on the presence.
Thus, all elements of individual mindfulness are reflected in ASD. But prioritizing working software also means
to be willing to utilize errors and failures as a way of improving the product; exposing the working software to

19th Australasian Conference on Information Systems Mindfulness and Agile Software Development
3-5 Dec 2008, Christchurch Matook & Kautz
642
other developers and to users entails a readiness to perceive problems from different points of view and to cope
with them when they occur. The short development cycles of the software parts suggest letting experts work
with this task and underlines the need for some individuals, who have an overall picture of the development
process and the future product. This confirms the close relationship between collective mindfulness and the
value of appreciating working software over documentation.
Customer collaboration over contract negotiation
As stated above, the ASD values and principles postulate that business people, customers, users and developers
must co-operate on a daily base during a development project. These values and principals also stipulate that the
team, including the customer and user representatives, regularly evaluates its conduct, performance and actions.
This of course means that ASD embraces an openness to novelty, an alertness to distinction, a sensitivity to
context, an awareness of multiple perspectives, and an orientation in the present as well as a reluctance to
simplify, a commitment to resilience and a migration of decision making and problem solving to the respective
experts. As such, all concepts related to individual mindfulness and the majority of the concepts related to
collective mindfulness can be connected to the ASD value of appreciating customer collaboration over contract
negotiation.
Responding to change over following a plan
The ASD values and principles welcome changing requirements, even late in the development process and
harness change for the customer's competitive advantage while, as stated above, keeping the amount of work
performed to implement a change and produce a new release as low as possible. The frequent delivery and
evaluation of working software, sustainable development as well as its good design and technical excellence
certainly facilitate responding to change as does the co-operation of the different stakeholder groups and a
working environment, which cherishes trust, expertise, and direct communication. In such a context, all aspects
of individual mindfulness are taken into consideration as well as all key aspects of collective mindfulness are
dealt with.
In the following we will demonstrate how the theory of mindfulness can be applied in a case study to provide a
better understanding of ASD in practice. Before doing so, we will briefly introduce our case setting and research
method.
CASE SETTING AND RESEARCH METHOD
The research presented in this paper is interpretive and is based on an empirical case study. The case company
is a German water supplier, which we call WaterWorks. It was founded in the 1850ies and has been partially
privatised in 1999. Since 1999 the city council holds 50.1% and 49.9% are in private hand. The firm provides
town water supply as well as sewage and wastewater recycling for 3.5 million people. The company has 4,500
employees and realised a total income in 2006 of 1.26 million Euros.
The project under investigation was concerned with the development of an operations management system
(OMS) for WaterWorks by a small software company, AgDev, which had specialised on ASD. The system was
developed with a web-based graphical user interface and a backend to interface the technical infrastructure as
defined by an underlying ERP system. The project was organized in 4 subprojects to provide IT support ranging
from customer management to the maintenance of the sewer system.
At the time of the data collection, AgDev consisted of 25 employees, 20 of them being developers, and based its
development approach on the agile method XP (Beck and Andres, 2004). The method includes planning
techniques for releases and iterations called planning games, user stories and story cards to specify user
requirements, onsite customers to support customer-developer communication, daily meetings (stand-up
meetings) of the whole project team to support team communication, pair programming, re-factoring, collective
ownership, continuous integration and software testing, and tuning workshops to improve the development
processes regularly.
The project was organised in 2 phases. In a first 12 months exploration phase, prototypes catching requirements
and possible solutions were developed. This led to the development of a comprehensive requirements document
by the customer organisation and their decision to contract AgDev also for the development of the OMS. In this
main development phase, a team of 12 development staff with multiple roles such as project manager, analyst,
customer contact, and developer worked onsite in a building owned by WaterWorks. The project team also
consisted of a varying number of users with at least one representing one of the subprojects. These users were,
however, not the entire time onsite. A sophisticated management structure was established with one subproject
manager also acting as contact person from AgDev and one subproject manager also acting as onsite-customer
from WaterWorks for each individual subproject. The development team consisted of project managers, who

19th Australasian Conference on Information Systems Mindfulness and Agile Software Development
3-5 Dec 2008, Christchurch Matook & Kautz
643
had quite some experience with ASD, and of highly educated and motivated, young staff with little to no
experience with ASD, but none of them had ever participated in such a large project.
When the data collection for this study was performed phase 1 had been successfully completed and phase 2 had
been in progress for 4 months. The project ended 10 months later on time with all parts of the IS being
operational.
The empirical data for the case study was collected in semi-structured, open-ended interviews, which were
conducted by a team of two researchers in a three days period. The research team performed 12 interviews with
11 individuals – the AgDev project manager was interviewed twice, once at the beginning and once at the end of
the investigation. The interviews included about half of the development team and a representative sample of
key players and future users in the customer organisation. Table 3 presents the roles and affiliation of the
interviewees.
The interviews were tape-recorded and subsequently transcribed to be processed in a qualitative data analysis.
We used the qualitative software tool NVIVO 7 for this purpose. The coding and analysis of the data for this
particular study have been guided by the four pairs of values and the twelve principles underlying ASD and the
ten concepts derived from mindfulness theory. This study is part of a larger research project, which aims at
understanding and theorizing about ASD in practice, which so far has been documented in Kautz and Zumpe
(2008) and Zumpe and Kautz (2008).
Table 3. The Interview Partners
Name Role Affiliation
Mr. A Project Manager/analyst/developer AgDev (2 interviews)
Mr. B Project Manager WaterWorks
Mr. C Developer AgDev
Mr. D Developer AgDev
Mr. E Subproject manager/onsite user WaterWorks
Mr. F Subproject contact/analyst/developer AgDev
Mr. G Subproject contact/developer AgDev
Mr. H Chief IT co-ordinator WaterWorks
Ms. K Subproject contact/developer AgDev
Mr. L Subproject manager/onsite user WaterWorks
Mr. M Developer AgDev
MINDFUL BEHAVIOUR IN THE OMS PROJECT
The OMS project was described by both the customer and the supplier as a success. In a presentation to the
board the project champion at WaterWorks said: “I am with the company now for 25 years but I never exper-
ienced a project that could generate output so fast.” One of the WaterWorks subproject managers explicated:
“Our users have been very satisfied” and the project manger confirmed that the agile concept of working
software as the measurement of project progress was much appreciated as “it was amazing to have something to
test so quickly.” The project provided already after the initial exploration phase various benefits to the company,
for example time savings and cost reductions. The emerging information system afforded, in the words of a
WaterWorks subproject manager, “to identify synergies among the various departments” and in particular in the
duct department it enabled improved planning that resulted in the possibility to “dispose cleaning vehicles and
reduce related staff.”
Throughout the project we observed openness to novelty both with regard to ASD and the problem at hand by
both the developers and the customers. This was for example expressed through a strong desire, motivation and
pleasure to learn as described by one AgDev subproject manager: “I enjoyed the learning. It was something new
every day.” and one developer stated: “Sure, I had to catch-up and even now, I still need to learn a lot, but I
meet with interesting people and they help me through.” In addition, the project managers as well the subproject
managers paid attention to the operation and had an overall picture of the project.
In the following we present and discuss more instances of mindful behaviour in the OMS project. This
presentation is again structured according to the four value pairs of ASD.

19th Australasian Conference on Information Systems Mindfulness and Agile Software Development
3-5 Dec 2008, Christchurch Matook & Kautz
644
Individuals and Interaction over Processes and Tools
XP provides a number of processes and tools such as short releases and iterations, planning games, user stories,
story cards, onsite users, pair programming, collective ownership, and stand-up meetings to carry out ASD. In
the OMS project pair programming was a prominent process to support the interaction of the individuals of the
development teams by working in shifting pairs of developers in front of a screen while implementing the
requirements written down as user stories on story cards as executable code. Two sub-processes or mechanisms
here were important: 1) to regularly shift a partner and 2) to regularly shift possession of the keyboard within a
team.
In the project the developers found it difficult to find the appropriate synchronization points at which to change
a partner in the teams of 4 developers. No common practice existed. However they did not follow an overly
bureaucratic rule such as shifting partner every morning regardless of the status of a story card. To avoid both
too much red tape and too much chaos, some developers preferred to stay with a partner until a card was closed.
“… changing a partner was always a problem, it still is as changing in the middle of a card seems foolish to me
and I don’t really like doing it …” said one developer. This of course could lead to limited interaction, spread of
knowledge and dead ends. Thus, although some uncertainty regarding the mandate existed, a subproject leader
might intervene if a pair had worked together for too long, i.e. three days. In doing so, a balance was created
between shifting too often and not shifting at all.
The developers started out with a practice, which did not really support the objectives of interaction, namely that
one developer exclusively held the keyboard and programmed, while the other watched and sometimes
commented. To avoid such situations a process was introduced where using a stopwatch after 20 minutes the
keyboard had to switch. This was however abandoned as too bureaucratic and not fruitful in a creative work
environment. The teams found their own rhythm. “We don’t do that anymore. It didn’t function. Now it also
functions without any explicit rule.” was how one developer commented the emerged practice.
This had also been the case with stand-up meetings. They were performed by all teams together everyday before
lunch with the purpose to keep everyone up to date with the current status of the project and to exchange useful
information. These sessions originally were quite detailed and long, but they had been refined and were then
acknowledged as very helpful. One AgDev subproject manager described: “In the beginning we did this all
together, but we found out that it can become too much, as some are doing something that is not of interest for
other teams. But it is good to know what others do. It does not have to be in detail. And that is what the teams do
now, all teams, but we keep it short.” Other intensive interaction took place in the beginning of each iteration,
where all story cards were jointly discussed.
Despite the fact that these mechanisms could not totally provide the intended collective ownership as the project
leader regretted and explained with the size of the teams, they present mindful behaviour in the form of
alertness to distinction, sensitivity to different contexts, awareness of multiple perspectives, orientation to the
present as well a willingness to learn from errors, an aspiration to perceive problems from different perspectives,
an ability to cope with problems and the migration of decision to expertise. All these contributed to the progress
of the project; they kept the project teams informed and decreased the need for documentation, a topic, which
will be discussed in the next subsection.
Working Software over Comprehensive Documentation
In the OMS project working software was the measure of progress. Software releases were provided every 3-6
months with each release being organised in iterations of 3-6 weeks duration. Beyond this, working software
was also, as mentioned above, presented to the customer in shorter cycles as for example one AgDev subproject
manager described: “We really try to show something every week … there we make a presentation and
demonstrate the software. It is a great way to get fast feedback“.
Each iteration produced operational software, but also minor advancements were demonstrated to the customers.
The WaterWorks project manager stated: “… I have never experienced a project that could generate output so
fast.” and continued “The major benefit is that we do not work so abstract, but rather focus on the real thing.”
One of his subproject managers added to this “ … this way we have seen that we are on the right way, as we can
use 95% of what has been developed this way, and just the last 5% we have to do something with again … ”.
This was confirmed by one developer by saying “Yes, that functioned well, we made all 3 weeks a short
presentation of the running software.” and another one extended this: “…we got very quick feedback when we
showed what we had done.” Thus, the short feedback cycles presented the appropriate mindful behaviour for the
development of the working software. But mindful behaviour was also shown in the way the team handled
documents.
A number of different documents existed as a prerequisite to develop the working software, but they were all
comparably short and concise. From a customer perspective they were related as follows: “We have … the
requirement list. These lists govern what should be the outcome of an iteration. For me this is the basis for my

19th Australasian Conference on Information Systems Mindfulness and Agile Software Development
3-5 Dec 2008, Christchurch Matook & Kautz
645
acceptance test: has been achieved what is on the list? And on the level below there are the story cards, these,
so to speak, represent the detailed specifications and plans for the developers’ process.” The developers shared
this perception and confirmed that the documents, both in length and in number, were adequate. One of them
said: “Absolutely sufficient” and was acceded by a colleague: “I flipped through the realization document in the
beginning and never touched it afterwards … the requirements change anyway every 2nd week.”
These examples again demonstrate how alertness to distinction, sensitivity to different contexts, awareness of
multiple perspectives, orientation to the present, the preoccupation with failure, the reluctance to simplify,
commitment to resilience and the migration of decisions were performed and experienced in the OMS project.
Customer Collaboration over Contract Negotiation
Customer collaboration in the OMS project came in different ways. It took the form of onsite customers and
users, as well as telephone contact and email correspondence, especially to clarify requirements as specified on
story cards. The planning games, the presentations of working software, and the acceptance tests were as well
crucial elements, which structured the collaboration.
The planning games were partly based on the overall realization concept, a document, which had been produced
by the customer as a basis for the contract. Another foundation of the planning game was the requirement list.
These were largely produced by AgDev, both their project leader and some of the subproject leaders, who also
worked as contact persons for their counterparts at WaterWorks and as developers. They developed these
documents with input from the onsite customers. The story cards were solemnly produced by the developers in
team work sessions, where they also estimated them. The developers and the customers then together prioritised
these cards.
This could be considered a limited form of customer collaboration, however, as one subproject leader expressed
it, there could be a number of reasons for this: “Here we have users, who have to take their working gloves off
before they go to the keyboard … in contrast to projects I’ve been involved in before, where the customers were
wearing ties, here the subproject leaders are partly folks, who have done something quite different before, they
have a different education and that becomes apparent with regard to their abstraction capabilities and their
abilities to write down some texts.” Thus, this form of customer collaboration presented a suitable mindful
behaviour to cope with the complexities of a comparatively large ASD project, which was performed by a
number of inexperienced staff, while leaving room for less structured collaboration as well.
Nevertheless, when implementing the story cards, it became obvious that some additional collaboration was
needed. One subproject manager estimated that user contact was necessary for nearly every story card. He put
forward that maybe 60% of a card’s contents was clear. When no user was onsite available the communication
process in the absence of customers and with a lack of information was as follows: “Certain users want to be
contacted by phone to be reached straight away, while others prefer to get their requests via email, but
answered timely.”
The overall collaborative spirit of the project showed that the customer collaboration was not replaced by formal
contracts and negotiations. The project champion, who after having been involved in the original contract
negotiations, supports this view: “… we decided not to be tough on change requests and back-up formalities, but
rather to work constructively with them to make progress. And my good feelings have been confirmed.” The
AgDev project leader confirmed this and described the context of requirement changes: “The customer is quite
relaxed. In such situations they look where they can cut expenses planned for other requirements or we discuss
if we can make the implementation simpler to meet the budget planned.”
The balance between stability and flexibility was brought about by different kinds of mindful customer
collaboration covering all aspects of individual and all aspects of collective mindfulness, may be with the
exception of attention to operation. This also extends to the handling of change requests, which we discuss
below.
Responding to Change over Following a Plan
As described above, in the OMS project change especially change of requirements was an accepted fact of life.
Many change requests were detected through the scheduled acceptance test sessions for an iteration with a
customer representative onsite and were then dealt within the next iteration. The customer representatives also
performed regularly ‘road shows’ in the user departments to collect feedback, ideas, and proposals for
improvements.
But change requests were also brought forward by the users on a shorter time scale. There were weekly and bi-
weekly feedback loops built into an iteration. The AgDev project manager explained: “And then after a week
the customer rep is back and wants to see what happened during the week and he gets the first feedback and this
then continues … .” They had the following consequence: “… often we show the customer rep something once

19th Australasian Conference on Information Systems Mindfulness and Agile Software Development
3-5 Dec 2008, Christchurch Matook & Kautz
646
a week and then he’s going “I thought this would be different” … thus there are always small changes … “ as
one developer put it.
These frequent feedback loops also had the effect that minor misunderstandings were caught and solved as
changes to avoid escalation, as the same developer explained: “Until now it has not happened that everything
was totally wrong; there are of course some refinements or a bug is found or something similar. There is always
something.” The feedback was taken seriously and immediately responded to with action: “Through the
feedback we got, we could react directly … .“
The different feedback mechanisms illustrate mindfulness in the way the changes were handled, but plans and
planning - not impeding more spontaneous actions - were playing an important role as well. Even the weekly
sessions were to some extent planned, as were of course the acceptance tests. As one WaterWorks subproject
leader relating to the size and complexity of the project said “Planning is essential in such kind of projects.”
Therefore, the project also had an overall long term plan covering a 14 months period anticipating 3-6 releases
depending on the subprojects. A more fine-grained plan was developed for the individual iterations, which made
up a release detailed to single weeks. The planning game and the story cards then offered the devices to perform
planning on the most detailed level for very short periods of time. The frequent planning sessions embedded in a
‘larger’ and coarser plan together with the different means to handle change are a clear instance of mindful
behaviour, which helped moving the project forwards.
CONLUSION
We have applied mindfulness theory and a framework consisting of ten key elements of individual and collective
mindfulness to contribute to an enhanced understanding of ASD and especially ASD in practice. Our study
provides a number of illustrative examples, which show how mindful behaviour as part of an ASD approach may
contribute to successful ISD.
However, more research applying the theoretical lens of mindfulness and providing more empirical evidence is
needed to further the understanding of the phenomenon. Iivari and Maansaari (1998) distinguish between
explicit and implicit software development methods use and mindfulness allows us to determine when implicit
use refers to the traditional or the agile approach. Furthermore, Butler and Gray (2006) stress the relationship
between reliability and information systems and also put mindfulness theory forward as a possible explanation of
why developers move from more traditional, ‘disciplined’ and document driven development approaches to ASD.
These are both exciting and significant areas for future research.
REFERENCES
Abrahamsson, P., Warsta, J., Siponen, M. T. and Ronkainen, J. 2003. “New Directions on Agile Methods: A
Comparative Analysis”, IEEE, pp 244-254.
Beck, K., Andreas, C. 2004. Extreme Programming Explained: Embrace Change. 2nd Edition, Addison Wesley
Professional, Boston (MA).
Butler, B.S., and Gray, P.H. 2006. “Reliability, Mindfulness and Information Systems”, MIS Quarterly (30:2),
pp 211-224.
Chanowitz, B., and Langer, E. J. 1980. “Knowing More (or Less) Than You Can Show: Understanding Control
Through the Mindlessness/ Mindfulness Distinction,” Human Helplessness, M. E. Seligman and J. Garber
(eds.), Academic Press, New York, 1980.
Conboy, K., and Fitzgerald, B. 2004. “Toward a Conceptual Framework of Agile Methods”, Extreme
Programming and Agile Methods - XP/ Agile Universe 2004, Springer-Verlag Berlin.
Dybå, T. and Dingsøyr, T. 2008. “Empirical Studies of agile Software Development: A systematic review “,
Information and Software Technology (50:9-10), pp 833-859.
Erickson, J., Lyytinnen, K., and Siau, K. 2005. “Agile Modelling, Agile Software Development, and Extreme
Programming: The State of Art”, Journal of Database Management (16:4), pp 88-100.
Highsmith, J. 2000. Adaptive Software Development: A Collaborative Approach to Managing Complex
Systems. Dorset House Publishing, New York.
Highsmith, J. 2002. Agile software development ecosystems. Addison-Wesley, Boston (MA).
Iivari, J. and Maansaari, J. 1998. “The Usage of Systems Development Methods: Are We Stuck to Old
Practices?”, Information and Software Technology (40:9), pp. 501-510.

19th Australasian Conference on Information Systems Mindfulness and Agile Software Development
3-5 Dec 2008, Christchurch Matook & Kautz
647
Kaban-Zinn, J. 1994. Wherever you go there you are – Mindfulness Meditation in everyday Life. Hyperion,
New York.
Kautz, K. 2004. “The Enactment of Methodology: The case of developing a multimedia Information System”,
Proceedings of the International Conference on Information Systems, December, pp 671-684.
Kautz, K., and Zumpe, S. 2008. Just enough structure at the edge of Chaos: Agile Information Systems
Development in Practice. Proceedings of the 9th International Conference, XP2008 (Abrahamsson et al.,
eds.), Limerick, Ireland, pp. 137-146.
Langer, E.J. 1992. “Matters of mind: Mindfulness/Mindlessness in Perspective”, Consciousness and cognition
(1), pp 289-305.
Langer, E.J. 1997. The Power of Mindful Learning. Perseus Publishing, Cambridge (MA).
Lyytinen, K. and Rose, G. 2006. “Information system development agility as organizational learning”, European
Journal of Information Systems (15:2), pp 183-199.
Sternberg, R. J. 2000. “Images of Mindfulness”, Journal of Social Issues (56:1), pp 11-26.
Vidgen, R. and Wang, X. 2006. Organizing for Agility: a complex adaptive systems perspective on agile
software development process. Proceedings of the Fourteenth European Conference on Information Systems
(Ljunberg J., Andersson, M. eds.), 1316-1327, Gothenburg, Sweden.
Wang, X. and Vidgen, R. 2007. Order and Chaos in Software Development: A comparison of two software
development teams in a major IT company. Proceedings of the 14th European Conference on Information
Systems (Winter, R. et al. eds.), 807-818, St. Gallen, Switzerland.
Weick, K., and Sutcliffe, K. H. 2001. Managing the Unexpected: Assuring High Performance in an Age of
Complexity, Jossey-Bass, San Francisco.
Zumpe, S. and Kautz, K. 2008. In Search of Information Systems Development Theory: A Framework to
Understand Agile Software Development in Practice. Proceedings of the 31st Information Systems Research
Seminar in Scandinavia, Åre, Sweden.
COPYRIGHT
Sabine Matook and Karlheinz Kautz © 2008. The authors assign to ACIS and educational and non-profit
institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided
that the article is used in full and this copyright statement is reproduced. The authors also grant a non-exclusive
licence to ACIS to publish this document in full in the Conference Papers and Proceedings. Those documents
may be published on the World Wide Web, CD-ROM, in printed form, and on mirror sites on the World Wide
Web. Any other usage is prohibited without the express permission of the authors.