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 Appleton25+ years in industry – last 20 w/large Telecom.Agile Leader, Coach & Manager

Scrum, XP, SAFe, LeSS, DADALM/SCM/DevOps Solution Architect

Git, JIRA, Confluence, TFS, RTC, Jenkins, CI/CDLeading 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

PRINCIPLESAgile Software Development

Scal

ing

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

InteractionsProcesses and Toolsove

rWorking Software

Comprehensive

Documentation

over

Responding to Change Following

a PlanoverCustomer

Collaboration

Contract Negotiationove

r

http://www.agilemanifesto.org/


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

http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658


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

http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658

http://www.poppendieck.com/ilsd.htm

http://www.infoq.com/resource/articles/poppendieck-implementing-lean/en/resources/poppendieck_ch02.pdf


Principles behind the Agile Manifesto

Continuous Technical Excellenceand Simplicity is Essential

Align, Support & Trust …Self-Organizing Teams

Collaborate Daily Across Functions and Convey Information via Conversation

Deliver Working Software Frequentlyat a Sustainable Pace

Welcome Change – Reflect and Adapt

Continuous Delivery of Customer-Valueand Working Software Defines Progress


Continuous Delivery of Customer-Value

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:

http://drdobbs.com/184414755


Continuous Delivery of Customer-Value

“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

http://www.rallydev.com/

http://www.amazon.com/Agile-Management-Software-Engineering-Constraints/dp/0131424602

http://www.informit.com/store/product.aspx?isbn=0321685857

http://jimhighsmith.com/2011/11/02/velocity-is-killing-agility/


Welcome ChangeWelcome 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:

http://drdobbs.com/184414755


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

http://www.processimpact.com/more_about_reqs_book/chapter_2.pdf

http://www.computer.org/portal/site/computer/menuitem.5d61c1d591162e4b0ef1bd108bcd45f3/index.jsp?&pName=computer_level1_article&TheCat=1005&path=computer/homepage/0308&file=cover.xml&xsl=article.xsl&;jsessionid=JykdXy48m4tvk2thLQP3drL1Gx2PNcTPKMtwY2q0fqRpB


Deliver Working Software Frequently

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:


Deliver Working Software Frequently“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

http://jamesshore.com/Agile-Book/

http://www.ambysoft.com/essays/whyAgileWorksFeedback.html


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

http://www.disciplinedagiledelivery.com/

http://www.adaptivesd.com/articles/IEEEArticle1Final.pdf


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:

http://www.ddj.com/184414755



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”





Convey Information via ConversationThe 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:




Convey Information via Conversation

“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)

http://www.amazon.com/Common-Knowledge-Companies-Thrive-Sharing/dp/0875849040



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



https://pragprog.com/book/tpp/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.

—Martin Fowler and James Highsmith, On the Agile Manifesto

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 PaceIf 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.”


http://www.agileforall.com/2009/07/24/new-to-agile-work-at-a-sustainable-pace/



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 Technical Excellence

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:

https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy

http://pragmaticcraftsman.com/2011/03/the-boy-scout-rule/

https://en.wikipedia.org/wiki/Technical_debt


Continuous Technical Excellence"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.”

—Martin Fowler and James Highsmith, On the Agile Manifesto

“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

http://www.poppendieck.com/llsd.htm


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

http://www.maartenvolders.com/blog/labels/simplicity.html



“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:


Self-Organizing Teams“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

http://www.scrumalliance.org/articles/6

http://www.stevedenning.com/High-Performance-Teams/most-high-performance-teams-are-self-organizing.aspx


Self-Organizing 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

http://www.futureworksconsulting.com/resources/TeamAgilityAgileTimesFeb04.pdf

http://blog.mountaingoatsoftware.com/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:



Values & Principles of Agile Software DevelopmentBrad AppletonInternal

BACKUP SLIDES

Align, Support &

Trust Self-

Organizing

Teams

Continuous Value thru Working Software

Welcome Change --

Reflect and Adapt

Deliv

er

Freq

uent

ly a

t

a S

usta

inab

le

Pace

Cont

inuo

us

Sim

plic

ity

& T

echn

ical

Exce

llenc

e

Collaborate

Daily

via

ConversationResponding

to change

Individuals &

Interactions Working

Software

Customer

Collaboration


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

http://www.cmcrossroads.com/agile-scm/6752-the-unchangeable-rules-of-software-change-and-what-to-do-about-it


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

http://jeffsutherland.com/papers/zivchaos.html

http://www.computer.org/portal/site/computer/menuitem.5d61c1d591162e4b0ef1bd108bcd45f3/index.jsp?&pName=computer_level1_article&TheCat=1005&path=computer/homepage/0308&file=cover.xml&xsl=article.xsl&;jsessionid=JykdXy48m4tvk2thLQP3drL1Gx2PNcTPKMtwY2q0fqRpB


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

http://www.cmcrossroads.com/agile-scm/6752-the-unchangeable-rules-of-software-change-and-what-to-do-about-it

http://blog.cutter.com/2008/09/16/to-attract-agile-change-embrace-uncertainty/

http://www.controlchaos.com/download/Emergence%20of%20Essential%20Systems.pdf


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


Self-Organizing TeamsAgile 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

http://www.infoq.com/articles/learning_is_the_bottleneck

http://www.poppendieck.com/ilsd.htm

http://www.stevedenning.com/High-Performance-Teams/most-high-performance-teams-are-self-organizing.aspx


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

http://www.agileadvice.com/archives/2005/12/agile_work_uses_2.html

http://www.scrumalliance.org/articles/6


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



Values & Principles of Agile Software DevelopmentBrad AppletonInternal

Appendix: Source Materials from specific Agile methods

Align, Support &

Trust Self-

Organizing

Teams

Continuous Value thru Working Software

Welcome Change --

Reflect and Adapt

Deliv

er

Freq

uent

ly a

t

a S

usta

inab

le

Pace

Cont

inuo

us

Sim

plic

ity

& Te

chni

cal

Exce

llenc

e

Collaborate

Daily

via

ConversationResponding

to change

Individuals &

Interactions Working

Software

Customer

Collaboration


XP ValuesExtreme 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

http://www.think-box.co.uk/blog/2006/01/why-agile-principles-are-important.html


XP PrinciplesHumanity: 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 ScrumCommitment: 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

http://www.amazon.com/Agile-Software-Development-Scrum/dp/0130676349


Principles of ScrumCommunicate: 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

http://www.amazon.com/Agile-Software-Development-Scrum/dp/0130676349

http://www.scrumalliance.org/articles/5-the-why-of-scrum

http://www.scrumalliance.org/articles/5-the-why-of-scrum


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

http://www.pmdoi.org/


9 Principles of DSDM1. 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

http://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/

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

http://www.informit.com/store/product.aspx?isbn=0131240714


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

http://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

http://www.agilemodeling.com/


7 Properties of Crystal Clear

1. Frequent Delivery2. Reflective Improvement3. Osmotic Communication4. Personal Safety5. Focus6. Easy Access to Expert Users7. Technical Environment with Automated Tests,

Configuration Management, and Frequent Integration

Source: Alistair Cockburn, The Seven Properties of Running an Agile Project

http://www.informit.com/articles/article.aspx?p=345009


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

http://www.ibm.com/developerworks/rational/library/oct05/kroll/index.html

The Values and Principles of Agile Software Development

Software

Transcript of The Values and Principles of Agile Software Development