What is Agile?

August 20, 2013

Consultant
www.crisp.se Henrik Kniberg
henrik.kniberg@crisp.se Father
@HenrikKniberg

Agile & Lean coach

Author

(& more...)
 Boring but important practical info about these slides
Usage
Feel free to use slides & pictures as you wish, as long as you leave my name somewhere.
For licensing details see Creative Commons (http://creativecommons.org/licenses/by/3.0/)

Downloading the right font

This presentation uses the ”Noteworthy” font. If you’re using Mac OSX 10.7 or later it should be
preinstalled. If you’re on a Windows or older Mac OS then you need to download the font from here:
http://tinyurl.com/noteworthy-ttc
•  On Windows right-click the font file and select ”install”. Then restart Powerpoint.
•  On Mac, double-click the font file and press ”install font”. Then restart Powerpoint.

The PDF version of these slides has the font embedded, so you don’t need to do anything. On the other
hand you don’t get the fancy animations.

Font test
How the font is supposed to look: How the font shows up on your computer:
(screenshot from my computer)

The quick brown fox jumps over the lazy dog

The quick brown fox jumps over the lazy dog

Regardless of font appearance, if that text doesn’t fit nicely into

the box then you’re going to need to download the right font, or
switch to a new font and fiddle with the slides to make sure
Henrik Kniberg things fit.
 Why? How?
Agile is...

Early delivery of business value

Less bureaucracy

Henrik Kniberg (Thanks Alistair Cockburn for this simplified definition of Agile)
 All products / features start with a Great Idea!

Henrik Kniberg
 Unfortunately..... it is likely to fail

Plan

Reality

Henrik Kniberg
 Long projects get Longer

More scope
Longer project creep

More likely to
get interrupted

Henrik Kniberg
 Most IT projects fail. And are late.
The Standish Group has studied over 40,000 projects in 10 years.

IT project success rate 1994: 15%

Average cost & time overrun: ≈170%
Plan: €1,000,000
Actual: €2,700,000


IT project success rate 2004: 34%
Average cost & time overrun: ≈70%
Plan: €1,000,000

Actual: €1,700,000

Sources:
http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish
Henrik Kniberg http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS
 We tend to build the wrong thing
Features and functions used in a typical system

Half of the
stuff we build Always
is never used! 7%
Often
13%
Never
45%

Cost
Some-
times
16%

Rarely
19%

# of features

Sources:
Standish group study reported at XP2002 by Jim Johnson, Chairman

Henrik Kniberg The right-hand graph is courtesy of Mary Poppendieck

 Big Bang

01:39
Henrik Kniberg
 Big Bang = Big Risk

Cumulative
RISK Value

Henrik Kniberg
Big Bang = cannon ball
Assumptions:
•  The customer knows what he wants
•  The developers know how to build it
•  Nothing will change along the way

Henrik Kniberg
 Agile

01:36
Henrik Kniberg
 Agile = homing missile
Assumptions:
•  The customer discovers what he wants
•  The developers discover how to build it
•  Things change along the way

Henrik Kniberg
 Agile Manifesto

www.agilemanifesto.org
We are uncovering better ways of developing
software by doing it and helping others do it.
Feb 11-13, 2001
Snowbird ski resort, Utah

Kent Beck Ron Jeffries
Mike Beedle Jon Kern
Arie van Bennekum Brian Marick
Alistair Cockburn Robert C. Martin
Ward Cunningham Steve Mellor
Martin Fowler Ken Schwaber
James Grenning Jeff Sutherland
Jim Highsmith Dave Thomas
Andrew Hunt
14

Henrik Kniberg
 Agile Manifesto
www.agilemanifesto.org
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools

Individer och interaktioner framför processer och verktyg

Working software over comprehensive documentation

Fungerande programvara framför omfattande dokumentation

Customer collaboration over contract negotiation

Kundsamarbete framför kontraktsförhandling

Responding to change over following a plan

Anpassning till förändring framför att följa en plan

That is, while there is value in the items on

the right, we value the items on the left more.
15

Henrik Kniberg
 Principles behind the Agile Manifesto
•  Our highest priority is to satisfy the customer •  Working software is the primary measure of
through early and continuous delivery of valuable progress.
software. •  Agile processes promote sustainable
•  Welcome changing requirements, even late in development. The sponsors, developers, and
development. Agile processes harness change for users should be able to maintain a constant
the customer's competitive advantage. pace indefinitely.
•  Deliver working software frequently, from a •  Continuous attention to technical excellence
couple of weeks to a couple of months, with a and good design enhances agility.
preference to the shorter timescale. •  Simplicity--the art of maximizing the amount of
•  Business people and developers must work work not done--is essential.
together daily throughout the project. •  The best architectures, requirements, and
•  Build projects around motivated individuals. Give designs emerge from self-organizing teams.
them the environment and support they need, and •  At regular intervals, the team reflects on how
trust them to get the job done. to become more effective, then tunes and
•  The most efficient and effective method of adjusts its behavior accordingly.
conveying information to and within a development
team is face-to-face conversation.
Agile ”umbrella” –
a family of iterative, incremental methods

FDD
DSDM

Scrum XP
Crystal

Kanban Sources:
3rd Annual ”State of Agile Development” Survey June-July 2008
•  3061 respondents
•  80 countries
 Iterative & Incremental

01:32
Henrik Kniberg
Agile = Iterative + Incremental

Don’t try to get it all right Don’t build it all at once

from the beginning

cost value
cost
value
RISK

Henrik Kniberg
 Not ”horizontal” increments
3
Client

Server 2
value
DB 1

1 4
2 3

Henrik Kniberg
 ”Vertical” increments!
Client 1 2 3
value
Server

DB

1 2 3 4 5

Henrik Kniberg
 Keep iterations short
(2-3 weeks)

Less scope
Short iteration creep

Less likely to
get interrupted

Henrik Kniberg
 Planning is easier with frequent releases

Henrik Kniberg
 Planning

01:26
Henrik Kniberg
 Face it.
Estimates are almost always Wrong!

Henrik Kniberg
 How estimates are affected by specification
length
Spec Same spec – more pages

117 hrs 173 hrs

Source: How to avoid impact from irrelevant and misleading info

on your cost estimates, Simula research labs estimation seminar,
Henrik Kniberg Oslo, Norway, 2006
 How estimates are affected by
irrelevant information
Spec 1 Same spec
A + irrelevant details
B
A
C
B
C

20 hrs

39 hrs

Source: How to avoid impact from irrelevant and misleading info

on your cost estimates, Simula research labs estimation seminar,
Henrik Kniberg Oslo, Norway, 2006
 How estimates are affected by
extra requirements
Spec 1 Spec 2 Spec 3
A A A
B B B
C C C
D D D
E E
4 hrs
4 hrs 8 hrs

Source: How to avoid impact from irrelevant and misleading info

on your cost estimates, Simula research labs estimation seminar,
Henrik Kniberg Oslo, Norway, 2006
 How estimates are affected by anchoring
Spec Same spec Same spec

456 hrs
500 hrs 50 hrs
Never mind me Never mind me

555 hrs 99 hrs

Source: How to avoid impact from irrelevant and misleading info

on your cost estimates, Simula research labs estimation seminar,
Henrik Kniberg Oslo, Norway, 2006
 Velocity
to know the future, you need to know the past When will we
get there?

Our steps
so far
We are
here

Henrik Kniberg
 Velocity-based release planning

Backlog

Henrik Kniberg
 Velocity-based release planning

Done!
Jan

Henrik Kniberg
 Velocity-based release planning

Done! Done!
Feb Jan

Henrik Kniberg
 Velocity-based release planning

Q2 forecast
Done! Done! Done!
None of Some of All of Mar Feb Jan
these these these

Henrik Kniberg
 Release burnup chart

Delivered
features

Henrik Kniberg
Date
 Fixed scope forecast

When will all of

this be done?

Delivered
features

Around week
27-30

Henrik Kniberg
Date
 Fixed time forecast

Some of
these

All of
these

Delivered What will be done

features by Christmas?

Date
Henrik Kniberg
 Fixed time & scope forecast
No. That is
Can we get unrealistic.
all of THIS
done...

Delivered
features

....by
Christmas?

Date
Henrik Kniberg
 Fixed time & scope forecast
No. That is
unrealistic.

We can get THIS ...and the rest done

much done by by February.
Delivered Christmas
features

Date
Henrik Kniberg
 Example: Measuring velocity by counting cards
Done!

Velocity per week

40

Henrik Kniberg
 Example: Release planning using a burnup chart
All of these
will be done

Total
# of Week
delivered Some of these
features will be done,
but not all

None of these
will be done 41 41

Henrik Kniberg
 Estimating

01:14
Henrik Kniberg
 Fact: Features have different sizes

Henrik Kniberg
 Option 1: Ignore the size difference.
It evens out over time.
Done!

Velocity per week

Henrik Kniberg
 Option 2: Estimate relative feature Size.

1 2 4 1 1

Week 1 Week 2 Week 3

Delivered
features

Delivered
Story points

Velocity: Velocity: Velocity:

5 story points 4 story points 4 story points

Henrik Kniberg Date

 Two different questions: Size & Time
1: What is weight of
each stone?
2 kg 4 kg
1 kg 1 kg 2: What is our
delivery capacity?

200 kg / hour

Henrik Kniberg
 Agile estimating strategy
•  Don’t estimate time.
•  Estimate relative size of features.
•  Measure velocity per sprint.
•  Derive release plan.
•  (Scrum rule) Estimates done by the people who are going to do the work.
•  Not by the people who want the work done.
•  Estimate & reestimate continuously during project
•  Don’t trust early estimates
•  Prefer verbal communication over detailed, written specifications.
•  Avoid false precision
•  Better to be roughly right
than precisely wrong

Henrik Kniberg
http://planningpoker.crisp.se
 Cost control without time reports

Mon Tue Wed Thu Fri Mon Tue Wed Thu Fri

Team size: 5 people Sprint length: 2 weeks

Average velocity:
10 story points per sprint
1 sprint = 200,000kr
(salary cost of 5 people for 2 weeks) Better to be Roughly Right
than Precisely Wrong

1 story point = 20,000kr
(200,000kr / 10 story points) Feature Size Cost Cost
Delete user 3 sp 15 60,000kr
1 story point = 5 mandays mandays
(50 mandays / 10 story points) PDF export 2 sp 10 40,000kr
mandays
Outlook 8 sp 40 160,000kr
integration mandays
Henrik Kniberg
 Value

01:05
Henrik Kniberg
 Features have different value
(and value is independent of size)

Weight: 1 gram Weight: 2000 grams

Value: 100 000 kr Value: 5 kr

Done
1:00
1:01
1:02
1:03
1:04
1:05
1:06
1:07
1:08
1:09
1:10
1:11
1:12
1:13
1:14
1:15
1:16
1:17
1:18
1:19
1:20
1:21
1:22
1:23
1:24
1:25
1:26
1:27
1:28
1:29
1:30
1:31
1:32
1:33
1:34
1:35
1:36
1:37
1:38
1:39
1:40
1:41
1:42
1:43
1:44
1:45
1:46
1:47
1:48
1:49
1:50
1:51
1:52
1:53
1:54
1:55
1:56
1:57
1:58
1:59
2:00
0:01
0:02
0:03
0:04
0:05
0:06
0:07
0:08
0:09
0:10
0:11
0:12
0:13
0:14
0:15
0:16
0:17
0:18
0:19
0:20
0:21
0:22
0:23
0:24
0:25
0:26
0:27
0:28
0:29
0:30
0:31
0:32
0:33
0:34
0:35
0:36
0:37
0:38
0:39
0:40
0:41
0:42
0:43
0:44
0:45
0:46
0:47
0:48
0:49
0:50
0:51
0:52
0:53
0:54
0:55
0:56
0:57
0:58
0:59
2 minute standup discussion (pair/trio):

•  Give a real-life example of a feature that is
small and very valuable
•  Give a real-life example of a feature that is
large and not very valuable.

Henrik Kniberg
 Maximize Value, not Output

Henrik Kniberg
 Less is More

Perfection is attained,
not when there is nothing more to add,
but when there is nothing left to take away

Antoine de Saint-Exupery

Henrik Kniberg
 Example: Google

Henrik Kniberg
 Google vs Yahoo

Value (billion $)
250
200
150
100
50
0
Google Yahoo

Henrik Kniberg
 Example: Apple
2008 2009 2010
2007
-  App Store -  Copy/Paste -  Multitasking
-  3G -  Search -  Video calls

Henrik Kniberg
 Example: Blocket

Henrik Kniberg
 Example: Dropbox

Henrik Kniberg
 Don’t give the team a Solution to Build
Build a
Bridge

OK

Henrik Kniberg
 We need to get to the
Give the team a Problem to Solve other village without
getting wet.

OK

? Options:
•  Bridge
•  Ferry
•  Tunnel
•  Move the
villages together

Henrik Kniberg
 As X
Always include the Why I want Y
so that Z

As online buyer
I want to save my shopping cart
so that I can continue shopping later

Henrik Kniberg
 Improving the Value Curve

Big Bang Big increments Small increments Highest value first

$ $ $ $ $$
$$$$

To Do Done

Henrik Kniberg
 Timeboxing
A B
Plan C D
(doomed to fail, but we don’t know it yet)
Week 1 Week 2 Week 3 Week 4

Big Bang scenario

”We will deliver ABCD in 4 weeks” Oops, we’re late. A B
C D
Scope

Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8

X Quality

X
Cost
X Time

Agile scenario
”We always deliver something every sprint (2 weeks)”
”We think we can finish ABCD in 4 weeks, but we aren’t sure”
A A B A B E
”We always deliver the most important items first”
Scope
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6

Quality

Cost Time Oops, our velocity is lower than we thought.

It looks like we’ll only finish AB by week 4.
What should we do now?
Henrik Kniberg
 Focus on Feedback!
Delivery frequency = Speed of learning

Stakeholders It is not the strongest

species that survive, nor
the most intelligent, but
the ones most responsive
Feedback to change.
Demos
and and
Requests Releases

Development team

Charles Darwin

Henrik Kniberg
 Business risk
Agile reduces risk Technical risk

Social risk Cost & schedule risk

Agile
Total
delivered Big
value Reduced Risk
Bang

Date
Henrik Kniberg
 Faster learning = Higher value
Value = Knowledge Value + Customer Value

Higher value
Agile

Total
delivered Big
value
Bang

Date
Henrik Kniberg
 The Development Team

00:49
Henrik Kniberg
 Resource optimization vs Time-to-market optimzation
Resource optimization Time-to-market optimization

Specialized tasks Specialists

Cross-functional team

C User needs

C D
D
S T

Henrik Kniberg
 Cross-functional teams
User

are vertical Client

Client team
Server
DB
C C C

Server team
Feature team 1 Feature team 2

S S S
C
C
DB team
C
S
S S
D D D
D D
D
Test team
T
T T
T T T Communities
of interest
Henrik Kniberg
 Spotify

Tribe Tribe Tribe

Tribe Tribe Tribe

Henrik Kniberg
Spotify
Tribe Tribe

PO PO PO PO PO PO PO PO

Tribe lead Tribe lead

Chapter Chapter

Chapter
Guild
Chapter
 Cultivating a Great Team

•  Colocated Big team working hard

•  Small (3-7 ppl)
•  Self-organizing
•  Cross-functional
•  Clear mission & product owner
•  Empowered to deliver
•  Direct contact with users & stakeholders
•  Focused. No multitasking.
•  Transparent
Small team working smart

Henrik Kniberg
 Multiple teams working together
Continuous
Team integration
backlogs
Product Weekly release train
backlog

Week 3 Week 2 Week 1

v1.2 v1.1 v1.0

Henrik Kniberg
 Release = Drama!
Releasing must be REALLY easy
Release!

Req Code Test

Release = Routine

Henrik Kniberg
 Why we get stuck in Big Bang thinking

Releasing is Releasing is
expensive & risky cheap & safe

Release Release
seldom often

Henrik Kniberg
 The team balances long-term and short-term work

Mon Tue Wed Thu Fri Mon Tue Wed Thu Fri

Feature
development Bug fix Architecture

Manual testing Test automation

Meetings
Prototyping Infrastructure

Short term focus Long term focus

Henrik Kniberg
 The team Limits work to capacity
... and knows how to say No
Our capacity is
Which 5 shall we
about 5 features
do next?
per sprint

sprint 3 sprint 2 sprint 1

We CAN do
more if we
sacrifice But we
quality don’t.

Henrik Kniberg
 The team continuously experiments
and gradually improves it’s way of working
•  Driven from the bottom
•  Supported from the top

Velocity
Quality
Motivation
Effectiveness
Speed
Value
... etc ...

Henrik Kniberg
 Example

00:33
Henrik Kniberg
Before
Design-ready games Production-ready games
Game backlog
15 12
8

Concept Resource Graphics Sound Integr. &

Dev
pres. planning design design deploy
1m 6m 1w 6m 6m
4h 1d 1m 3w 3m 3w
(1m+2m)
3 m value added time Process
= 12% cycle
25 m cycle time efficiency
Before
Design-ready games Production-ready games
Game backlog
15 12
8

Concept Resource Graphics Sound Integr. &

Dev
pres. planning design design deploy
1m 6m 1w 6m 6m
4h 1d 1m 3w 3m 3w
(1m+2m)
3 m value added time Process
= 12% cycle
25 m cycle time efficiency

After Game team

(graphics, sound, dev,
integrate)
Cross-functional game team

3-4 months

7 times
faster!
 Cross-functional teams
We’re slow!
I’m fast! 6 months

Joe Dave Lisa Release

3 months

We’re alot faster!

Joe
I’m a bit
Dave slower

Lisa Release

January February March April May June July

81

Henrik Kniberg
 Portfolio-level board
Next Develop Release Done
1 3 2
Concept Playable Features Polish
Game
Pac
Team
man Bingo
Solitaire 1
Game Zork Mine
Team Pong sweeper
2
Dugout
Game
Team
Donkey Duck
Kong hunt
3
FLOW Avg lead time: 12 weeks
Game
teams

Game team 1 Game team 2 Game team 2

Current game: Pac Man Current game: Pong Current game: Donkey Kong
Not Not Not
checked  out Done!  :o) SPRINT  GOAL:  Beta-­‐ready  release!
checked  out checked  out
checked  out checked  out Done!  :o) SPRINT  GOAL:  Beta-­‐ready  release!
checked  out Done!  :o) SPRINT  GOAL:  Beta-­‐ready  release!
Deposit
Write
failing
Burndown Deposit
Write
Deposit
Write
2d
test

