Translated from German to English - www.onlinedoctranslator.

com

technical article

Bertil Muth Uwe Valentini

( Bertil.Muth@hood-group.com ) ( Uwe.Valentini@hood-group.com )
is Senior Consultant at HOOD GmbH. His focus is on agile coaching is a consultant, trainer and coach at HOOD GmbH. Against the
and consulting. background of his many years of experience in software development
and requirements engineering, he has specialized in agile
approaches. He coaches development teams, scrum masters, product
owners and organizations on their way to agility.

Agile Manifesto for Managers

At its core, agile development is not a method, a technique, or a framework. She's a mindset! This mindset is manifested in
the Agile Manifesto. The article examines the importance of the Manifesto for and the implications for management.
Furthermore, we want to show that the values and principles of the Agile Manifesto are much more than just common sense
for software developers.

The importance of the Agile Manifesto for The four pairs of values dividuals and interactions: "If we define
development teams is now sufficiently Value #1: “Individuals and interactions the right process and all employees
clear, because the effects on teams are overprocesses and tools” follow it exactly, then we will be
being better understood and the new way For most organizations, processes and successful". This approach would work if
of thinking behind it is being implemented tools are still more important than internal everyone were identical
very successfully in many development
projects worldwide. However, an agile
transition is not just another process
change that affects IT at best and that can
possibly also be delegated. The true
potential of the agile approach only really
unfolds when the agile way of thinking
encompasses the entire organization,
especially management.

What does it consist of

"agile mindset"?
This question was answered in 2001 by 17
software development luminaries in the
Agile Manifesto [Agile]. The signatories
note in the introductory sentences that
they do not have an answer for everything
("uncovering"), but that continuous
improvement based on the values and
principles of the agile manifesto leads to
success ("by doing it").
The core of the agile manifesto are four
pairs of values and twelve principles. This
article is about them. Fig. 1:Value #1.

1 www.object-spectrum.de
 technical article
Fig. 2:Value #3.
is. Thinks identically and acts identically.
But software development requires
communication and creativity from
individuals. It is performed by
knowledge workers who need to look at
complex problems from different angles.
Since teams are made up of
individuals, they are also different. Not
all teams can be treated equally.
Although all teams must share the
philosophy of agile development, even
the basic methods (Scrum, Kanban, etc.)
can be different.
This pair of values therefore calls on
management to focus on people and not
processes.
Value #2: “Working softwareover
comprehensive documentation”
The second pair of values is the most commonly
misunderstood. It does not mean that
documentation in an agile environment and
2 www.object-spectrum.de
important is. The documentation should
just be less important than the result, the
software.
Without any specification of how it
should behave, software probably
cannot be developed to meet
stakeholder expectations. The facts in
software development are sometimes
too complicated to only be
communicated and remembered
verbally. But what good is an extensive
specification if the software doesn't
work? What good is a specification
created early in the project if it's out of
date when development begins?
The agile mindset calls for a lightweight,
just-in-time specification, such as user
stories with acceptance criteria. The
balance between the value created (the
software) and the documentation required
for it must be understood, demanded and
promoted by management.
Online Theme Special Agility 2016
Value #3: “Customer collaborationover
contract negotiation"
Customers pay for the purchase of
products. Therefore, they also
legitimately want a supply agreement
like a contract. However, there are some
problematic aspects, depending on the
type of product involved.
For example, building a house is
comparatively easy, while building a
skyscraper is probably complicated. But in
both cases the solution is known or can be
determined by analysis and calculations.
Therefore, it can be planned reliably.
However, software development is a
complex undertaking. Such projects are
non-linear because there are no simple
cause-and-effect relationships in them. It
is therefore impossible to predict exactly
the effect of a change.
In the case of complex projects, the
attempt to contractually fix the
requirements in detail in advance is not
only wasteful, but probably even
counterproductive. Instead,
management should work with the
customer and development to create a
shared vision and work as partners to
address any issues that arise through
feedback.
Value #4: “Responding to changeover
following a plan”
The fourth pair of values addresses
changes. Stable, predictive planning
depends on stable requirements. But the
requirements in complex projects are
constantly changing. Management must
ensure that the development process
accommodates frequent changes. For
management activities, this means
planning adaptively and continuously
and constantly adjusting the plan on the
basis of regular feedback instead of
blindly sticking to an initial project plan.
The Twelve Principles
Principle #1: “Our highest priority is to
satisfy the customer through early
and continuous delivery of valuable
software”
The first principle defines the goal for
organizations on their way to agility. The
aim is to provide the customer with
something of value – that is a clear
requirement.
In order to know what is really valuable
for the customer, their feedback is
necessary. Early and continuous delivery
 technical article Online Theme Special Agility 2016

