ArticlePDF Available

On Understanding Software Agility – A Social Complexity Point Of View

Authors:

Abstract

Over the last decade, the field of so-called Agile software development has grown to be a major force in the socio-economic arena of delivering quality software on time, on budget, and on spec. The acceleration in changing needs brought on by the rise in popularity of the Internet has helped push Agile practices far beyond their original boundaries, and possibly into domains where their application is not the optimal solution to the problems at hand. The question of where Agile software development practices and techniques make sense, and where are they out of place, is a valid one. It can be addressed by looking at software development as a complex endeavour, and using tools and techniques from the Cynefin method and other models of social complexity.
26 E:CO Vol. 13 Nos. 1-2 2011 pp. 26-37
Over the last decade, the eld of so-called Agile software development has
grown to be a major force in the socio-economic arena of delivering qual-
ity software on time, on budget, and on spec. The acceleration in changing
needs brought on by the rise in popularity of the Internet has helped push
Agile practices far beyond their original boundaries, and possibly into do-
mains where their application is not the optimal solution to the problems
at hand. The question of where Agile software development practices and
techniques make sense, and where are they out of place, is a valid one. It
can be addressed by looking at software development as a complex en-
deavour, and using tools and techniques from the Cynen method and
other models of social complexity.
Introduction
Over the course of the last decade, a soft revolution has taken place in the
eld of software development. Experiences with projects delivering late
and over budget have led people to question some of the basic tenets of
software project development and management. Starting with a few provoca-
tive theses in Kent Beck’s 1999 book eXtreme Programming, the eld of so-called
Agile software development has grown to be a major force in the socio-eco-
nomic arena of delivering quality software to people on time, on budget, and on
spec. The acceleration in changing needs brought on by the rise in popularity of
the Internet has helped push Agile practices far beyond their original boundar-
ies, and possibly into domains where their application is not the optimal solu-
tion to the problems at hand.
So, where do Agile software development practices and techniques make sense,
and where are they out of place? To answer that question, it is necessary to rst
understand how, and more importantly why, Agile practices work. In the mid
1990s, it was maintained that practices such as eXtreme Programming could not
possibly work, although even then dozens of projects successfully completed
had proved otherwise. Later, after sucient empirical evidence had accumu-
lated to irrefutably prove that Agile practices do work, the question of why they
worked still remained.
On Understanding Software Agility—A Social Complexity Point Of View
E:CO Issue Vol. 13 Nos. 1-2 2011 pp. 26-37
On Understanding Software Agility—
A Social Complexity Point Of View
Joseph Pelrine
MetaProg GmbH, CHE
Applied
27
Pelrine
As a consequence of the increasing complexity and unpredictability of the world
around us, Agile practice is increasingly seen as the solution. Agile represents a
new paradigm in the truest sense, a complete abandonment of old methods
that cannot be done in half measures. At its core, Agile addresses complexity
in a manageable fashion, attuned to the needs of the human psyche. The Ag-
ile approach, though, constitutes a revolution in our modes of thinking, work-
ing and interacting. Agile processes have grown and developed as the body of
knowledge acquires new ideas from its practitioners. Expansion is not always a
positive force, however. The discipline that originally allowed Agile to explode
linear, mechanistic development practices has often vanished, replaced by a car-
go-cult “by-the-rules” interpretation of Agile based on checklists. It seems today
that some Agile’ teams are practicing nothing more than ‘air guitar and attitude’
(to quote Alan Kay).
Ultimately, models are only as good as the people applying them. Too many
teams have come to regard Agile as something like a cookery recipe—follow
this set of instructions and procedures for a tasty result. But in software develop-
ment, as in cooking, what you get out is not simply the sum of what you put in.
We need to develop an understanding of what makes Agile work, and indeed
what makes it fail. This understanding is a prerequisite for sustaining and scaling
Agile eorts. Acknowledging that Agile is not working in a particular situation is
an inherent part of Agile practice, but it’s one that’s often ignored.
The purpose of this paper is to explore the following questions:
• Is software development (in whole or in part) a socially complex endeavour?
• What can be gained by treating it as complex, and using tools and tech-
niques from social complexity science?
• Why do Agile practices work so well?
Why is Agile the best method around for meeting challenges in software devel-
opment? As projects become more complex, and customer requirements ever
more ambitious but ever less clearly dened, how does Agile help developers
produce usable software on time and on budget? Despite the recent quantum
shift in the eld towards the adoption of Agile, many organizations have not yet
made the conceptual adjustments necessary to apply it successfully. No method
is without its detractors, and those who have yet to be convinced by Agile can
point to the lack of hard evidence, of rigorous analysis, of a theoretical, scientic
basis, in the literature. For Agile fans, rigorous does not mean rigid, and it is not
‘anti-Agile’ to question the assumptions on which we base our processes, quite
the opposite is true!
The core realization inherent in Agile is that people build software, that team dy-
namics are fundamental to it, and that teams of people are complex and unpre-
dictable. The need to factor psychological and cognitive concepts into project
design and implementation is novel in a world where mechanization and unifor-
28 E:CO Vol. 13 Nos. 1-2 2011 pp. 26-37
mity are frequently encountered, and often admired, within corporate cultures.
A more realistic model of corporate information sharing began with Knowledge
Management and its applications, but Agile goes much farther.
Modern software development is performed by teams of motivated individu-
als. The prevailing attitude for much of the eld’s history, though, has been to
treat software development as a predictable ‘factory’ process, where adding a
given amount of money, time, programmers and managers will produce the de-
sired result. Within this context, the development process is broken down into
a sequential pathway, with deliverable outcomes predicted at set points. This
‘traditional’ approach is exemplied by the Waterfall model. It can work—if the
requirements are known, in detail, right from the start, the product is straight-
forward, and nothing goes horribly wrong. But who has ever worked on a proj-
ect like that? Successful Waterfall projects do exist, but they are few and far be-
tween, and on closer analysis may not be adopting ‘pure’ linear management
models—some exibility, the beginnings of Agility, has crept in!
Trying to establish computing as an engineering discipline led people to be-
lieve that managing projects in computing is also an engineering discipline. En-
gineering is for the most part based on Newtonian mechanics and physics, es-
pecially in terms of causality. Events can be predicted, responses can be known
in advance and planning and optimize for certain attributes is possible from the
outset. Eectively, this reductionist approach assumes that the whole is the sum
of the parts, and that parts can be replaced wherever and whenever necessary
to address problems. This machine paradigm necessitates planning everything
in advance because the machine does not think. This approach is fundamentally
incapable of dealing with the complexity and change that actually happens in
projects.
Traditional Agile
Sequential Iterative
Dened Empirical
Plan-driven Result-driven
Big-bang Incremental
Specialised teams Cross-functional teams
Test at end Test-rst
Figure 1 Traditional vs. Agile.
Consider what happens if you manage a project like a production line. Develop-
ers are assigned tasks, code is pumped through, and the nished product rolls
o at the end. There are two problems with this paradigm. Firstly, the production
line approach is more suited to generating multiple repetitive units, something
that is rarely entailed in software development. Secondly, as soon as the product
stops working at the end, the entire production line must be analyzed and xed
to solve the fault. Usability is a good example—often, aspects of product usabil-
29
Pelrine
ity are left until the end stages of a project, with the expectation that it can be
ne-tuned as needed. Frequently, there are aws deep within the software that
are not trivial to x. The whole process must be reworked, but the team has al-
ready given it massive investment in terms of resources, time and eort. For the
author, adopting Agile becomes the task of increasing awareness of, and nding
the best process for answering the question, ‘when do you want to know you
have a problem?’ (That assumes, naturally, that you do want to know you have a
problem, an equally important point!)
One of the most highly developed skills in contemporary Western civilization
is dissection: the split-up of problems into their smallest possible components.
We are good at it. So good, we often forget to put the pieces together again
(Toer, 1984)
The reductionist approach described by Toer has served us well in the past,
but we need to move beyond it. Many people still regard building software as a
complicated undertaking, but in fact it is a dening example of a complex or a
‘wicked’ problem. The concept of wicked problems was originally proposed by
Horst Rittel and Marcus Webber (Rittel & Webber, 1973). Wicked problems have
incomplete, contradictory, and changing requirements; and solutions to them
are often dicult to recognize as such, because of complex interdependencies.
Rittel and Webber stated that while attempting to solve a wicked problem, the
solution of one of its aspects may reveal or create other, even more complex
problems. Rittel expounded on the nature of ill-dened design and planning
problems, which he termed ‘wicked’ (that is, messy, circular, aggressive) to con-
trast against the relatively ‘tame’ problems of mathematics, chess, or puzzle solv-
ing. In the author’s experience, certain ground rules of Agile software develop-
ment have emerged that address the limitations of the Waterfall and other linear
development paradigms in tackling such problems.
Communication and team dynamics represent the other area where Agile dif-
fers fundamentally older development paradigms. The functioning of the team,
and the contributions and roles of individuals within the team, are fundamental
to productivity. Team roles are no longer xed, but members are allowed to self-
organise. Management takes on the role of facilitating and coaching the team,
rather than issuing orders. Scrum (Schwaber & Beedle, 2001) sees self-organiz-
ing teams as a fundamental aspect of the process. In applying Scrum, there is
an emphasis on skills, not knowledge, and there are few rules. The author has
distilled three ‘rules of thumb/rules of Scrum’ from experience in practice: the
rst is ‘we don’t make mistakes, we learn,’ i.e., set up a safe-fail work environment
where it is OK to learn and to correct behavior, estimates etc., on the basis of that
learning. Secondly ‘whoever has the risk, makes the decision.’ Increase aware-
ness of roles, rights, and responsibilities of the various partners in the develop-
ment process. And last ‘if you’re not having fun, we’re doing something wrong.
Keeping people happy and motivated isn’t easy over a long project, but there
are techniques that can be used from the outset to promote good team practice.
30 E:CO Vol. 13 Nos. 1-2 2011 pp. 26-37
Getting Comfortable With Complexity—
Sense Making The Agile Way
What is a complex system? Complexity theory can be considered one
of the most revolutionary products of 20th century thought. Theories
of chaos, complexity and emergence have shattered the conceptual
frameworks of science, technology and economics, and provide unifying themes
across previously distant disciplines. Scientists, sociologists, economists and en-
gineers are nding common ground that transcends the terms of reference of
each particular eld. We have gone from the assumption that everything can be
modelled given enough time, intelligence or processing power, to the realiza-
tion that not everything we experience can be drilled into predictable patterns
that we can recognise and understand. The human mind does not readily grasp
complexity. It is counterintuitive; we prefer to recognise patterns in mechanistic
systems.
How can a complex system be dened? Ask ten or twenty people working on
complexity and emergence to describe such a system and you will get as many
answers. One of the best sets of criteria for complexity is provided by professor
George Rzevski:
1. INTERACTION—A complex system consists of a large number of diverse
components (Agents) engaged in rich interaction;
2. AUTONOMY—Agents are largely autonomous but subject to certain laws,
rules or norms; there is no central control but agent behavior is not random;
3. EMERGENCE—Global behavior of a complex system “emerges” from the in-
teraction of agents and is therefore unpredictable;
4. FAR FROM EQUILIBRIUM—Complex systems are “far from equilibrium” be-
cause frequent occurrences of disruptive events do not allow the system to
return to the equilibrium;
5. NONLINEARITY—Nonlinearity occasionally causes an insignicant input to
be amplied into an extreme event (buttery eect);
6. SELF-ORGANIZATION—Complex systems are capable of self-organization in
response to disruptive events, and;
7. CO-EVOLUTION—Complex systems irreversibly coevolve with their environ-
ments.
Is software development a complex domain, and if so, why? This is the key ques-
tion. At one level, the software development process seems to full all of Rzevs-
ki’s criteria, but on another level there seem to be exceptions and questions.
This question may not be able to be answered denitely, but as we will see, in-
teresting things happen when we TREAT software development as complex. We
might also question which other domains may benet from this treatment.
31
Pelrine
Many customers and developers alike regard building software as a complicated
undertaking, but in fact it is a prime example of a complex problem. In adopt-
ing Agile processes, the eld is beginning to address this and to become more
comfortable with complexity. Unfortunately, the typical Agilist perception of
complexity is not quite aligned with any of the main scientic denitions of the
term. Agile literature abounds with romanticized, subjective interpretations of
terms such as complexity, self-organization, emergence, which can only be un-
derstood by remembering that ‘a little knowledge is often a dangerous thing’.
If we even succeed in establishing that developing software is a complex en-
deavour, a wicked problem, how then do we address it eectively? Complexity
is counterintuitive to many. This is one of the reasons that a mechanistic, Newto-
nian view of projects has persisted in management thought.
Even as it was toppled from its unassailable position in science, Newtonian
mechanics remained rmly lodged as the mental model of management,
from the rst stirrings of the industrial revolution right through the advent of
modern-day MBA studies (Petzinger, 1999).
Complexity theory represents software development more realistically than the
engineering model. Understanding the theory is only the rst step. How can
complex problems be tackled practically on a daily basis? How can one dier-
entiate easily between the complex and, e.g., complicated aspects of a complex
domain? The art of management and leadership is having an array of approach-
es and being aware of when to use which approach.
Thinking About Complex Problems
The challenges of a Wicked problem are manifold. At the outset, goals may
be unclear, yet expectations are high. We are tempted to set out a grand
plan, mapping the project from start to nish, with meticulous alloca-
tion of time and resources. Yet the chances of such a plan being followed are
remote—even if the initial stages appear to be going well, reality will rapidly
cause divergence from the pathway. New information, changing variables and
requirements, external factors such as competitor activity, cannot be factored in
to a plan made months before. However, how many times do managers insist
on struggling forward with a battered, modied version of the original plan?
This tendency to cling to our initial assumptions and plotted course is down
to the way our minds deal with new situations. The process of rst-t pattern
matching evolved to make us capable of fast decisions in danger, based on pre-
vious experience. Once that ‘t’ has been made it’s hard for us to let go and con-
sider alternatives within a complex problem. It also makes humans bad at cut-
ting their losses and changing tack mid-project. Research shows we value things
we already have more highly than things of equal or greater value that we don’t
possess, for example. We’re also good at seeing patterns where none exist, and
32 E:CO Vol. 13 Nos. 1-2 2011 pp. 26-37
imputing causality in random chains of events. A classic example is cumulative
winnings or losses from betting on heads or tails in a coin toss. These purely
random outputs can be modelled by a rst-order Markov chain, which as is well
known, readily exhibits pseudo cycles and pseudo trends, with stationary mean
and non-stationary variance.
The problem of how to gure out a solution to a complex problem goes fur-
ther. It is another part of complexity science known as multi-ontological sense
making. The sense making process says that there is not one t solution. Sense
making is looking at things pre-hypothetically, that is crossing the line between
unknown and known. As G. Spencer Brown said in his book The Laws of Form
(Spencer-Brown, 1979), the rst thing to do is to draw a distinction, which is ex-
actly drawing a line between unknown and known. What we can know is cause
and eect, which is the basic observation we make, i.e. phenomenology. We see
something happen along the temporal axis and we often input causality: the
rst caused the second. Because our level of resolution of perception allows us
to perceive them as to separate events, we interpret a causal connection be-
tween them. I push that light switch and a light goes on, I do it again and again
and the light always changes. So I assume that there has to be some repeatable
cause of connection. In this way we can predict the future.
Dave Snowden says, “sense making is the way that humans choose between
multiple possible explanations of sensory and other input as they seek to con-
form the phenomenological with the real in order to act in such a way as to
determine or respond to the world around them.
A basic premise of sense making is that we need to understand our thought
processes when we analyze things. Our opinion, our evaluation of something
says as much about us as it does about the thing we are looking at. This is called
cognitive bias, and it inuences our interpretation of everything around us, for
example, what we consider to be complex.
Agile As A Technique For Addressing Complexity
The basic science necessary to understand complex systems was just start-
ing to be established when the rst Agile literature was published. At that
time, the works of Stacey, Nonaka, and others suced to provide ideas and
impulses for some Agile pioneers, but lacked the full breadth and rigour neces-
sary for providing a foundation for understanding the Agile process as a whole.
Only with the publication of Dave Snowdens papers on the Cynen model did a
system emerge that nally allowed researchers and practitioners to understand
social complexity science, and its position as the theoretical basis of software
Agility.
This paper will discuss one of many aspects of social complexity science, the
Cynen approach, and one of its practical applications to Agile software devel-
opment. Many aspects of software development fall into the complex domain.
33
Pelrine
Figure 2 The Cynen Framework: Common Summary
The Cynen sense-making model has been described in a number of papers
(Kurtz & Snowden, 2001; Snowden, 2005), and will not be covered in detail here.
In addition to the sense-making model, though, the Cynen method contains
a number of techniques and exercises, which can be used to help groups make
sense of their domain, helping them understand which methods and techniques
can then be best applied.
In a study conducted over a number of years, the author has run the Cynen
‘buttery stamping’ exercise (see Cognitive Edge methods in the references)
with over 300 people involved in Agile software development, with the goal
of sensitizing them to scientic denitions of complexity and related concepts,
of interpreting their cognitive biases related to software development, and of
understanding whether software development as a whole could be considered
a complex domain. During an introductory session, the participants are asked to
brainstorm and collect topics they deal with and activities they engage in as part
of their work. Later, after explaining the Cynen model, denitions of the dier-
ent domains, and the sense-making process, they do the exercise by assigning
to the dierent Cynen domains a set of situations, themes, and subjects pro-
vided by Dave Snowden, and which the participants were agnostic about. After
“warming up” with these situations, themes, and subjects, and getting an active
awareness for the meaning of the dierent domains, the participants then make
sense of the activities and topics they identied and collected themselves.
34 E:CO Vol. 13 Nos. 1-2 2011 pp. 26-37
Simple
18%
Complicated
25%
Complex
38%
Chaotic
16%
Unknown
3%
Figure 3 Breakdown Of Typical Activities In Software Development
Table 1 oers a sample of typical activities provided by participants, together
with their sense-making results:
Simple Complicated Complex Chaotic Unordered
Knowing when
a task is done
Ambitious
(political) time-
line
Changing
requirements
Arguing
about coding
standards
No release
deadline
Monitoring
actual time
spent
Fixing the build Countering a
belief in magic
Retrospectives
without
consequence
Resource
shortage
Featuritis Finding who to
talk to Task Estimation Project volume
too big Lack of trust
Table 1 Some Typical Software Development Activities
Interpreting the results of the exercises led to the following realizations:
• Software development is a rich domain, with aspects and activities in all the
dierent domains. The interactions between these aspects and activities are
themselves often of a complex nature.
• Software development is a multi-level domain with self-similar characteris-
tics, i.e., activities often tend to consist of sub-activities, each of which may
be located in a dierent domain to the basic activity.
• The activities tend to be weighted more to the complicated and complex do-
mains, with activities related to the coding aspect of software development
landing in the complicated (or sometimes simple) domain, and activities as-
sociated with project management landing in the complex (sometimes cha-
otic) domain. Tasks dealing with interaction with a computer tended to be
in the ordered domains, tasks dealing with interaction with other humans
tended to be in the un-ordered, i.e., complex and chaotic, domains.
35
Pelrine
• The highest percentage of tasks and activities were in the complex do-
main. Although this is not sucient to argue that software development as
a whole is complex, it does suggest that many parts of it are amenable to
analysis and treatment using complexity-based tools and techniques.
Success In Software Development Is Only Retrospectively Coherent
One thing that makes complex systems complex is their causality. As Dave
Snowden says. ‘If the system is chaotic/random then agent behavior is
deterministic, which means I can use statistical instruments. If it’s con-
strained, then the constraint structure allows predictability/repeatability. Strong
constraints produce linear causality; weaker constraints provide repeatability
that may be non-linear. However the moment you get the phase shift into a
coevolutionary relationship between agents and system then there is no repeat-
ability except by accident. In that context there is no meaningful causality, and
any causality is only retrospectively coherent.
In an ordered system, if you do something, you expect a specic result. Do it
again, expect the same result. It’s that simple. In a complex system, causality
emerges as the system itself emerges, so that at the end, you can say how you
got to where you are, but you can’t guarantee that by doing exactly the same
things, you’ll get to the same place again—and you probably won’t. In com-
plex systems, we say the causality is retrospectively coherent. A classic example
of retrospective coherence is task estimation. Before you do a task, it’s almost
impossible to estimate how long it will take. Afterwards, though, you can say
exactly how long it took, and why it took that long. The same goes for projects.
As a project goes on, the reasons for its success become established, not before.
After it’s over, you can say that the project was a success, and that certain things
took place during the project—but you cannot say that the project was a suc-
cess because these certain things took place!
Now shift the focus to a project. We tend to make the mistakes above when it
comes to project planning. What worked last time? Why? Well, it must have been
the people, the methodology, the meeting schedule—let’s do it the exact same
way again. Is it any surprise, then, that a project planned on this basis is likely to
be a op?
Contrary to Einstein’s denition, in a socially complex system, insanity is doing
the same thing over and over again and expecting the same result!
Complex Activities Require A Probe-Sense-Respond Model Of Action
Now that we have a reasonable basis for asserting that software develop-
ment (as a whole) is a complex endeavour, or rather treating is as such,
let’s turn back to the Cynen model. Since causality in the complex do-
main is retrospectively coherent, we’ll always only know afterwards whether our
eorts were crowned with success. To maximise exibility in the face of this un-
36 E:CO Vol. 13 Nos. 1-2 2011 pp. 26-37
certainty, the Cynen method suggests a probe-sense-respond technique. Set
boundaries for the system to emerge. Employ numerous probes, which will pro-
vide feedback on what works and what doesn’t. Apply sense-making to the re-
sults to the feedback. Then respond by continuing or intensifying the things that
work, correcting or changing those that don’t. Tighten this into a small iterative
loop, observing emergent patterns, amplifying good ones, and disrupting bad
ones, until you end up successful at your endeavour. In fact, it’s often the case
that by applying this process, you discover value at points along the way. Your
nal product can end up looking very dierent to the original plan, and being
very much better. You could not have dened these benets at the outset and
aimed for them; these are an example of emergent properties of the complex
system.
The ‘apply-inspect-adapt’ model of agile development is a probe-sense-re-
spond model. The Scrum project management framework utilises an iterative,
incremental model of development, with work divided into iterations (called
‘Sprints’), and a review and reection step at the end of each iteration. This tech-
nique, called ‘inspect and adapt, should properly be called apply-inspect-adapt,
otherwise the focus is not on actually doing anything. If we think about this, it
becomes clear that the apply-inspect-adapt loop is nothing else then the probe-
sense-response cycle used in the Cynen method for dealing with issues in com-
plex domains.
This insight brings us full circle. We used a social complexity method to gain
understanding of the cognitive bias of Agilists towards the eld of software de-
velopment, and ended by noticing that the Scrum framework implements the
exact method called for by the Cynen method for managing work in the com-
plex domain. This leads us to the following conclusions:
• The theoretical underpinnings of Agile methods need to be understood for
such methods to become truly scalable and sustainable. Insights, and an-
swers to many of the questions, can be found in social complexity methods
such as Cynen.
• Agile methods such as Scrum provide a lightweight, proven framework
for managing work in the complex domain, be it software development or
something else.
Software development is a rich domain, containing many aspects, a large per-
centage of which can be classied as complex. The interaction between these
aspects is also complex. Just as we have beneted from treating software devel-
opment as complex, and taking advantage of the toolbox of social complexity,
namely the Cynen method, so the eld (as well as many other elds of human
endeavour) would benet from a multi-ontological approach, taking the best
techniques for the various domains, and combining them in an appropriate and
exible manner. More work is needed to reach a deeper understanding of the
37
Pelrine
inter-workings of agility and complexity, and it is the author’s hope that the rst
(and following) workshops on complexity and real-world applications will not
only provide insights, but also motivate other researchers to look into these fas-
cinating elds.
Acknowledgements
Kent Beck, for being a strong source of motivation and inspiration; Dave
Snowden and George Rzevski, for their input and insights into social complex-
ity; Mark McKergow, for his excellent review and comments; Evelyn Harvey, for
research and editorial assistance
References
Beck, K. (1999). Extreme Programming Explained: Embrace Change, ISBN
9780201616415.
Cognitive Edge methods: Buttery Stamping, http://www.cognitive-edge.com/meth-
od.php?mid=45.
Kurtz, C. and Snowden, D. (2003). The new dynamics of strategy: Sense-making in a
complex and complicated world,IBM Systems Journal, ISSN 0018-8670, 42(3): 462-
483, http://www.research.ibm.com/journal/sj/423/kurtz.html.
Petzinger, T. (1999). The New Pioneers: Men and Women Who are Transforming the Work-
place, ISBN 9780684846361.
Rittel, H. and Webber, M. (1973). “Dilemmas in a general theory of planning,” Policy Sci-
ences, ISSN 0032-2687, 4: 155-169.
Schwaber, K. and Beedle, M. (2001). Agile Software Development with Scrum, ISBN
9780130676344.
Snowden, D. (2005). “Multi-ontological sense-making: A new simplicity in decision
making,http://www.cognitive-edge.com/ceresources/articles/40_Multi-ontology_
sense_makingv2_May05.pdf.
Snowden, D. and Boone, M. (2007). “A leader’s framework for decision making,Harvard
Business Review, ISSN 0017-8012, 85(11): 69-76.
Spencer-Brown, G. (1979). The Laws of Form, ISBN 9780525475446.
Joseph Pelrine is C*O of MetaProg, a company devoted to increasing the quality
of software and its development process, and is one of Europes leading experts on
Agile software development. After studying philosophy, psychology, and music in
Vienna, his interests led him to work in the eld of articial intelligence and soft-
ware development. He worked as an assistant to Kent Beck in developing eXtreme
Programming, and is Europe’s rst certied ScrumMaster Practitioner and Trainer.
Joseph Pelrine is an accredited practitioner for the Cognitive Edge Network, and his
work focus is on the eld of social complexity science and its application to Agile
processes.
... Although concepts like iterative development had existed before (Boehm, 1988), it was the release of the "Manifesto for Agile Software Development" in 2001 (Manifesto for Agile Software Development, 2001) that brought about a radical shift in our understanding of project management, injecting a breath of fresh air into the discipline. However, several challenges still need to be addressed (Moreira, 2013;Pelrine, 2011): ...
... However, there are a lot of agile practitioners who do not fully understand this necessity of adapting to change. Pelrine exposes them by saying "Acknowledging that Agile is not working in a particular situation is an inherent part of Agile practice, but it's one that's often ignored" (Pelrine, 2011). ...
... We believe our proposal allows independence and freedom in decision-making, based on the specific context to be faced, with the ultimate goal of achieving optimal and superior results in projects. In short, we choose the most suitable tools for each case, instead of following a "cookbook" (Pelrine, 2011). ...
Article
Managing software development projects is a complex endeavor due to the constant emergence of unforeseen events that deviate from initial expectations. A competent project leader is not just someone who follows the planned course but also adept at handling and minimizing inconveniences, ultimately striving to achieve results that align as closely as possible with the desired outcome. However, individuals involved in technological development often cling to familiar tools that have previously yielded positive outcomes, even when those tools may not be the best fit for the current project context. The Agile Manifesto has significantly transformed project management, infusing the discipline with a fresh perspective. Nevertheless, there remain several challenges to overcome. In this article, we aim to provide a guide that addresses these difficulties and minimizes their impact. We explore the selection of key factors that adequately describe a project's complexity, which can subsequently be used in conjunction with the Cynefin framework to categorize management strategies, techniques, and tools based on their applicability to specific complexities. Additionally, we offer insights on adapting project management approaches throughout the project life cycle in response to changes in reality, utilizing the dynamics outlined by the Cynefin framework. Finally, we present suitable strategies, techniques, and tools for agile project management based on the complexity context assigned by the Cynefin framework.
... Uncertain or unsought results can be produced because of this complexity (Pelrine, 2011). ...
Thesis
Thesis: Agile Project Management: Evaluating the impact on project success. Enhanced Project Outcomes: Agile Project Management (APM) boosts productivity, success rates, stakeholder satisfaction, product quality, and cost management. Key Success Factors: Success is driven by quality delivery, compliance, punctuality, and cost-effectiveness. Optimal for Dynamic Environments: Agile methods excel in projects with high uncertainty and evolving requirements. Challenges for Stable Projects: APM may not suit projects with stable, well-defined needs and extensive documentation requirements. Flexibility and Improvement: APM promotes flexibility, continuous improvement, and stakeholder engagement. Careful Assessment Required: Project managers should evaluate project characteristics and team capabilities for effective agile implementation.
... Other advantages of implementing agile development include higher levels of flexibility, reduced expenses for development, more frequent delivery of functional software, and more reusable code. Agile development might be considered a method to deal with the complexity of the various parts of software development, which exists in a relatively complicated area (Pelrine 2011). ...
Article
Full-text available
Agile software development has gained more popularity due to its capacity to manage constantly changing needs and generate high-quality software in less time. However, several success factors are required for an agile project to succeed. Agile development technique, delivery strategy, project team training, customer and staff involvement, management commitment, organizational culture, communication, and project management process are critical success factors (CSF) discovered in this study. This study's goal is to locate and evaluate these crucial elements of the agile software development methodology's success. A systematic literature review was conducted to study and analyze the previous studies to identify the CSFs in agile development. The findings of the literature review indicate that technical, people, organizational, and process factors are crucial for the success of agile projects. Each CSF falls into any one of these factors. Overall, this study's findings emphasize the significance of CSFs in the agile software development process. Organizations and software development teams can enhance their agile processes and raise the likelihood of project success by being aware of these aspects. Teams may create high-quality software in less time while simultaneously fulfilling the goals and expectations of the customer by concentrating on different success factors.
... Given the interdependencies, entanglement, and dynamic nature of complexity it is not possible to make sense of the situation without first probing to acquire an observable response. These probes should be multiple, parallel, diverse, and fail safe (Lepmets et al., 2014;Pelrine, 2011;Van Beurden et al., 2013;van Kemenade, 2021). Establishing scaffolding for learners to probe into wicked problems will help them reveal emergent patterns, to gain a sense of what is likely to work, then respond by amplifying and resourcing. ...
Thesis
Full-text available
Learning Design continues to emerge as a distinct area of professional practice in both corporate and education contexts. This practice must now adapt to meet the challenges of increased expectation of learner experience, an exponential rate of global change, and the need for learning experiences to be future-fit. However, there is a lack of a coherent framework to guide Learning Design practice in addressing these challenges. There is a lack of a framework that supports the learning designer as a leader of change for a thriving future. This thesis proposes an emergent framework: Leadership by Learning Design. The researcher adopts a pragmatic approach, which draws upon both existing research and professional experience across a range of design related themes including anthro-complexity, future studies, decolonisation, transformational learning, and systems transformation. Key literature in each of these areas is explored, contextualised to Learning Design, then applied in a manner that pushed beyond the boundaries of prevalent practice. Together these themes form an emergent, yet coherent, framework which allows Learning Designers to explore their role as leaders for a thriving future - Leadership by Learning Design.
... Complexity theory has been used as a frame of reference, by analysing its implications on software design and development (e.g. Pelrine [143], Rikkilä et al. [149]). Software projects can be characterized as endeavours wherein a dynamic network of customers, software designers, developers, 3rd party partners, and external stakeholders interact and can be seen as a Complex Adaptive System (CAS). ...
Preprint
Full-text available
Software startup companies develop innovative, software-intensive products within limited time frames and with few resources, searching for sustainable and scalable business models. Software startups are quite distinct from traditional mature software companies, but also from micro-, small-, and medium-sized enterprises, introducing new challenges relevant for software engineering research. This paper's research agenda focuses on software engineering in startups, identifying, in particular, 70+ research questions in the areas of supporting startup engineering activities, startup evolution models and patterns, ecosystems and innovation hubs, human aspects in software startups, applying startup concepts in non-startup environments, and methodologies and theories for startup research. We connect and motivate this research agenda with past studies in software startup research, while pointing out possible future directions. While all authors of this research agenda have their main background in Software Engineering or Computer Science, their interest in software startups broadens the perspective to the challenges, but also to the opportunities that emerge from multi-disciplinary research. Our audience is therefore primarily software engineering researchers, even though we aim at stimulating collaborations and research that crosses disciplinary boundaries. We believe that with this research agenda we cover a wide spectrum of the software startup industry current needs.
... Paulus et al. [7] also classify sequential development, based on a plan, as an appropriate approach for a clear context. Pelrine [8] understands that a project is not complex or complicated in itself, but rather its constituent parts that can be classified independently in the four Cynefin's contexts. ...
... Many organizations today lean on traditional, hierarchical, managerialist orientation that is powerful in the production of physical products (Sohlberg, Czaplicka & Lindblad, 2008;Bandura, 2002), but ill-suited to a knowledgeoriented economy (Uhl-Bien, Russ & McKelvey, 2007;Cohen & Prusak, 2001), because it has become evident for many organizations that it is not possible to formalize every aspect of work into standard, predictable, mechanistic patterns that are easy to understand or recognize (Pelrine, 2011 Barney & Wright, 1998.) Management's most important contribution in the 21 st century is no longer the increase in productivity of the manual worker, but the increase in productivity of the knowledge worker. ...
Article
Full-text available
In 2007, two friends decided to establish a new IT company, but not just another software company – a phrase that later became one of their slogans. The Finnish IT company called Vincit has turned out to be a success story both financially and in terms of personnel and customer satisfaction. The company is known for its skillful use of media as a deliverer of their company story. This paper examines organizational storytelling through media. The empirical data was gathered between 2012 and 2019, and it is analyzed using narrative analysis focusing on the types of stories told and how they are narrated.
... The Cynefin framework is frequently referenced in literature on decision-making in project management in complicated and complex contexts (e.g. Appelo, 201;Pelrine, 2011;Shalbafan et al., 2018;Wingo & Tanik, 2015). It drew some criticism from Firestone & McElroy (2011), as in their opinion the contexts are too limited, and the model lacks rigorous foundation. ...
Thesis
Full-text available
This research examines middle-managers’ construing of exploratory and exploitative innovation projects in two large US high-tech companies. The theoretical basis for this research is that of organizational ambidexterity and agency theory. Answering a call from multiple researchers, this research focuses on ambidexterity at the individual level. The research follows a phenomenological paradigm with its focus on individual experiences as evidence, and constructivism as epistemological stance. It is based on a case study design, with data collection completed in two stages, using Repertory Grid Technique in stage 1 and Key Informant Interviews in stage 2. Emergent findings indicate that a) prior experience type (exploitative/exploratory) and function (Engineering / Product management) are the key leading indicators of differences in the construing of project success; b) there is mostly alignment in how managers from different levels construe what is important for exploratory and exploitative innovation projects; c) there is a difference in the extent to which managers apply approaches to these two types of project; and d) managers rarely apply exploratory-innovation specific approaches even when merited. The emergent root cause for lack of exploratory innovation specific approaches appears to be a result of inertia, and of the expectations of the extant corporate culture. A model is developed to indicate how a change can be introduced in an organization to address this finding. This research contributes to study of ambidexterity, managerial sensemaking, and project management by offering an insight into how managers from the Product Management and Engineering functions think about project success. It offers possible explanations for the lack of distinction between exploration and exploitation when it comes to selection of approaches and metrics; it presents implications to practice and makes recommendations for improving chances of success of exploratory innovation projects.
Article
Full-text available
Software security is a complex topic, and for development projects it can be challenging to assess what security is necessary and cost-effective. Agile Software Development (ASD) values self-management. Thus, teams and their Product Owners are expected to also manage software security prioritisation. In this paper we build on the notion that security experts who want to influence the priority given to security in ASD need to do this through interactions and support for teams rather than prescribing certain activities or priorities. But to do this effectively, there is a need to understand what hinders and supports teams in prioritising security. Based on a longitudinal case study, this article offers insight into the strategy used by one security professional in an SME to influence the priority of security in software development projects in the company. The main result is a model of influences on security prioritisation that can assist in understanding what supports or hinders the prioritisation of security in ASD, thus providing recommendations for security professionals. Two alternative strategies are outlined for software security in ASD – prescribed and emerging – where we hypothesise that an emerging approach can be more relevant for SMEs doing ASD, and that this can impact how such companies should consider software security maturity.
Article
Full-text available
In this paper, we challenge the universality of three basic assumptions prevalent in organizational decision support and strategy: assumptions of order, of rational choice, and of intent. We describe the Cynefin framework, a sense-making device we have developed to help people make sense of the complexities made visible by the relaxation of these assumptions. The Cynefin framework is derived from several years of action research into the use of narrative and complexity theory in organizational knowledge exchange, decision-making, strategy, and policy-making. The framework is explained, its conceptual underpinnings are outlined, and its use in group sense-making and discourse is described. Finally, the consequences of relaxing the three basic assumptions, using the Cynefin framework as a mechanism, are considered.
Article
Full-text available
Imagine organising a birthday party for a group of young children. Would you agree a set of learning objectives with their parents in advance of the party? Would those objectives be aligned with the mission statement for education in the society to which you belong? Would you create a project plan for the party with clear milestones associated with empirical measures of achievement? Would you start the party with a motivational video so that the children did not waste time in play not aligned with the learning objectives? Would you use PowerPoint to demonstrate to the children that their pocket money is linked to achievement of the empirical measures at each milestone? Would you conduct an after-action review at the end of the party, update your best practice database and revise standard operating procedures for party management? No! Instead, like most parents, you would create barriers to prevent certain types of behaviour, you would use attractors (party games, a football, a videotape) to encourage the formation of beneficial largely self-organising identities; you would disrupt negative patterns early, to prevent the party becoming chaotic, or necessitating the draconian imposition of authority. At the end of the party you would know whether it had been a success, but you could not have defined (in other than the most general terms) what that success would look like in advance.
Article
Full-text available
Many executives are surprised when previously successful leadership approaches fail in new situations, but different contexts call for different kinds of responses. Before addressing a situation, leaders need to recognize which context governs it -and tailor their actions accordingly. Snowden and Boone have formed a new perspective on leadership and decision making that's based on complexity science. The result is the Cynefin framework, which helps executives sort issues into five contexts: Simple contexts are characterized by stability and cause-and-effect relationships that are clear to everyone. Often, the right answer is self-evident. In this realm of "known knowns," leaders must first assess the facts of a situation -that is, "sense" it -then categorize and respond to it. Complicated contexts may contain multiple right answers, and though there is a clear relationship between cause and effect, not everyone can see it. This is the realm of "known unknowns." Here, leaders must sense, analyze, and respond. In a complex context, right answers can't be ferreted out at all; rather, instructive patterns emerge if the leader conducts experiments that can safely fail. This is the realm of "unknown unknowns," where much of contemporary business operates. Leaders in this context need to probe first, then sense, and then respond. In a chaotic context, searching for right answers is pointless. The relationships between cause and effect are impossible to determine because they shift constantly and no manageable patterns exist. This is the realm of unknowables (the events of September 11, 2001, fall into this category). In this domain, a leader must first act to establish order, sense where stability is present, and then work to transform the situation from chaos to complexity. The fifth context, disorder, applies when it is unclear which of the other four contexts is predominant. The way out is to break the situation into its constituent parts and assign each to one of the other four realms. Leaders can then make decisions and intervene in contextually appropriate ways.
Article
The search for scientific bases for confronting problems of social policy is bound to fail, becuase of the nature of these problems. They are wicked problems, whereas science has developed to deal with tame problems. Policy problems cannot be definitively described. Moreover, in a pluralistic society there is nothing like the undisputable public good; there is no objective definition of equity; policies that respond to social problems cannot be meaningfully correct or false; and it makes no sense to talk about optimal solutions to social problems unless severe qualifications are imposed first. Even worse, there are no solutions in the sense of definitive and objective answers.
The New Pioneers: Men and Women Who are Transforming the Workplace
  • T Petzinger
Petzinger, T. (1999). The New Pioneers: Men and Women Who are Transforming the Workplace, ISBN 9780684846361.