DAO
failing

2d
test Burndown failing

2d
test Burndown
Code Integr DAO DAO
cleanup DB
test Code Code
2d 0.5d design Integr Integr
1d cleanup DB cleanup DB
2d test test
1d 2d 0.5d design 2d 0.5d design
1d 2d 1d 2d
1d 1d
GUI Write

Migrat ion   spec failing

GUI Write GUI Write

Migrat ion   Migrat ion  

2d 2d test
1d 3d spec failing spec failing

tool Tapest
spike
ry 2d 2d test
1d 3d
2d 2d test
1d 3d

Impl.
migration
1d
2d
tool Tapest
spike
ry tool Tapest
spike
ry

Impl. 1d Impl. 1d
8d 2d 2d
migration migration
8d 8d

Backoffice Write
failing
test
Backoffice Write
Backoffice Write

Unplanned  items Next

failing failing
Login Impl 2d
test test

Integr.
with
GUI
1d
Login
Integr.
Impl
GUI
2d
Unplanned  items Next Login
Integr.
Impl
GUI
2d
Unplanned  items Next
JBoss 1d 1d
2d with with
Fix mem
ory Withdraw
Perf  test
JBoss
2d
JBoss
2d

Backoffice
Write
failing
Write
2d
failing
leak
(JIRA
125)
Sales support
Withdraw Write
Fix mem
leak
ory
Sales support
Withdraw
Perf  test Write
Fix mem
leak
ory
Sales support
Withdraw
Perf  test
test
3d test 3d Write
Backoffice failing
test
Write
2d
(JIRA
failing 125) Withdraw Backoffice failing
test
Write
2d
(JIRA
failing 125) Withdraw
User  admin whitepaper
3d test 3d Write 3d test 3d Write

