The Values and Principles of Agile Software Development

The Values & Principles of
Agile Software Development
by Brad Appleton
created 21 October 2009,
last updated 9 February 2012

Values & Principles of Agile Software DevelopmentBrad Appleton 2
Presenter Information
Brad Appleton
25+ years in industry – last 20 w/large Telecom.
Agile Leader, Coach & Manager
 Scrum, XP, SAFe, LeSS, DAD
ALM/SCM/DevOps Solution Architect
 Git, JIRA, Confluence, TFS, RTC, Jenkins, CI/CD
Leading adoption & scaling of Agile development for large
organization since 2000.
Co-author: Software Configuration Management
Patterns (Addison-Wesley 2002), Agile CM Environments
(column in CM Journal), Reviewer for The Agile Journal

Values & Principles of Agile Software DevelopmentBrad Appleton
PRINCIPLES
Agile Software DevelopmentScaling
Adoption
Agility
Practices
Principles
Values
“Agile is a mindset defined by
values, guided by principles, and
manifested through many different
practices”
⎯Ahmed Sidky

Agile Values (from the Agile Manifesto)
The Agile Manifesto establishes a set of four values
that are people-centric and results-driven:
That is, while there is value in the items on the right,
we value the items on the left more.
(www.agilemanifesto.org)
Individuals and
Interactions
Processes
and Tools
over
Working
Software
Comprehensive
Documentation
over
Responding
to Change
Following
a Plan
over
Customer
Collaboration
Contract
Negotiationover

Simple Clear Purpose and Principles
“Simple clear purpose and principles give
rise to complex, intelligent behavior.
Complex rules and regulations give rise
to simple, stupid behavior.”
—Dee Hock, Founder of VISA corp.

Principles Guide Behavior Towards Values
❖ Values bring purpose to practices.
❖ Practices bring accountability to values.
❖ Principles bridge values and practices by
guiding behavior.
―Kent Beck, Extreme Programming Explained (2nd edition)
Values
Practices
Principles

Which comes first?
“Practices by themselves are barren. Unless
given purpose by values, they become rote.”
—Kent Beck, Extreme Programming Explained (2nd edition)
“Is it better to spend your time understanding principles
or studying practices? We observe that the best results
come from combining the two approaches.
Copying practices without understanding the underlying
principles has a long history of mediocre results.”
—Mary & Tom Poppendieck, Implementing Lean Software Development, Chapter 2 – Principles

Principles behind the Agile Manifesto
Continuous Technical Excellence
and Simplicity is Essential
Align, Support & Trust …Self-Organizing Teams
Collaborate Daily Across Functions and
Convey Information via Conversation
Deliver Working Software Frequently
at a Sustainable Pace
Welcome Change – Reflect and Adapt
Continuous Delivery of Customer-Value
and Working Software Defines Progress

Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
• Customers care about whether or not you're delivering working software to
them every development cycle—some piece of business functionality that
proves to them that the evolving software application serves their business
needs. —Martin Fowler & James Highsmith, On the Agile Manifesto
• Decompose work into testable increments of executable functionality, and
deliver them iteratively
• Set and regularly revisit priorities of backlog-items, based on which ones are
most valued by the customer
• Make plans responsive to changes in customer priorities.
Focus on the continuous flow of value to the customer
9
Agile Principle:
Meaning/Importance:
Actions/Behaviors:
Key Take-Away:

“Continuous delivery is about achieving flow. It is an aspect of lean
software development that seeks to minimize waste and maximize
efficiency and throughput.” —Dave Thomas, Rally Software
“Flow means that there is a steady movement of value through the
system. Client-valued functionality is moving regularly through the
system — and the steady arrival of throughput — with working code
being delivered.” —David J. Anderson, Agile Management for Software Engineering
“Flow of value enables transparency, in that you can measure what is
important to the customer (namely, potentially shippable software).
Transparency enables discovery of waste. Reducing waste, in turn,
accelerates flow and enables greater transparency.”
—Sam Guckenheimer, Agile Software Engineering
“We have to build and sustain a continuous value delivery engine, not
one that bangs out many features the first release and then rapidly
declines in ability thereafter.” —James Highsmith, Velocity is Killing Agility

Welcome Change
Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
• Requirements changes late in the lifecycle are competitive advantage, IF you
can act on them! —Mary Poppendieck
• Learn to trust in your ability to respond to unpredictable events; it's more
important than trusting in your ability to plan for disaster.
—Martin Fowler & James Highsmith, On the Agile Manifesto
• Embrace and adapt to changes.
• View changes as opportunities to learn and improve.
• Expect iterations reviews and retrospectives to result in changes to
requirements, plans and processes.
 Change will happen. If we anticipate it, watch for it, and are prepared