that talks about these new requirements

first take place.
Management has to strike the balance
between chaos and bureaucracy, between
delegating responsibility to teams and
keeping the whole thing together.

Principle #3: “Deliver working software

frequently, from a couple of weeks to a
couple of months, with a preference to
the shorter timescale.”
The third principle addresses fast
delivery and thus the possibility of being
faster on the market. Delivering working
software quickly is technically and
organizationally difficult, but critical for a
company's success in dynamic markets.
Even if a team isn't good at it, it helps a
lot to know why. It's also not just about
agile development teams, it's about a
complete agile organization - it's about
delivery, not just development.

Management is responsible for

making the necessary organizational
changes to enable fast delivery.

Fig. 3:Principle #1. Principle #4: "Business people and

developers must work together daily
leads to early and regular feedback. The Implementing changes immediately throughout the project."
valuable software comes from the 20 leads to chaos. The development team The fourth principle is crystal clear: Daily
percent of the requirements that deliver must be able to reject this, and insist on communication between specialists
80 percent of the value. Namely from the
requirements that inspire the customer
the most.
It is management's responsibility to
align their organization's goals with
what customers want and the value they
want to deliver to customers.

Principle #2: “Welcome changing

requirements, even late in development.
Agile processes harness change for the
customer's competitive advantage.”
The world turns. The software
development world is spinning much
faster. Long-term planning may give you
peace of mind, but it doesn't bring you
the flexibility you need to stay
competitive. If you can react to changes
faster than the competition, then change
has become a competitive advantage.
Facilitating change is more effective than
trying to prevent it.
But agile is no excuse for being
disorganized! For example, if management
decides without consultation to accept new
and unknown requests Fig. 4:Principle #2.

3 www.object-spectrum.de
 technical article Online Theme Special Agility 2016

get to know him better. As servant

leaders, middle management must
ensure that teams have the environment
and support they need to do their jobs.
Top management must be an enabler, it
must enable middle management to
lead in a supportive manner.

Principle #6: "The most efficient and

effective method of conveying
information to and within a development
team is face-to-face conversation."
The sixth principle defines the gold
standard of communication. The most
information-rich form of communication
is face-to-face. Principles #4 (frequency
of communication) and #6 (quality of
communication) can lead to a deep
understanding of what is to be
developed together and thus to success.

Principle #7: "Working Software is the

Fig. 5:Rule #5.
experts and IT is essential. Problems
with this communication are the main
reason for unsuccessful projects and
also for problems with agile procedures.
It is management's job to demand and
support this continuous communication.
to plan, to learn, to form and maintain
relationships, and to
primary measure of progress."
It is human nature to try to measure
everything. Unfortunately, what is
measured is usually done. But the really
important things cannot be measured
because they are too complex. All in one

Principle #5: “Build projects around

motivated individuals. Give them the
environment and support they need, and
trust them to get the job done.” What
motivates knowledge workers? Dan Pink lists
three things that are necessary for people to
be intrinsically motivated [Pin11]:

- autonomy:Employees are largely

allowed to decide for themselves
how they do their work.
- Mastery:Employees must
have the opportunity to
learn in order to master
their work and grow with it.
- Purpose:Employees must
understand and support the
meaning and purpose of their work.

Employees make the difference between

