Conference PaperPDF Available

Mindfulness and agile Software Development

Authors:

Abstract and Figures

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.
Content may be subject to copyright.
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.
... Mindfulness in Agile ISD mindfulness is an appropriate theoretical lens to examine ASD (Matook and Kautz 2008;Vidgen and Wang 2009;McAvoy et al. 2013) given that mindfulness is a process to promote attention to detail, willingness to consider alternatives, responsiveness to change, openness to novelty, and orientation in the present which all exhibit similarities to the principle, values and goals of agile ISD (as per agile manifesto 1 ) (Matook and Kautz 2008). In a case study research to formulate the enablers and inhibitors of agility and emergent capabilities of agile teams, Vidgen and Wang (2009) argue that in order to optimise self-organising teams (one of the principles of agile ISD), a truly agile team must embrace mindfulness and cautiously avoid "mechanical use of cognitive and emotionally rigid, rulebased behaviours" (which is the definition of mindlessness as articulated by Butler and Gray (2006, p. 215). ...
... Mindfulness in Agile ISD mindfulness is an appropriate theoretical lens to examine ASD (Matook and Kautz 2008;Vidgen and Wang 2009;McAvoy et al. 2013) given that mindfulness is a process to promote attention to detail, willingness to consider alternatives, responsiveness to change, openness to novelty, and orientation in the present which all exhibit similarities to the principle, values and goals of agile ISD (as per agile manifesto 1 ) (Matook and Kautz 2008). In a case study research to formulate the enablers and inhibitors of agility and emergent capabilities of agile teams, Vidgen and Wang (2009) argue that in order to optimise self-organising teams (one of the principles of agile ISD), a truly agile team must embrace mindfulness and cautiously avoid "mechanical use of cognitive and emotionally rigid, rulebased behaviours" (which is the definition of mindlessness as articulated by Butler and Gray (2006, p. 215). ...
... While IS literature acknowledge the lack of mindfulness (or in other words, existence of mindlessness) in implementation of agile approaches, and that "[exercising] mindful behaviour as part of an ASD approach may contribute to successful ISD" (Matook and Kautz 2008, p. 646) at both individual and collective levels (Vidgen and Wang 2009), empirical examination of the relationship between mindfulness and the success and wellbeing of agile team members at individual level remains underdone and is limited to few case studies (Matook and Kautz 2008;Vidgen and Wang 2009;McAvoy et al. 2013). In the present research, therefore, we seek to expand the existing knowledge by investigating if practicing mindfulness by agile team members leads to better outcome for them in terms of several factors (which overall, we label them as agile wellbeing in this research). ...
Conference Paper
Today, agile approach is arguably the most-widely-used project management method in software development industry. The dynamic nature of agile methods however is putting an overwhelming pressure on agile team members which in turn might negatively influence their overall agile wellbeing. Drawing on IT mindfulness as a theoretical foundation, this research-in-progress develops a conceptual model to examine the potential impact of agile mindfulness, in conjunction with agile identity, on the agile wellbeing of individuals in information system development projects. The findings of this research, upon completion, will contribute to IS literature by providing an evidence-based theoretical understanding of the relationship between agile mindfulness, agile identity, and agile wellbeing. The findings could also help agile teams to understand what improves agile wellbeing of team members, and in turn help them maintain, promote, and enhance it.
... The relevance of social aspects in software development and in particular agile software development has been investigated in the past (e.g., [6,11]). For instance, we know, that the quality of collaboration and communication with stakeholders, like users and customers is important concerning to the output of the development teams [12]. ...
Preprint
In 2020, the world changed due to the Covid 19 pandemic. Containment measures to reduce the spread of the virus were planned and implemented by many countries and companies. Worldwide, companies sent their employees to work from home. This change has led to significant challenges in teams that were co-located before the pandemic. Agile software development teams were affected by this switch, as agile methods focus on communication and collaboration. Research results have already been published on the challenges of switching to remote work and the effects on agile software development teams. This article presents a systematic literature review. We identified 12 relevant papers for our studies and analyzed them on detail. The results provide an overview how agile software development teams reacted to the switch to remote work, e.g., which agile practices they adapted. We also gained insights on the changes of the performance of agile software development teams and social effects on agile software development teams during the pandemic.
... Ideally these firms would have a highly skilled workforce with digitisation knowledge, increased organisational learning, agile, digitally innovative and empowered with more decision rights (Caroli & Van Reenen 2001). Kautz, Johansen & Uldahl, (2014) demonstrated that positive impact of agile management where individual and collective mindfulness are key characteristics of agile practice (Matook & Kautz 2008) is critical in dynamic environments. ...
Thesis
Full-text available
The impact of Digital disruption on the Australian energy industry is the focus of this research. It investigates disruptive changes to the industry. Digital technologies that occur at a pace and magnitude that disrupts established ways of value creation, social interactions, business and the ways in which people within the digital space and culture, socially react and innovate for them is researched. This thesis explores how decision-makers manage disruptive change with effective strategies that exploit progressive innovation. Building on existing literature on digital disruptions, the Disruptive Change Capability (DCC) Framework is analysed. This framework provides an understanding of managing digitally disruptive change in enterprise organisations and how to benefit from future digital disruptions. The motivation for this research is to investigate how digitally mature organisations can transform themselves, rapidly respond to opportunities and manage challenges, embracing disruptive change to create value and stay relevant in the disruptive business environment. The primary research question is ‘How do enterprise decision makers understand the various aspects of digital disruption and manage disruptive change in the Australian energy industry?’ An interpretative perspective was used to research the topic and an explorative case study methodology was thus utilised. This study collects decision-makers’ reactions, perceptions and feedback about the specific components of digital transformation. It presents a new set of organisational capabilities and learning, digital dynamic capabilities, digital business strategies, concepts, values and practices critical to the success and sustainability of the rapidly and technologically disruptive business environment in which the future enterprise will have to operate. This research delivered five key findings; Digital Mindset, External Collaboration, Customer Focus, Constraints and Future Drivers. The relationships between the five concepts linked by their related themes constitute the major findings of the thesis and were found to have a grounding with digitalisation literature. This research has identified the digital decision-makers’ recommendations to manage digital disruptions; an organisational mindset of shared vision, an agile, digital transformation organisational culture; a customer-focused dynamic capabilities and collaboration in building trust. Furthermore, it is essential for decision makers to encourage progressive innovation; embrace co-creation to maintain mutually beneficial relationships; retaining collective digital talents; remaining responsive, adaptive and innovative as a key strategic priority; building networks with industry ecosystems, society, businesses and policy makers to indirectly influencing regulatory policies and investing in progressive technological innovation as future drivers that enable aspects of digitisation. Key words: Digital disruption, digital transformation, customer-focused, disruptive change capabilities, network ecosystems collaboration, energy policies, progressive innovation, innovative disruptive technologies, digitalisation
... In the agile software process community, not only the practice of mindfulness has been recommended in order to create a good atmosphere in work groups, meetings, and interactions with customers and users [44], [45], but also an empirical study on the effects of mindfulness in agile developers has been recently carried out reporting positive effects [46] (see Section 7 for details). ...
Article
Context. Mindfulness is a meditation technique whose main goal is keeping the mind calm and educating attention by focusing only on one thing at a time, usually breathing. The reported benefits of its continued practice can be of interest for Software Engineering students and practitioners, especially in tasks like conceptual modeling, in which concentration and clearness of mind are crucial. Goal. In order to evaluate whether Software Engineering students enhance their conceptual modeling performance after several weeks of mindfulness practice, a series of three controlled experiments were carried out at the University of Seville during three consecutive academic years (2013—2016) involving 130 students. Method. In all the experiments, the subjects were divided into two groups. While the experimental group practiced mindfulness, the control group was trained in public speaking as a placebo treatment. All the subjects developed two conceptual models based on a transcript of an interview, one before and another one after the treatment. The results were compared in terms of conceptual modeling quality (measured as effectiveness, i.e. the percentage of model elements correctly identified) and productivity (measured as efficiency, i.e. the number of model elements correctly identified per unit of time). Results. The statistically significant results of the series of experiments revealed that the subjects who practiced mindfulness developed slightly better conceptual models (their quality was 8.16% higher) and they did it faster (they were 46.67% more productive) than the control group, even if they did not have a previous interest in meditation. Conclusions. The practice of mindfulness improves the performance of Software Engineering students in conceptual modeling, especially their productivity. Nevertheless, more experimentation is needed in order to confirm the outcomes in other Software Engineering tasks and populations.
... Other researches have attempted to measure programmers' performance under the influence of mindfulness. [35] shows how mindfulness improves the overall quality of the software development process, thus enhancing the productivity of each team. These types of research, naturally, do not give a correct estimate on how mindfulness can boost coding abilities and therefore is outside of the scope of this study. ...
Preprint
Full-text available
Mindfulness cause a lot of positive effects on human brain as well as hinders the performance of other functions. This paper proposes a way for measure difficulty of performed activity using electroencephalogram. Proposed metric is used to analyze whether mindfulness techniques, especially meditation, cause a positive effect on software development performance. 8 experienced programmers were participating in the experiment. Analysis shows no positive effect on their programming performance (t=3.05, p=0.05). Paper claims that meditation does not cause positive effect on programmers and address possible negative effect of meditation on performance as well.
... Agile methods are developed as a reaction to the traditional project management which is plan-driven. In case of software development, when following traditional project management due to the plans to be followed slows down the software development, Therefore agile methods have become prominent as a group of software development methodologies which are adaptive rather than predictive and are people-oriented rather than process-oriented [4]. ...
Article
Full-text available
At present, Agile Project Management has done an evolutionary change in software industry. Agile Project Management is defined as a conceptual framework which responds quickly to changes, collaborates with the client frequently and covers minimum amount of document needs. Agile methods facilitate the software development by performing incrementally and iteratively and thereby minimizing the risk. This literature review paper covers the aspects of agile project management in the software industry.
... Despite this landmark definition of mindfulness, similar conceptual definitions soon followed his work. These definitions include keeping one's consciousness alive to the present reality (Hanh, 1976); the knack of noticing without comment whatever is happening in one's present experience (Claxton, 1990); bringing one's complete attention to the present experience on a moment-to-moment basis (Marlatt & Kristeller, 1999); the non-judgmental observation of the ongoing stream of internal and external stimuli as they arise (Baer, 2003); an open and receptive attention to and awareness of what is occurring in the present moment (Brown & Ryan, 2004); an awareness of present experience with acceptance (Germer, Siegel, & Fulton, 2005); an attention that is receptive to the whole field of awareness and remains in an open state so that it can be directed to currently experienced sensations, thoughts, emotions, and memories (Jha, Krompinger, & Baime, 2007); a frame of mind in which one maintains a continuous attention to detail (Matook & Kautz, 2008); and an awareness that arises from intentionally attending in an open, accepting, and discerning way to whatever is arising in the present moment (Shapiro & Carlson, 2009). Bishop et al. (2004) further suggest that the concept of mindfulness can be broken down into two components. ...
Article
This article provides a foundation for future marketing research on sustainable consumption through the application of three prominent theoretical perspectives of consumer behavior: responsible consumption, anti-consumption, and mindful consumption. This article considers how each perspective can help researchers better understand how consumers can engage in sustainable consumption practices, and develops insights that emerge from the simultaneous examination of multiple theoretical perspectives.
Article
Mindfulness is receiving growing attention in the project management community, probably due its proven beneficial effects at individual, team and organization levels in other management domains. Indeed, 80% of the 50 publications identified in this paper were published over the last decade. This review addresses the disparate extant publications related to mindfulness in the field of project management to date and seeks to establish how mindfulness is studied in the management of projects. We first recall the two historical schools of thought, their respective perspective on mindfulness and highlight a recent, reconciling conceptualization of the mindfulness construct termed meta-cognitive practice. Next, we review existing project management works that have included mindfulness theory and categorize them into six main research themes. Project management scholars have studied mindfulness as an enabler of (1) high reliability project organizing, (2) change and innovation, (3) agility and flexibility, (4) mindfulness-based behaviours to be compared with routine-based ones, (5) project actors and project team self-regulation, and (6) megaprojects performance. Third, we provide an overall framework of how mindfulness may benefit the project management field, together with an overall discussion of issues to be addressed. Last, we provide research avenues to foster future research in each of the identified themes. In sum, as the first review on the application of mindfulness in project management research, we contribute to the understanding of how mindfulness can contribute to overall project performance.
Article
The small and tiny manufacturing sector in India have missed out on the many technological advancements in the automation solutions being offered in the manufacturing sector due to various impeding factors. The impeding factors include the high initial investment requirement and the high cost of implementation thus rendering the solutions unaffordable. The small and tiny manufacturing sector with its lower potential to tap into the scale economies find themselves constrained to reap the benefits of automation. The lack of technical ongoing support and training contributed by their exorbitance and inaccessibility adds to this impedance and deters the long-term sustenance of the solution. This article attempts to elucidate a remedy that partly resolves these impeding factors by assimilating the merits of an implementation model. The model was tested out in a few projects, one of which is elaborated here. The research methodology adopted is a mix of participatory action research and agile model of implementation. The authors were actively involved as drivers of this automation solution. The article validates and offers a remedy for scenarios where the mentioned factors are relevant. Conclusively, it underlines adherence to an implementation model for the project’s successful implementation and for the sustenance of such implementations.
Chapter
This research contributes to the body of knowledge in information systems development (ISD) with an empirical investigation in the form of a case study that demonstrates the positive impact of the agile development and project management method Scrum on team leadership in information systems and software development projects. It also provides a useful operationalization of the concept through six identified indicators for team leadership. Despite the fact that the case unit had challenges with the use of Scrum, the indicators identified the areas where the company had managed to exploit the potential of Scrum and its practices with regard to increasing team leadership. The research results are discussed with regard to the existing Scrum literature and briefly related to complex adaptive systems (CAS) as a foundation for ISD and agile development.
Article
Full-text available
Mindfulness, achieved without meditation, is discussed with particular reference to learning. Being mindful is the simple act of drawing novel distinctions. It leads us to greater sensitivity to context and perspective, and ultimately to greater control over our lives. When we engage in mindful learning, we avoid forming mind-sets that unnecessarily limit us. Many of our beliefs about learning are mind-sets that have been mindlessly accepted to be true. Consideration is given to some of the consequences that result from a mindful reconsideration of those myths of learning.
Conference Paper
Full-text available
Since the software crisis of the 1960’s, numerous methodologies have been developed to impose a disciplined process upon software development. It is now widely accepted that these methodologies are unsuccessful and unpopular due to their increasingly bureaucratic nature. Many researchers and practitioners are calling for these heavyweight methodologies to be replaced by agile methods. The Agile Manifesto was put forward in 2001, and several method instantiations, such as XP, SCRUM and Crystal exist. Each adheres to some principles of the Agile Manifesto and disregards others. This paper conducts a review of the literature on agility across many disciplines, in order to reach an all-encompassing notion of what agility is. This paper aims to develop a comprehensive framework of software development agility, through a thorough review of agility across many disciplines. We then elaborate and evaluate the framework in a software development context, through a review of software related research over the last 30 years.
Conference Paper
Full-text available
Agile information systems development is not well understood and suffers from a lack of sustainable theories, which are based on empirical research of practice. We use a framework that focuses on the ‘edge of chaos’ as the area, where agile information systems development takes place to fill in this gap. Our study identifies for a concrete project under investigation, where the beneficial balance between stability and instability lies. It discusses the circumstances, which influence this balance and the relationships of the elements, which constitute it.
Article
Full-text available
Agile software development represents a major departure from traditional, plan-based approaches to software engineering. A systematic review of empirical studies of agile software development up to and including 2005 was conducted. The search strategy identified 1996 studies, of which 36 were identified as empirical studies. The studies were grouped into four themes: introduction and adoption, human and social factors, perceptions on agile methods, and comparative studies. The review investigates what is currently known about the benefits and limitations of, and the strength of evidence for, agile methods. Implications for research and practice are presented. The main implication for research is a need for more and better empirical studies of agile software development within a common research agenda. For the industrial readership, the review provides a map of findings, according to topic, that can be compared for relevance to their own settings and situations.
Article
This article addresses the question: How should mindfulness be understood? Three views are considered. The first is that mindfulness should be understood as a cognitive ability. According to this view, people differ in their capacity to think in a mindful way, much as people differ in memory or intelligence. The second view is of mindfulness as a personality trait. According to this view, mindfulness is a stable disposition, much as would be extraversion or neuroticism. The third view is of mindfulness as a cognitive style. According to this view, mindfulness represents a preferred way of thinking. Mindfulness has characteristics of all three but seems closest to being a cognitive style. Construct validation is needed in order to address this and related questions.
Article
There is surprisingly little research on the actual use of systems development methods. The general ®nding of earlier studies is, however, that the use of methods is weak and, as far as they are used, the use is not literal. The use of methods has also been found to be quite conservative, old methods from the 1970s still dominating. The present paper makes two contributions to this ongoing discussion on the use of systems development methods. Firstly, it raises a number of conceptual problems related to their use. These conceptual problems help to devise theoretically more justi®ed research on method use. Secondly, the paper provides evidence that the repertoire of systems development methods may be undergoing a considerable change. Results of a recent survey of method use among CASE user organisations in Finland indicate that object-oriented methods have become the dominant systems development approach in this population. Even though the sample may be biased towards more innovative organisations, the results also show that organisations are not necessarily stuck to old practices of systems development, and gives hope that object-oriented methods will gradually achieve wider acceptance. At the same time they indicate considerable differences in the effective use of object-oriented methods. Overall, the paper underlines the need future research on the usage of systems development methods.