to react to it, we can use it to our advantage
 Burying or avoiding the effects of change only compounds the problem
11
Agile Principle:
Meaning/Importance:
Actions/Behaviors:
Key Take-Away:

Welcome Change
“It is not necessary to change; survival is not mandatory.”
—W. Edwards Deming
“It’s inevitable that requirements will change.
▪ Business needs evolve, new users or markets are identified,
business rules and government regulations are revised, and
operating environments change over time.
▪ In addition, the business need becomes clearer as the key
stakeholders become better educated about what their true needs
are.”
— Karl Wiegers, Cosmic Truths about Software Requirements
“Orders must change rapidly in response to change in circumstances. If one
sticks to the idea that once set, a plan should not be changed, a business
cannot exist for long.” —Taiichi Ohno, Toyota Production System
“It will be important to organize future projects with enough agility to be able
to adapt to the additional emergence of new sources of unpredictable
change.” —Barry Boehm, Making a Difference in the Software Industry, March 2008

Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
• Provides better transparency of genuine progress.
• Exposes risk earlier
• Allows for early and frequent customer feedback
• Encourages closer collaboration between teams
• The project is built around short iterations
• Iterations are focused on delivering testable, demonstrable, customer-valued
functionality
Rapidly delivering tangible, tested increments to customers facilitates
frequent feedback on executable end-results.
13
Agile Principle:
Meaning/Importance:
Actions/Behaviors:
Key Take-Away:

“Delivering working software frequently, as fast as possible
enables two important feedback loops:
• One is from actual customers to the developers, where customers
use the software and communicate how well it meets their needs.
• The other is from the team to the customers, where the team
communicates by demonstrating how trustworthy and capable it is.
Frequent delivery tightens these loops.”
―James Shore & Shane Warden, The Art of Agile Development
“One of several reasons why agile techniques are so effective
is that they reduce the feedback cycle-time between the
generation of an idea and the realization of that idea. This
not only minimizes the risk of misunderstanding, it also
reduces the cost of addressing any mistakes.”
―Scott Ambler, Why Agile Software Works: Improved Feedback

Collaborate Daily Across Functions
Business people and developers must work together daily throughout the
project.
• common focus, mutual trust, and respect;
• collaborative, but speedy, decision-making process;
• the ability to deal with ambiguity
• Use cross-functional teams that everyone needed to specify, develop, test
and deliver a working “slice” of functionality.
• Use standup meetings to communicate daily about issues and impediments
across disciplines.
• collaboration ≠ communication
Cross-functional collaboration on each small increment yields faster, more
effective knowledge transfer with less rework.
15
Agile Principle:
Meaning/Importance:
Actions/Behaviors:
Key Take-Away:

Collaborate Daily Across Functions
“Disciplined agile teams adopt practices such as on-site
customer and active stakeholder participation, and adopt
inclusive tools and techniques which enable stakeholders to
be actively involved with solution delivery.”
―Scott Ambler and Mark Lines, Disciplined Agile Delivery
“Agile teams are characterized by ... intense collaboration,
within and across organizational boundaries.
•teams have a common focus, mutual trust, and respect;
•a collaborative, but speedy, decision-making process;
•and the ability to deal with ambiguity.
We distinguish collaboration from communication.
•Communication is the sending and receiving of information.
•Collaboration is actively working together to deliver a work product
or make a decision.”
―James Highsmith & Alistair Cockburn, Agile Software Development: The Business of Innovation

Align, Support & Trust
Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
• Lean teaches us that decisions must be made by the people who know the most
about the situation.
• This means that managers must trust their staff to make the decisions about the
things they're paid to know about. ―Martin Fowler & James Highsmith, On the Agile Manifesto
• Leadership-collaboration rather than command-control management.
• Set goals & constraints, providing boundaries in which innovation can flourish.
• Who makes decisions isn’t as important as collaboration on information to make
informed decisions.
• Agility depends on trusting individuals to apply their competency in effective
ways. ―James Highsmith & Alistair Cockburn, Agile Software Development: The People Factor
Empower from above, support from beneath, then trust in the collective
ownership of motivated people with a common purpose.
17
Agile Principle:
Meaning/Importance:
Actions/Behaviors:
Key Take-Away:

Align, Support & Trust
“Agile companies practice leadership-collaboration rather
than command-control management.
▪ They set goals and constraints, providing boundaries within which
innovation can flourish.
▪ They understand that who makes decisions isn’t as important as
collaboration on information to make informed decisions.
▪ They understand that agility depends on trusting individuals to apply
their competency in effective ways.”
―James Highsmith & Alistair Cockburn, Agile Software Development: The People Factor
“Realize that you need to build teams from people who are willing to
work together collaboratively and learn from each other. Have the
humility to respect one another and realize that people are a
primary success factor in solution delivery. Allow them to create an
environment in which they will thrive as a team”

The most efficient and effective method of conveying information with and
within a development team is face-to-face conversation.
• The issue is not documentation — the issue is understanding! The indicator of
success is … Will the people involved gain the understanding they need?
•Writing is difficult and inefficient … We use it because we have to, but most
project teams can and should use more direct communication techniques.
―Martin Fowler & James Highsmith, On the Agile Manifesto
• Place people physically closer
• Replace documents with talking in person and at whiteboards
• Improve the team’s amicability ― its sense of community and morale ― so that
people are more inclined to relay valuable information quickly.
―James Highsmith & Alistair Cockburn, Agile Software Development: The People Factor
Documentation efforts should be limited to only what is absolutely essential
for the purpose of facilitating shared understanding with stakeholders and to
maintain and evolve the product.
19
Agile Principle:
Meaning/Importance:
Actions/Behaviors:
Key Take-Away:

“Tacit knowledge cannot be transferred …
onto paper.
▪ Tacit knowledge can be transferred by moving the
people who have the knowledge around.
▪ The reason is … tacit knowledge is not only the
facts but the relationships among the facts—that
is, how people might combine certain facts to
deal with a specific situation.”
―Nancy Dixon, Common Knowledge (Harvard Business School Press)

SECI stages from Ikujiro Nonaka and Noboru Konno in their article "The Concept of ‘Ba’: Building a
Foundation for Knowledge Creation" published in California Management Review, vol. 40, #3, 1998“.

Working Software Defines Progress
Working Software is the primary measure of progress.
• Provides milestones that can't be fudged, which imparts an accurate measure of
the progress and a deeper understanding of the risks involved in any given project
—Martin Fowler and James Highsmith, On the Agile Manifesto
• Provides stakeholders with concrete feedback, making the current status of your
project transparent while providing an opportunity for stakeholders to provide
improved direction for the development team —Scott Ambler, IBM Agile Practice Leader
No “partial credit! Don’t accept development tasks/changes as “completed”
until they are:
• Implemented & Unit-Tested
• Integrated, Built & Regression Tested
• Accepted & Validated by Downstream Consumers
No other indicator of progress is more trustworthy or transparent than
visibly tangible, working, end-results.
23
Agile Principle:
Meaning/Importance:
Actions/Behaviors:
Key Take-Away:

Working Software Defines Progress
“Working software tells the developers and sponsors what they
really have in front of them—as opposed to promises as to
what they will have in front of them. The working software
can be shipped, modified, or scrapped, but it is always real.”
―James Highsmith & Alistair Cockburn, Agile Software Development: The Business of Innovation
“The primary measure of a solution delivery project should be the
delivery of a consumable solution that provides actual value to your
stakeholders. This solution should meet the changing needs of its
stakeholders, not some form of ‘earned value’ based on the delivery
of documentation of the holding of meetings.”
“Working software is the measure of progress because there's no other
way of capturing the subtleties of the requirements: Documents and
diagrams are too abstract to let the user ‘kick the tires’.”
—Dave Thomas, coauthor of The Pragmatic Programmer

Sustainable Pace
Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.
• Sustainable development means finding a working pace (40 or so hours a week)
that the team can sustain over time and remain healthy.
•Agility relies upon people who are alert and creative, and can maintain that
alertness and creativity for the full length of a software development project.
Work at a steady but productive cadence with enough energy-reserves to
occasionally “sprint” when needed.
 Work only as many hours as you can be productive and only as many
hours as you can sustain.
 Burning yourself out unproductively today and spoiling the next two
days' work isn't good for you or the team. —Kent Beck
25
Agile Principle:
Meaning/Importance:
Actions/Behaviors:
Key Take-Away:

Sustainable Pace
If the pace of the team is not sustainable several undesirable
effects are likely to occur:
1. Defects will increase. Tired teams let more defects through.
2. Work output will decrease. Tired teams do less work in more time!
3. Morale will drastically decrease. This may lead to employee
turnover at a most unfortunate time in the project.
4. The blame game will become common. (Not our fault you didn’t
say X. I said X. Did not. Did so…)
5. The team starts to abandon good practices for those that “seem”
faster. —Bob Hartman, Work at a Sustainable Pace
“Our experience is that you can only do high-quality, intellectual work
for 5 to 6 hours a day before burning yourself out. The rest of the
day can be filled up with email, meetings, water cooler discussions and
so on, but people’s ability to do ‘real work’ is limited.”