GUI Clarify
4d
User  admin whitepaper

4d
User  admin whitepaper

4d
design Impl
require- GUI GUI
(CSS) GUI Clarify Clarify
ments design Impl design Impl
1d 2d require- require-
6d (CSS) GUI (CSS) GUI
ments ments
1d 2d 1d 2d
6d 6d
 Succeeding with
software development

00:22
Henrik Kniberg
 10,000 person-years of experience

Communication!
Especially between
Developers and Users

Henrik Kniberg
 What have we learned? Top 5 reasons for success
1.  User involvement
2.  Executive management support
IT project success rate 1994: 15%
3.  Clear business objectives
Average cost & time overrun: 170%
4.  Optimizing scope Scope
IT project success rate 2004: 34% 5.  Agile process
Average cost & time overrun: 70%
Cost Time
“The primary reason [for the improvement]
is that projects have gotten a lot smaller.”

“Doing projects with iterative processes as opposed to the

waterfall method, which called for all project requirements
Jim Johnson
Chairman of
to be defined up front, is a major step forward.”
Standish Group

Sources:
http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish
http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS
86 book
”My Life is Failure”, Jim Johnson’s

Henrik Kniberg
 Minimize distance between Maker and User
People
(# of handoffs) 2 3
1

Maker User

Time
(feedback delay)

Henrik Kniberg
 Minimize distance between Maker and User
People
(# of handoffs)
2 3
1
Maker User
5

4
People 3
(# of
handoffs) 2
1 Time
(Feedback delay)
0

Done
1:00
1:01
1:02
1:03
1:04
1:05
1:06
1:07
1:08
1:09
1:10
1:11
1:12
1:13
1:14
1:15
1:16
1:17
1:18
1:19
1:20
1:21
1:22
1:23
1:24
1:25
1:26
1:27
1:28
1:29
1:30
1:31
1:32
1:33
1:34
1:35
1:36
1:37
1:38
1:39
1:40
1:41
1:42
1:43
1:44
1:45
1:46
1:47
1:48
1:49
1:50
1:51
1:52
1:53
1:54
1:55
1:56
1:57
1:58
1:59
2:00
0:01
0:02
0:03
0:04
0:05
0:06
0:07
0:08
0:09
0:10
0:11
0:12
0:13
0:14
0:15
0:16
0:17
0:18
0:19
0:20
0:21
0:22
0:23
0:24
0:25
0:26
0:27
0:28
0:29
0:30
0:31
0:32
0:33
0:34
0:35
0:36
0:37
0:38
0:39
0:40
0:41
0:42
0:43
0:44
0:45
0:46
0:47
0:48
0:49
0:50
0:51
0:52
0:53
0:54
0:55
0:56
0:57
0:58
0:59
minutes hours days weeks months years

Time (Feedback delay)

2 minute standup discussion (pair/trio):

•  Think of any ongoing project
•  What is the distance between Developer & User?
•  What can YOU do to reduce the distance?

Henrik Kniberg
 Final points

00:17
Henrik Kniberg
 Avoid Big-Bang
The price of agile transformation!
(there is no such thing as a free lunch....)
Do it gradually.

•  Infrastructure Investments
(release automation, test automation, etc)
•  Reorganization
(new roles, cross-functional teams, etc)
•  New skills
(Vertical story-slicing, retrospectives, agile architecture, etc)
•  New habits
(Frequent customer interaction, frequent release, less specialization)
•  Transparancy
(problems and uncertainty painfully visible rather than hidden)

Henrik Kniberg
 Big is Bad!
Break it down!
•  Big project => Several small projects
•  Big feature => Several small features
•  Big team => Several small teams
•  Big transformation => Several small transformations

Henrik Kniberg
 Agile is...

Early delivery of business value

Less bureaucracy

Henrik Kniberg (Thanks Alistair Cockburn for this simplified definition of Agile)
 ...gradually...
3 concrete changes

1.  Make Real Teams

•  small, cross-functional, self-organizing, colocated
2.  Deliver Often
•  internally every 3 weeks at most
•  externally every quarter at most
3.  Involve Real Users
•  direct and fast feedback between the team and the users

Henrik Kniberg
Agile is a direction, not a place
The important thing is not your process.
The important thing is
your process for improving your process

1.  Make Real Teams

•  small, cross-functional, self-organizing, colocated
2.  Deliver Often
•  internally every 3 weeks at most
•  externally every quarter at most
3.  Involve Real Users
•  direct and fast feedback between the team and the users

Henrik Kniberg