dark agile

based on the assumption that the requirements are there (in the minds of the customers), we just have to work hard enough to get

The Agile Guru understood that the management of requirements was a major plus for their approach.
So they reached the point of clarity that Agile manages to keep the cost of requirements flat in contrast to traditional methods where the cost of change increases

The statement of Beck is not false:
giving up upfront planning and defining requirements only when there is a strong need for such definition lowers the cost of their modification.

always of the calibre of Kent Beck to claim that it is always
possible to keep the cost of changing requirements constant.
To keep a long story short, not all the consultants pro-
moting Agile had the skills of Kent Beck in organizing the
process and the code and not all the projects managed by
such consultants were amenable to the application of Agile.

Agile is not anymore considered the solution for
everything, the computer science departments of book
stores are not anymore paved with books about agile. The
attention went to other buzzwords such as Lean and Kanban.

compared himself to Jack Kennedy: “Consultant, we know Kent Beck, we worked with him, and you are not Kent Beck.”
But still many, too many companies believed in them and their failure was reflected on a fall of the trust in Agility.

bility. We think that this is what stops software engineers
and software companies to take full advantage of agility: to
clearly understand when they happen to be useful and when
not.

premise in mind: it is not possible to plan every detail in
advance. This goes against conventional wisdom, which
teaches us to “first think, then do.”

Companies operating in the construction business provide the most disastrous examples of cost and time overruns whenever something new – with only few opportunities to reuse past experiences – had to be built.
There are endless examples like the following:

Our experience leads us to think that something similar happens also to software: if we had to rebuild something that had already been built, we would have only a limited time and cost overrun.
Look at the software houses doing

In software there is also an extra complexity that makes it more unlikely that a new project is similar to a previous one: the technology evolves very rapidly and so the desires and expectations of the customers.
The bias and incomplete compar

there is an
intrinsic additional complexity in developing software
linked to the high speed of change of the underlying soft-

“management take over all work for which they are better fitted than the workmen [43].”
This statement builds on the assumption that workers deliberately work slowly to keep the productivity low so that all workers are needed.

Frederick Herzberg began to investigate how to improve
productivity by increasing the motivation of workers and
by involving them more in the decision making processes
through what was called Job Enrichment [44]. We can draw
a parallel: in software production the waterfall process
resembles scientific management and the propositions of
Agile are analogous to those of Herzberg.

All four methods, Scientific Management, Job Enrichment, Waterfall, and Agile Methods have their right to
exist, if used within the right context.

The problem arises when one method is used in a context where it does not belong to.
«That’s what the Cynefin Framework is for!»
Altogether, Agile went down

customers are not familiar with software engineering at all,

they imagine it as something they know and behave accord-

ingly. Some imagine it as building a house,

Such customers react very annoyed when con-

stantly asked for feedback or requirements throughout the
project since they planned to invest time in the project only

at the beginning.

Another thinking model is to see software development

as to cook – you just need to assemble different compo-

nents in the right combination.

When developers are con-

fronted with problems they have never seen before and
need time to develop a solution this is seen as the fault of
the developer that does not know all the available compo-

nents. A similar way is to see software developers like
configuring a video recorder: there are a predefined number
of switches and buttons and the skills of the developer
decide whether he or she is able to setup the system in the
right way or not.