The Agile Promise and the Agile Premise
The Agile “promise” is that rapid-responsiveness to
change will yield returns of improved cycle-time and
quality with far less rework (and at a sustainable pace).
The Agile “premise” that makes it all possible is that we
constantly keep all artifacts clean and lean so they are
always easy to change quickly!
• This applies not only to product-artifacts (e.g., code, designs,
specs) but also to planning and process artifacts.
The way we do this is with continuous technical excellence
and ruthless simplicity-of-design!

Continuous attention to technical excellence and good design enhances agility.
• To embrace change we must be working off a technically solid foundation
• Otherwise change becomes risky and a thing to be avoided.
• Design is a continuous activity that's performed throughout the project (not
just up front)
• Don’t live with “broken windows” — and follow the boy scout rule
• Establish a Definition of Done (“Done Done”)
• Continuous Integration with Automated Testing
• Emergent & Incremental Design with Refactoring/Restructuring
 Prolonged inattention to technical excellence and good design creates
technical debt, which compounds until it is paid!
 Technical debt impedes agility and lowers the team’s productivity
28
Agile Principle:
Meaning/Importance:
Actions/Behaviors:
Key Take-Away:

"Agile approaches emphasize quality of design, because
design quality is essential to maintaining agility.
One of the tricky aspects, however, is the fact that agile processes
assume and encourage the alteration of requirements while the
code is being written.
• As such, design cannot be a purely up-front activity to be
completed before construction.
• Instead, design is a continuous activity that's performed
throughout the project.
• Each and every iteration will have design work.”
“We are what we repeatedly do. Excellence, therefore, is
not an act, but a habit.” —Aristotle

Complexity Kills Projects!
Fred Brooks wrote, “Software entities are more complex
for their size than perhaps any other human construct.
Many of the classic problems of developing software
products derive from this essential complexity and its
nonlinear increases with size.”
• Extra features increase the complexity of the code, driving up costs
nonlinearly —the cost of the system with that extra code is not just
double; it's perhaps ten times more expensive.
• Business processes should be simplified first and automated later.
How often do we help our customers simplify their processes before
automating them?
• The cost of complexity is hidden; it has a second-order effect on
cost, so we just don't see it in our financial systems.
• This makes complexity all the more pernicious —it's hard to cost-
justify spending money to keep things simple.
—Mary Poppendieck, Leading Lean Software Development

Simplicity is Essential
Simplicity — the art of maximizing the amount of work not done — is essential.
• As projects change and evolve, “working ahead” results in wasted effort and
rework.
• This applies to both technical work and project planning.
• Defer decisions until the last responsible moment. Deferred decisions should
not result in significant rework (technical debt)
• Do “just enough” and “just in time”; no “just in case”
• Practice “emergent design” with continual refactoring and periodic
restructuring
• Routinely question if a task/artifact is necessary and sufficient to: satisfy
iteration goals or quality concerns, sustain the product, and simplify its
evolution.
Do “just enough” just-in-time, then keep it clean and simple!
31
Agile Principle:
Meaning/Importance:
Actions/Behaviors:
Key Take-Away:

There is a fundamental misunderstanding of simplicity and
what it means to be simple:
• Many confuse simple with “simplistic” and “simplism” or that
which is dumbed-down to the point of being deceptive or
misleading.
• “Simple” to some people means a kind of oversimplification of an
issue, which ignores complexities and creates obfuscation and
outright falsehoods.
“Simple” refers to being essentially, synonymous for clarity,
directness, essentialness and minimalism. The simple
solutions are not necessarily the easiest [to do], but results
may end up being the “easiest” to use.
—Maarten Volders, Scrum Master, on Simplicity and Why it Matters
“Perfection (in design) is achieved not when there is nothing more
to add, but rather when there is nothing more to take away.”
—Antoine de Saint-Exupéry

“A complex system that works is invariably found to have
evolved from a simple system that worked.” —John Gall
“Simplify means to eliminate the unnecessary so that the necessary
may speak.” —Hans Hofmann
“The most powerful designs are always the result of a continuous
process of simplification and refinement.” —Kevin Mullet
“Simplicity is about subtracting the obvious, and adding the
meaningful. The simplest way to achieve it is through thoughtful
reduction” —John Maeda
“Fools ignore complexity; pragmatists suffer it; experts avoid it;
geniuses remove it.” —Alan Perlis