success and failure.
Management must ensure that
employees have time to Fig. 6:Rule #8.

4 www.object-spectrum.de
 technical article
Fig. 7:Rule #12.
development projects need a common
language to talk about the progress of
their efforts.
The seventh principle defines
executable software as this common
language and not numbers ("80 percent
of the specification is complete", "the
design is 90 percent complete", etc.).
Principle #8: “Agile processes promote
sustainable development. The
sponsors, developers, and users
should be able to maintain a constant
pace indefinitely.” Sustainability is
important for a successful agile
approach. It is not agile to only consider
the three sides of the iron triangle
(scope, cost and time) and ignore quality.
When speed is prioritized over quality,
technical debt increases. Agile expands
the triangle and anchors quality as non-
negotiable in the golden square.
In order to achieve infinitely constant
pace, practices such as automated
testing and continuous integration must
be mastered. The skills for sustainable
development must be built up and
maintained. The
5 www.object-spectrum.de
Organization and management must
pave the way for this.
Principle #9: "Continuous attention to
technical excellence and good design
enhances agility."
The ninth principle is an extension of the
eighth. It doesn't skimp on quality to get
faster. It is precisely when quality is
taken seriously and technical debt is
avoided that it is possible to go faster.
Complex projects are non-linear and
small changes can have unpredictable
and far-reaching effects. Non-linearity
can be controlled by “just-in-time”
requirements instead of extensive
specifications and emergent design
instead of big upfront design. The
company must learn how to create
testable requirements (Requirements
Engineering, Behavior Driven
Development) and how to test before
coding (Test-Driven Development, TDD).
This requires quick feedback on whether
the software as a whole still works as
desired (continuous integration, CI,
continuous delivery, CD).
Online Theme Special Agility 2016
Technical excellence needs to be built
and maintained.
Principle #10: Simplicity - the art of
maximizing the amount of work not
done - is essential.
Maximize the amount of work that
doesn't need to be done! What's the
point of becoming faster and better at
delivery when delivering software
features that don't meet customers'
needs?
However, the simplicity demanded in
this principle should not only apply to
the selection of the software functions,
but also to their implementation. Test-
driven development writes only the code
that is necessary, and behavior-driven
development ensures simplicity at the
code level.
Simplicity also applies at the process
level! It is much more efficient to add to
a simple process than to subtract from a
process that is too complicated.
Principle #11: "The best architectures,
requirements and designs emerge from
self-organizing teams."
The eleventh principle is based on the
experience of the authors of the manifesto:
The better software is written by self-
organizing teams.
Self-organized teams are able to
reorganize in response to disruption and
eliminate the disruption. Despite this, in
most organizations, work at the
management levels is identified,
analyzed and broken down into
specialized tasks, which are then
delegated to specialized roles for
execution. But experience shows that
the teams that do the work are best
placed to make the architecture,
requirements, and design decisions.
Principle #12: At regular intervals, the
team reflects on how to become more
effective, then tunes and adjusts its
behavior accordingly.
Continuous improvement is only
achievable when teams are given the
opportunity to experiment. But
experiments cannot be dictated from
above for all teams, because every team
is different. What works for one team
may not work for another team.
For example, pair programming can
work very well in a team,
 technical article
another is perhaps not yet mature
enough for this. Therefore, management
must ensure that teams can experiment.
Support and encourage regular
retrospectives. Exemplify values such as
courage, openness and respect.
Summary
The Agile Manifesto is a to-do list for
managers moving their organization into the
6 www.object-spectrum.de
Online Theme Special Agility 2016
want to lead an agile world. Difficulties on this be firmly returned. A rich pool of agile
path can always be traced back to violations of practices can help to overcome these
the values or principles of Mani- difficulties. -
Literature & Links
[agile]Manifesto for Agile Software Development (Agile Manifesto), see:
agilemanifesto.org
[pin11]DH Pink, The Surprising Truth About What Motivates Us, Riverhead Books,
2011, see:http://www.danpink.com/books/drive/