The described difficulties do not only apply to non-
technical people. It is also hard for professional developers
who have been trained and whose experience is mostly in
formal, waterfall-like methods and approaches (e.g., struc-

In summary, different types of stakeholders have expec-
tations that for them are obvious and therefore are not
communicated. Nevertheless it is necessary to deal with
them:

managers might come to the conclusion that what

Agile Methods are proposing does not lead to the aimed
objectives, i.e., that Agile Methods are not aligned to the
business goals. Customers might come to the conclusion
that such a company is incompetent because its developers
constantly ask for feedback.

1. Where we are: an assessment of the current situation
   
2. Where we want to go: a description of the goals
   
3. How to get there: a plan to achieve the goal
   

To claim “to follow an Agile Software Development
Method” is not enough. As we have explained that the
different stakeholders have an entirely different understand-
ing of how development is carried out, it is necessary to
explain what this means, which practices will be used, why
these will be used, and what kind of outcome is expected.
Unfortunately, this is not always possible, and defending
agile approaches is sometimes difficult since they acquired
a reputation in the management community as a sloppy,
undisciplined method to hack, not develop software. The
next section gives some reasons why this happened.

they have not yet reached the
Slope of Enlightenment, meaning the precise boundary of
their applicability are not yet fully understood.
This all boils down to the fact that Agile

Unfortunately, often the proponent of Agile Methods in-
stead of providing a rational explanation of their applica-
tion cites the gurus, the holy texts, and, worse, does not
really understand whether the Agile Method first should
have been applied in such context, and just feels like being
a prophet.

drome emerged. They wanted to be better, to support Agile
Methods with all their strength, and the means became an
end. They interpreted the Agile Manifesto as in figure 7.
The dark side of agile caused a set of misconceptio

Dark Agile Manifesto: teams need to understand how much to
value the items on the left – how much working software,
how much customer collaboration, how much responding
to change – or the items on the right – how much planning,
how much contract negotiation, etc.

We are uncovering better the only ways of developing software by doing it and helping teaching others do it.
Through this work we have come to value:

• Individuals and interactions over and not processes and tools
  
• Working software over and not comprehensive documentation
  
• Customer collaboration over and not contract negotiation
  
• Responding to change over and not following a plan
  

That is, while since there is no value in the items on the right, we value only the items onf the left more

• Individuals and interactions over processes and tools:
  “Talking to people instead of using a process gives us the freedom to do whatever we want.”
  
• Working software over comprehensive documentation:
  “We want to spend all our time coding. Remember, real programmers don’t write documentation.”
  
• Customer collaboration over contract negotiation:
  “Haggling over the details is merely a distraction from the real work of coding. We’ll work out the details once we deliver something.”
  
• Responding to change over following a plan.
  “Following a plan implies we have to think about the problem and how we might actually solve it. Why would we want to do that when we could be coding?”
  

Such translations show that to some, Agile Methods appear
as approach that advocates coding without discipline, plan-
ning, and documenting: “this is nothing more than an at-
tempt to legitimize hacker behaviour [8].”

The agile community developed another term to de-
scribe such behaviour and to dissociate itself from it: the
cowboy coder. The cowboy method ignores defined pro-
cesses to be faster.

The guru is the person with wisdom – he or she knows
what, when, and how things should be done to achieve the
desired goal. It is the interest of the guru to hide the as-
sumptions on which the rules are based, on which previous
works he or she based his or her findings, how he or she
verified that what is claimed really works. For example, it

The guru has no advantage in making his or her follow-
ers independent adults, otherwise his or her role as a guru
would vanish. In this way, the adopters remain dependent
on the guru: the adopters need the guru to continue to use
the method in cases not described by the guru up front, e.g.,

This is not always the case. The guru
does know when it is the case and has several consulting
opportunities. So he or she picks smartly only those where
such approach is suitable and winning.

the market is dominated by
a few “enlightened” gurus that keep the knowledge secret
among themselves, followed by many quacksalvers.

“agile method practices sometimes lack clarity and the underpinning rationale is often unclear [12]”.
Some authors define Agile Methods, Extreme Programming in particular, as irrational and vague [13, 14].

Other authors claim that the agile method practices are on a
too high level of abstraction which causes an inconsistent
interpretation and implementation [15, 16, 17].
Not having a clearly stated rationale behind method and
practices makes it also difficult to tailor a method to specif-
ic needs [18, 19, 20, 21, 22, 23]. Without this knowledge
we don’t know what we are risking if we omit one method
or if we extend another.

Stephens and Rosenberg compare Extreme Program-
ming with a ring of poisonous snakes (sometimes depicted
as in figure 8), daisy-chained together. Each snake repre-
sents a practice that has issues that are compensated by the
use of another practice. „All it takes is for one of the snakes
to wriggle loose, and you’ve got a very angry, poisonous
serpent heading your way. What happens next depends on
the snake and to an extent on how good you are at damage
control [14].”

1. Requirements are elicited gradually, which – since developers do not have a complete picture – can result in wasted effort.
   This problem is alleviated by incremental design, i.e. to be ready to change the design incrementally.
   
2. Incremental design avoids designing everything up-front to minimize the risk of being wrong.
   This practice is considered safe because the code is constantly refactored.
   
3. Constant refactoring involves rewriting existing code that was thought to be finished: it went through discussions and thinking to get the design right.
   It potentially introduces new bugs, but it’s considered safe because of the presence of unit tests.
   
4. Unit tests act as a safety net for incremental design and constant refactoring. With unit tests it is difficult to verify the quality of the design of an architecture.
   Pair programming alleviates this problem.
   
5. And so on
   

To summarize, different underlying assumptions of com-
puter scientists, economists, project managers, engineers,
etc. can lead to different interpretations of what is happen-
ing during the project. Agile zealots create excessive ex-
pectations that move Agile Methods up the Hype Cycle but
at the end of the day cannot be met. In part this is possible
because Agile Methods are promoted by gurus, not inter-
ested in explaining what is behind their practices.
To overcome these problems we propose to co

To overcome these problems we propose to collect and
disseminate know-how about Agile Methods in the form of:
“To achieve objective o we use tactics y that has the cost c,
its performance can be understood observing m and we use
this tactic until m reaches the target value v.”

In the same way we recommend to collect software pro-
cess tactics, i.e., decisions whether to shape the process in a
certain way or not to achieve a given quality (e.g., code
quality, time-to-market, low turnover, etc.) about Agile
Methods.

Practitioners who want to productively use Agile Meth-
ods need to collect such set of tactics to adopt in different
circumstances [25, 32, 33, 34]. It is also necessary to know
the advantages (the achieved objective o) and the draw-
backs (the costs c) of using a specific tactic y. Since soft-
ware is invisible, and projects can progress towards the
wrong direction for a long time until this is noticeable, it is
necessary to define a way to understand whether the tactic
y is profitable or not (the measure m).
To make an example, the practice o

Tactics that help to achieve a common goal could be
then grouped into strategies. Agile software development
strategies could describe a set of tactics that help to achieve
a common goal (e.g., fast time-to-market).