Self-Organizing Teams
The best architectures, requirements, and designs emerge from self-organizing
teams.
• Those who do the work are in the best position to know how to get it done.
• When given freedom within boundaries, teams will automatically gravitate
toward efficient solutions and will quickly adapt as needed.
• Stakeholders define the project goals and high-level schedules
• Development teams determine the best way to meet the goals and schedule
requirements.
• Management trusts the team to deliver on its commitments and need not look
“under the covers”
• The team has the responsibility to timely alert management to significant risks to
their commitments.
Agile teams collectively decide and do what is needed to: make and meet
commitments, develop a quality product, respond to feedback, and adapt
to changes.
34
Agile Principle:
Meaning/Importance:
Actions/Behaviors:
Key Take-Away:

“Results emerge as a result of interactions….
Individuals within the system need to follow a set of
rules of interaction that allow feedback loops to be
created and to grow. New behaviors and capabilities
emerge from these feedback loops.”
—Matt Truxaw, Emergent behavior in software development teams
“What generates the energy and passion of self-organizing
teams, and their eventual high productivity, is that …
• members enjoy the opportunity to organize their own work
• and contribute their full human potential to the collectivity,
• rather than being limited to what the organization thinks it
can absorb, and only at those moments when it is ready to
absorb it.”
—Steve Denning, Creating & Sustaining High-Performance Teams

“This causes a shift in the roles of managers from planning,
controlling, directing, and managing to new roles like building
trust, facilitating and supporting team decisions, expanding
team capabilities, anticipating and influencing change.”
―Diana Larsen, Exploring Self-Organizing Software Development Teams
“The team’s job is to self-organize around the challenges,
and within the boundaries and constraints, put in place
by management.
• Management’s job is to come up with appropriate challenges
and remove impediments to self-organization.
• That being said, the fewer constraints or controls put on a
team, the better.
• If leaders overly constrain how a team solves the challenge
given to it, self-organization will not occur.”
—Mike Cohn, The Role of Leaders on a Self-Organizing Team

Reflect and Adapt
At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.
Agile methods are not something you pick and follow slavishly.
• We can't come up with the right process for every situation.
• An agile team must refine and reflect as it goes along, constantly improving its
practices in its local circumstances. ―Martin Fowler and James Highsmith, On the Agile Manifesto
Those doing the work know best what is working and what needs fixing
• Reflect (look backward to move forward): Conduct team-wide retrospectives
at the close of each iteration (and at other important transitional milestones)
• Introspect: Constantly ask “is there a better/simpler way to do this?” and
“What have we learned from this?”
• Adapt: Execute and follow-through on making needed improvements
identified by the team.
Reflect and adapt in regular cycles to continuously learn and improve.
37
Agile Principle:
Meaning/Importance:
Actions/Behaviors:
Key Take-Away:

Internal
BACKUP SLIDES
Continuous Value thru
Working Software
Welcome Change --
Reflect and Adapt

Values vs. Principles vs. Practices
“We need all three to combine into the optimum blend:
– We need values to use as filters for our decisions.
– We need principles to give us ideas about what values
look like when they come out of the clouds and into
actual work on the ground.
– We need practices to … practice, to understand and build
skill in our craft.
Three go in, one optimum blend comes out.
That's where our skill as practitioners of Agile becomes
critical, creating the blend of values-based, principle-
guided, practice-grounded environments where project
teams can succeed at delivering value to the customers.”
—Diana Larsen, Agile Alliance Newsletter, Nov. 2009

The Unchangeable Rules of Software Change
Rule #0: Change is Inevitable!
The Requirements/Plans ARE going to change!
Rule #1: Resistance is Futile!
There isn't a darn thing you can do to prevent Rule #0.
Rule #2: Change is like Quicksand -- Fighting it only makes it worse!
The more you try to deny and defy rule #1 by attempting to prevent
rule #0, the worse things will get.
Rule #3: Change is like Quicksilver -- Tightening your grip makes it slip
from your grasp!
The more you try to deny and defy rule #2 by attempting to
precisely predict, or rigidly control change, the more erratic and
onerous the result will be.
Rule #4: Embrace change to control change!
The more flexible and adaptive you are at accommodating change,
the more control you will have over your outcomes.
— From The Unchangeable Rules of Software Change, The CM Journal, Feb 2006

Quotes on Change and Uncertainty
❖ It’s not the strongest who survive, nor the most intelligent, but the ones
most adaptable to change. —attributed to Charles Darwin
❖ Doubt is not a pleasant condition, but certainty is absurd. —Voltaire
❖ It is not necessary to change; survival is not mandatory. —W. Edwards Deming
❖ When the rate of change outside exceeds the rate of change inside, the end
is in sight. —Jack Welch
❖ Orders must change rapidly in response to change in circumstances. If one
sticks to the idea that once set, a plan should not be changed, a business
cannot exist for long. —Taiichi Ohno, Toyota Production System
❖ Uncertainty is inherent and inevitable in software development processes
and products. —H. Ziv and D.J. Richardson, The Uncertainty Principle in Software
Engineering, Aug 1996
❖ It will be important to organize future projects with enough agility to be able
to adapt to the additional emergence of new sources of unpredictable
change. —Barry Boehm, Making a Difference in the Software Industry, March 2008

Quotes on Change and Uncertainty [2]
❖ There is a highly sophisticated technical term biologists use to
describe completely stable systems. This fancy technical term is the
word “DEAD!” Change is not the enemy – stagnation is!
—From The Unchangeable Rules of Software Change
❖ Requirements changes late in the lifecycle are competitive advantage,
IF you can act on them! —Mary Poppendieck
❖ Becoming agile means accepting uncertainty about the future as a
way of dealing with the future. Any project development effort should
be a balance between anticipation (planning based on what we know
now) and adaptation (responding to what we learn over time).
—James Highsmith, Embrace Uncertainty
❖ Scrum’s Uncertainty Principle is: Customers don’t know what they want
until they see it, and they always reserve the right to change their mind.
—Jeff Sutherland, Emergence of Essential Systems

Quotes on Change and Uncertainty [3]
“Systems requirements cannot ever be stated fully in advance, not even
in principle, because the user doesn’t know them in advance--not
even in principle.
To assert otherwise is to ignore the fact that the development process
itself changes the user’s perceptions of what is possible, increases
his or her insights into the applications environment, and indeed
often changes that environment itself.
We suggest an analogy with the Heisenberg Uncertainty Principle: any
system development activity inevitably changes the environment out
of which the need for the system arose. System development
methodology must take into account that the user, and his or her
needs and environment, change during the process.”
—Dan McCracken and Michael A. Jackson, ACM SIGSoft, 1982

Quotes On Simplicity
❖ Perfection (in design) is achieved not when there is nothing more to add, but
rather when there is nothing more to take away. —Antoine de Saint-Exupéry
❖ There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult. —C.A.R. Hoare
❖ A complex system that works is invariably found to have evolved from a
simple system that worked. —John Gall
❖ The most powerful designs are always the result of a continuous process of
simplification and refinement. —Kevin Mullet
❖ Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses
remove it. —Alan Perlis
❖ Simplify means to eliminate the unnecessary so that the necessary may
speak. —Hans Hofmann
❖ Simplicity is about subtracting the obvious, and adding the meaningful. The
simplest way to achieve it is through thoughtful reduction —John Maeda

Quotes On Simplicity [2]
❖ Simple, clear purpose and principles give rise to complex intelligent behavior.
Complex rules and regulations give rise to simple stupid behavior. —Dee Hock
❖ Everything should be made as simple as possible, but not simpler. … Out of
clutter find simplicity; From discord find harmony; In the middle of difficulty
lies opportunity. —Albert Einstein
❖ Making the simple complicated is commonplace; making the complicated
simple, awesomely simple, that's creativity. —Charles Mingus
❖ Besides the noble art of getting things done, there is the noble art of leaving
things undone. The wisdom of life consists in the elimination of
nonessentials. —Lin Yu Tang
❖ Very often, people confuse simple with simplistic. The nuance is lost on
most. —Clement Mok
❖ Any intelligent fool can make things bigger, more complex, and more violent.
It takes a touch of genius--and a lot of courage--to move in the opposite
direction. —E. F. Schumacker
❖ Think simple … meaning reduce the whole of its parts into the simplest
terms, getting back to first principles. —Frank Lloyd Wright

Agile teams collectively decide and do what is needed to: make and
meet commitments, develop a quality product, respond to
feedback, and adapt to changes.
Self-Organizing Teams are:
•Autonomous: There is no single central decision-making authority.
Control is distributed collectively to the team.
•Adaptive: The team dynamically adjusts as needed across roles,
functional specialties, and other boundaries, in order to solve their own
problems and improve their own performance.
•Accountable: The team collectively shares responsibility for results,
and members hold each other accountable for outcomes.

Quotes On Self-Organizing Teams
Self-organization does not mean that workers instead of
managers engineer an organization design. It does not
mean letting people do whatever they want to do. It means
that management commits to guiding the evolution of
behaviors that emerge from the interaction of independent
agents instead of specifying in advance what effective
behavior is. —Philip Anderson, The Biology of Business
Self-organizing teams are not free from management control.
Management chooses for them what product to build or often
chooses who will work on their project, but they are
nonetheless self-organizing. Neither are they free from
influence. —Mike Cohn, The Role of Leaders on a Self-Organizing Team

Quotes On Self-Organizing Teams
❖ A self-organized team is possible when people carry shared purpose,
principles and values. They support and respect each other. And they want
to succeed. The team works together to respond to changes that happen
together. They collectively do what needs to be done to build the software.
—Amr Elssamadisy & Deborah Hartmann, Learning is the Bottleneck
❖ Responsibility-Based Planning and Control: Respecting people means that
teams are given general plans and reasonable goals and are trusted to
self-organize to meet the goals. Respect means that instead of telling
people what to do and how to do it, you develop a reflexive organization
where people use their heads and figure this out for themselves.
—Mary Poppendieck, Implementing Lean Software Development
❖ What generates the energy and passion of self-organizing teams, and their
eventual high productivity, is that the members enjoy the opportunity to
organize their own work and contribute their full human potential to the
collectivity, rather than being limited to what the organization thinks it can
absorb, and only at those moments when it is ready to absorb it.
—Steve Denning, Creating & Sustaining High-Performance Teams

Quotes On Self-Organizing Teams [2]
❖ In agile teams, this concept of self-organization is taken quite far. Team
members collaborate to get work done. No one orders a team or individual
to do specific work. The team members volunteer for work that they see
needs doing, even if it is not something that is in their area of expertise. An
agile team is constantly promoting learning in its people.
—Mishkin Berteig, Team Self-Organization
❖ Scrum/Agile teams are self-organizing systems. Results emerge as a
result of interactions between the individuals on the team [and the team’s
values/principles]. Individuals within the system need to follow a set of
rules of interaction that allow feedback loops to be created and to grow.
New behaviors and capabilities emerge from these feedback loops.
—Matt Truxaw, Emergent behavior in software development teams

Agility in the Enterprise
“Adopting a disciplined approach to agile
delivery requires the courage to rethink some of
the agile rhetoric and make compromises where
necessary for the benefit of the ‘whole
enterprise’ and not just the whole team.
• In our experience most agile projects make compromises that
are not classically agile in order to get the job done.
• Rather than hiding this and fearing reprisals from those who
would accuse you of regressing to a traditional approach, it is
better to have the courage to take a pragmatic approach to
using agile in your situation

Internal
Appendix: Source Materials
from specific Agile methods
Continuous Value thru
Working Software
Welcome Change --
Reflect and Adapt

XP Values
Extreme Programming initially recognized four values in
1999. A new value was added in the second edition of
Extreme Programming Explained.
The five values are:
• Communication
• Simplicity
• Feedback
• Courage
• Respect
See also “Why Agile Principles are Important” by Simon Baker

XP Principles
Humanity: Acknowledge human frailty, leverage human strengths,
and balance individual and team needs.
Economics: Enhance the option value of the software and the
team while remembering the time value of money.
Mutual benefit: All activities should benefit everyone.
Self-similarity: When something works in one context, try it in
another. Even if it eventually doesn't work, it's a start.
Improvement: 'Perfect' is a verb and not an adjective. Always
seek to improve.
Diversity: The team should comprise people with different
backgrounds, skills and perspectives.
Reflection: Think about how you're working and why you're
working.

XP Principles [2]
Flow: Deliver a steady flow of business value by engaging in all
activities simultaneously.
Opportunity: See problems as opportunities for change and
learning.
Redundancy: Don't be afraid to include redundancy, e.g. a distinct
testing phase after development, if it helps prevent disaster.
Failure: If you're having trouble succeeding, don't be afraid to fail.
Quality: Always push for higher quality.
Baby steps: The overhead of small steps is less than when a team
wastefully recoils from aborted big changes.
Accepted responsibility: Responsibility cannot be assigned. It
can only be accepted.

5 Values of Scrum
Commitment: Be willing to commit to a goal. Scrum provides
people all the authority they need to meet their commitments.
Focus: Do your job. Focus all your efforts and skills on doing the
work that you’re committed to doing. Don’t worry about anything
else.
Openness: Scrum keeps everything about a project visible to
everyone.
Respect: Individuals are shaped by their background and their
experiences. It is important to respect the different people who
comprise a team.
Courage: Have the courage to commit, to act, to be open, and to
expect respect.
Source: Agile Software Development with Scrum by Ken Schwaber and Mike Beedle

Principles of Scrum
Communicate: Share information and create daily visibility into
the project.
Self-organization: Empower the Team.
Learn and improve via experimentation, feedback & adaptation.
Deliver Value Early and Build Trust with Incremental
Product Delivery.
Respond & Manage Empirically: software development is
best implemented via an empirical rather than a rigid, inflexible
process.
The “Art of the possible”: Focus on fixed-time over fixed-
scope (do not dwell on what cannot be done).
Source: Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
also: The “Why” of Scrum by Chris Fry of the Scrum Alliance

Project Mgmt Declaration of Interdependence
Value: We increase return on investment by making continuous
flow of value our focus.
Customer: We deliver reliable results by engaging customers in
frequent interactions and shared ownership.
Uncertainty: We expect uncertainty and manage for it through
iterations, anticipation and adaptation.
Individuals: We unleash creativity and innovation by recognizing
that individuals are the ultimate source of value, and creating an
environment where they can make a difference.
Teams: We boost performance through group accountability for
results and shared responsibility for team effectiveness.
Context: We improve effectiveness and reliability through
situationally specific strategies, processes and practices.
Source: www.pmdoi.org

9 Principles of DSDM
1. Active user involvement is imperative.
2. DSDM teams must be empowered to make decisions.
3. The focus is on frequent delivery of products.
4. Fitness for business purpose is the essential criterion for
acceptance of deliverables.
5. Iterative and incremental development is necessary to
converge on an accurate business solution.
6. All changes during development are reversible.
7. Requirements are baselined at a high level.
8. Testing is integrated throughout the lifecycle.
9. A collaborative and co-operative approach between all
stakeholders is essential.
Source: www.dsdm.org

9 Principles of Adaptive Sw Development
1. Deliver something to the client; check what they value.
2. Cultivate committed stakeholders.
3. Employ a leadership-collaboration style.
4. Build competent collaborative teams.
5. Enable team decision-making.
6. Use short timeboxed iterations to quickly deliver
features.
7. Encourage adaptability.
8. Champion technical excellence.
9. Focus on delivery activities, not process-compliance
activities.
Source: http://www.jimhighsmith.com/

Agile Leadership & Management Principles
Foster Alignment and Cooperation
• Organic teams: Enabling connections and adaptation through close
relationships on small, flexible teams.
• Guiding vision: Keeping the team aligned and directed with a shared
mental model.
Encourage Emergence and Self-Organization
• Simple rules: Establishing a set of simple, generative process rules for
the team.
• Open information: Providing free and open access to information.
• Light touch: Applying intelligent control to foster emergent order and
maximal value.
Institute Learning and Adaptation
• Adaptive leadership: Steering the project by continuously monitoring,
learning, and adapting.
Source: Sanjiv Augustine, Managing Agile Projects

7 Principles of Lean Software Development
1. Eliminate Waste (Extra Features, Reqts Churn, Handoffs)
2. Create Knowledge (Learn and Adapt thru Feedback)
3. Build Quality In (Continuous Integration & Automated Testing)
4. Defer Commitment (to the “Last Responsible Moment”)
5. Deliver Fast
6. Respect People (Empower the Team)
7. Improve the System (Optimize the Whole)
Source: Mary & Tom Poppendieck, www.poppendieck.com

Principles of Agile Modeling
• Assume Simplicity
• Embrace Change
• Enabling the Next Effort is
Your Secondary Goal
• Incremental Change
• Maximize Stakeholder ROI
• Model With a Purpose
• Multiple Models
• Quality Work
• Rapid Feedback
• Working Software Is Your
Primary Goal
• Travel Light
• Content Matters More Than
Representation
• Open and Honest
Communication
Source: Scott Ambler, www.agilemodeling.com

7 Properties of Crystal Clear
1. Frequent Delivery
2. Reflective Improvement
3. Osmotic Communication
4. Personal Safety
5. Focus
6. Easy Access to Expert Users
7. Technical Environment with Automated Tests,
Configuration Management, and Frequent Integration
Source: Alistair Cockburn, The Seven Properties of Running an Agile Project

Principles of the Agile Unified Process (AUP)
❖ Adapt the Process
❖ Balance Competing Stakeholder Priorities
❖ Collaborate Across Teams
❖ Demonstrate Value Iteratively
❖ Elevate the Level of Abstraction
❖ Focus Continuously on Quality
Source: Per Kroll & Walker Royce, Key Principles for
Business-Driven Development

The Values and Principles of Agile Software Development

More Related Content

The Values and Principles of Agile Software Development