What is Agile?
Consultant
www.crisp.se
August 20, 2013
Henrik Kniberg
Father
[email protected]
@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:
(screenshot from my computer)
How the font shows up on your computer:
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
Henrik Kniberg
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
things fit.
Agile is...
Why?
How?
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
Longer project
More likely to
get interrupted
Henrik Kniberg
More scope
creep
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
Henrik Kniberg
Sources:
http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish
http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS
We tend to build the wrong thing
Features and functions used in a typical system
Never
45%
Always
7%
Often
13%
Sometimes
16%
Cost
Half of the
stuff we build
is never used!
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
Henrik Kniberg
01:39
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
Henrik Kniberg
01:36
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
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
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
through early and continuous delivery of valuable
software. Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage. Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale. Business people and developers must work
together daily throughout the project. Build projects around motivated individuals. Give
them the environment and support they need, and
trust them to get the job done. The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation. • 
• 
• 
• 
• 
• 
Working software is the primary measure of
progress. Agile processes promote sustainable
development. The sponsors, developers, and
users should be able to maintain a constant
pace indefinitely. Continuous attention to technical excellence
and good design enhances agility. Simplicity--the art of maximizing the amount of
work not done--is essential. The best architectures, requirements, and
designs emerge from self-organizing teams. At regular intervals, the team reflects on how
to become more effective, then tunes and
adjusts its behavior accordingly. Agile ”umbrella” –
a family of iterative, incremental methods
Scrum
Kanban
XP
DSDM
FDD
Crystal
Sources:
3rd Annual ”State of Agile Development” Survey June-July 2008
• 
3061 respondents
• 
80 countries
Iterative & Incremental
Henrik Kniberg
01:32
Agile = Iterative + Incremental
Don’t try to get it all right
from the beginning
cost
RISK
Henrik Kniberg
Don’t build it all at once
value
cost
value
Not ”horizontal” increments
value
1
Henrik Kniberg
2
Client
3
Server
2
DB
1
3
4
”Vertical” increments!
Client
value
1
2
3
Server
DB
1
Henrik Kniberg
2
3
4
5
Keep iterations short
(2-3 weeks)
Short iteration
Less likely to
get interrupted
Henrik Kniberg
Less scope
creep
Planning is easier with frequent releases
Henrik Kniberg
Planning
Henrik Kniberg
01:26
Face it.
Estimates are almost always Wrong!
Henrik Kniberg
How estimates are affected by specification
length
Same spec – more pages
Spec
117 hrs
Henrik Kniberg
173 hrs
Source: How to avoid impact from irrelevant and misleading info
on your cost estimates, Simula research labs estimation seminar,
Oslo, Norway, 2006
How estimates are affected by
irrelevant information
Spec 1
Same spec
+ irrelevant details
A
B
A
C
B
C
20 hrs
39 hrs
Henrik Kniberg
Source: How to avoid impact from irrelevant and misleading info
on your cost estimates, Simula research labs estimation seminar,
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
Henrik Kniberg
4 hrs
8 hrs
Source: How to avoid impact from irrelevant and misleading info
on your cost estimates, Simula research labs estimation seminar,
Oslo, Norway, 2006
How estimates are affected by anchoring
Spec
Same spec
456 hrs
Same spec
500 hrs
Never mind me
555 hrs
Henrik Kniberg
50 hrs
Never mind me
99 hrs
Source: How to avoid impact from irrelevant and misleading info
on your cost estimates, Simula research labs estimation seminar,
Oslo, Norway, 2006
Velocity
to know the future, you need to know the past
Our steps
so far
Henrik Kniberg
We are
here
When will we
get there?
Velocity-based release planning
Backlog
Henrik Kniberg
Velocity-based release planning
Done!
Jan
Henrik Kniberg
Velocity-based release planning
Done!
Feb
Henrik Kniberg
Done!
Jan
Velocity-based release planning
Q2 forecast
None of
these
Henrik Kniberg
Some of
these
All of
these
Done! Done!
Mar
Feb
Done!
Jan
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
features
Henrik Kniberg
What will be done
by Christmas?
Date
Fixed time & scope forecast
Can we get
all of THIS
done...
No. That is
unrealistic.
Delivered
features
....by
Christmas?
Henrik Kniberg
Date
Fixed time & scope forecast
Delivered
features
Henrik Kniberg
We can get THIS
much done by
Christmas
Date
No. That is
unrealistic.
...and the rest done
by February.
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 delivered
features
Week
Some of these
will be done,
but not all
None of these
will be done41
Henrik Kniberg
41
Estimating
Henrik Kniberg
01:14
Fact: Features have different sizes
Henrik Kniberg
Option 1: Ignore the size difference.
It evens out over time.
Velocity per week
Henrik Kniberg
Done!
Option 2: Estimate relative feature Size.
1 2
Week 1
4
1
Week 2
1
Week 3
Delivered
features
Delivered Story points
Velocity:
5 story points
Henrik Kniberg
Velocity:
4 story points
Velocity:
4 story points
Date
Two different questions: Size & Time
2 kg
1 kg
4 kg
1 kg
1: What is weight of
each stone?
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
http://planningpoker.crisp.se
Henrik
Kniberg
Cost control without time reports
Mon Tue Wed Thu Fri
Team size: 5 people
Mon Tue Wed Thu Fri
Sprint length: 2 weeks
1 sprint = 200,000kr
(salary cost of 5 people for 2 weeks)
1 story point = 20,000kr (200,000kr / 10 story points) Feature
1 story point = 5 mandays
(50 mandays / 10 story points)
Henrik Kniberg
Average velocity:
10 story points per sprint
Better to be Roughly Right
than Precisely Wrong
Size
Cost
Cost
Delete user
3 sp
15
60,000kr
mandays
PDF export
2 sp
10
40,000kr
mandays
Outlook
integration
8 sp
40
160,000kr
mandays
Value
Henrik Kniberg
01:05
Features have different value
(and value is independent of size)
Weight: 1 gram
Value: 100 000 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
Weight: 2000 grams
Value: 5 kr
2 minute standup discussion (pair/trio):
Henrik Kniberg
•  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.
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
250
Value (billion $) 200
150
100
50
0
Henrik Kniberg
Google
Yahoo
Example: Apple
2007
Henrik Kniberg
2008
-  App Store
-  3G
2009
-  Copy/Paste
-  Search
2010
-  Multitasking -  Video calls
Example: Blocket
Henrik Kniberg
Example: Dropbox
Henrik Kniberg
Don’t give the team a Solution to Build
Build a
Bridge
OK
Henrik Kniberg
Give the team a Problem to Solve
We need to get to the
other village without
getting wet.
OK
?
Henrik Kniberg
Options:
•  Bridge
•  Ferry
•  Tunnel
•  Move the
villages together
Always include the Why
As X
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 increments
Big Bang
$
$
$ $$$
To Do
Henrik Kniberg
Small increments
Highest value first
$$$$
Done
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
Oops, we’re late.
”We will deliver ABCD in 4 weeks”
Scope
X
X
X
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8
Quality
Cost
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
”We always deliver the most important items first”
Scope
A B
A B E
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6
Quality
Cost
Time
Henrik Kniberg
Oops, our velocity is lower than we thought. It looks like we’ll only finish AB by week 4.
What should we do now?
A B
C D
Focus on Feedback!
Delivery frequency = Speed of learning
Stakeholders
Feedback
and
Requests
Demos
and
Releases
It is not the strongest
species that survive, nor
the most intelligent, but
the ones most responsive
to change.
Development team
Charles Darwin
Henrik Kniberg
Business risk
Agile reduces risk
Social risk
Technical risk
Cost & schedule risk
Agile
Total
delivered
value
Reduced Risk
Date
Henrik Kniberg
Big
Bang
Faster learning = Higher value
Value = Knowledge Value + Customer Value
Higher value
Agile
Total
delivered
value
Big
Bang
Date
Henrik Kniberg
The Development Team
Henrik Kniberg
00:49
Resource optimization vs Time-to-market optimzation
Resource optimization
Specialized tasks
Specialists
C
D
S
T
Henrik Kniberg
Time-to-market optimization
Cross-functional team
User needs
C
D
S
T
Cross-functional teams
are vertical
Client team
C
C C
S
Test team
Henrik Kniberg
Feature team 1
C
D D D
T
DB
S
DB team
T
Client
Server
Server team
S
User
T
Feature team 2
C
C
D
T
S
S
D
T
Communities
of interest
S
D
T
Spotify
Tribe
Tribe
Henrik Kniberg
Tribe
Tribe
Tribe
Tribe
Spotify
Tribe
PO
PO
PO
Tribe
PO
PO
Tribe lead
Tribe lead
Chapter
Chapter
Chapter
Guild
Chapter
PO
PO
PO
Cultivating a Great Team
• 
• 
• 
• 
• 
• 
• 
• 
• 
Big team working hard
Colocated
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
Product
backlog
Team
backlogs
Continuous
integration
Weekly release train
Week 3
v1.2
Henrik Kniberg
Week 2
v1.1
Week 1
v1.0
Releasing must be REALLY easy
Release = Drama!
Release!
Req
Code
Test
Release = Routine
Henrik Kniberg
Why we get stuck in Big Bang thinking
Releasing is
expensive & risky
Releasing is
cheap & safe
Release
seldom
Release
often
Henrik Kniberg
The team balances long-term and short-term work
Mon Tue Wed Thu Fri
Feature
development
Mon Tue Wed Thu Fri
Bug fix
Manual testing
Meetings
Prototyping
Short term focus
Henrik Kniberg
Architecture
Test automation
Infrastructure
Long term focus
The team Limits work to capacity
... and knows how to say No
Our capacity is
about 5 features
per sprint
We CAN do
more if we
sacrifice
quality Henrik Kniberg
Which 5 shall we
do next?
sprint 3
But we
don’t.
sprint 2
sprint 1
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
Henrik Kniberg
00:33
Before
Design-ready games
Game backlog
15
8
1m
Concept
pres.
4h
3 m value added time
25 m cycle time
6m
Resource
planning
1d
Process
= 12% cycle
efficiency
1w
Graphics
design
Sound
design
1m
3w
Production-ready games
12
Dev
6m
6m
3m
(1m+2m)
Integr. &
deploy
3w
Before
Design-ready games
Game backlog
15
8
1m
Concept
pres.
4h
3 m value added time
25 m cycle time
6m
Resource
planning
1d
1w
Graphics
design
Sound
design
1m
3w
Process
= 12% cycle
efficiency
After
Cross-functional game team
Production-ready games
Game team
(graphics, sound, dev,
integrate)
3-4 months
7 times
faster!
12
Dev
6m
6m
3m
(1m+2m)
Integr. &
deploy
3w
Cross-functional teams
I’m fast!
We’re slow!
6 months
Joe
Dave
Lisa
Release
3 months
We’re alot faster!
Joe
I’m a bit
slower
Dave
Lisa
January
February
Release
March
April
May
June
81
Henrik Kniberg
July
Portfolio-level board
Develop
3
Next
1
Concept Playable
Features
Game
Team
Solitaire
Pac
man
1
Game
Team
2
Donkey
Kong
3
Avg lead time:
Bingo
Zork
Pong
Game
Team
FLOW
Polish
Release Done
2
12
weeks
Mine
sweeper
Dugout
Duck
hunt
Game
teams
Game team 1
Current game: Pac Man
Not
checked out
checked out
Done! :o)
Deposit
SPRINT GOAL: Beta-‐ready release!
Write
failing
test
2d
Burndown
Game team 2
Current game: Pong
Not
checked out
checked out
Deposit
DAO
Code
cleanup
1d
GUI
spec
2d
Migrat ion tool
Tapest
ry
spike
1d
Impl.
migration
8d
Backoffice
Login
Integr.
with
JBoss
2d
Write
failing
test
Backoffice
User admin
GUI
design
(CSS)
1d
2d
Impl
GUI
Clarify
requirements
2d
1d
Write
failing
test
3d
Integr
test
2d 0.5d
6d
SPRINT GOAL: Beta-‐ready release!
Write
failing
test
2d
Current game: Donkey Kong
Not
checked out
checked out
Done! :o)
Deposit
Burndown
DAO
DB
design
2d
1d
Code
cleanup
1d
Write
failing
2d test
3d
1d
GUI
spec
2d
Migrat ion tool
2d
Tapest
ry
spike
1d
Impl.
migration
8d
Unplanned items
Fix mem
ory
leak
Write
(JIRA
125)
2d
failing
test
Sales support
3d
Write
whitepaper
4d
Impl
GUI
Done! :o)
Game team 2
Next
Withdraw
st
Perf te
W
ithdraw
Backoffice
Login
Integr.
with
JBoss
2d
Write
failing
test
Backoffice
User admin
GUI
design
(CSS)
1d
2d
Impl
GUI
Clarify
requirements
2d
1d
Write
failing
test
3d
Integr
test
2d 0.5d
6d
Burndown
DAO
Code
cleanup
DB
design
2d
1d
1d
Write
failing
2d test
3d
1d
GUI
spec
2d
Migrat ion tool
Tapest
ry
spike
1d
Impl.
migration
8d
2d
Unplanned items
Fix mem
ory
leak
Write
(JIRA
125)
2d
failing
test
Sales support
3d
Write
whitepaper
4d
Impl
GUI
SPRINT GOAL: Beta-‐ready release!
Write
failing
test
2d
Next
Withdraw
st
Perf te
W
ithdraw
Backoffice
Login
Integr.
with
JBoss
2d
Write
failing
test
Backoffice
User admin
GUI
design
(CSS)
1d
2d
Impl
GUI
Clarify
requirements
2d
1d
Write
failing
test
3d
Integr
test
2d 0.5d
DB
design
2d
1d
Write
failing
2d test
3d
1d
2d
Unplanned items
Fix mem
ory
leak
Write
(JIRA
125)
2d
failing
test
Sales support
3d
Write
whitepaper
4d
Impl
GUI
6d
Next
Withdraw
st
Perf te
W
ithdraw
Succeeding with
software development
Henrik Kniberg
00:22
10,000 person-years of experience
Communication!
Especially between
Developers and Users
Henrik Kniberg
What have we learned?
Top 5 reasons for success
IT project success rate 1994: 15%
Average cost & time overrun: 170%
IT project success rate 2004: 34%
Average cost & time overrun: 70%
1.  User involvement
2.  Executive management support
3.  Clear business objectives
4.  Optimizing scope Scope
5.  Agile process
“The primary reason [for the improvement]
is that projects have gotten a lot smaller.”
Jim Johnson
Chairman of
Standish Group
Cost
Time
“Doing projects with iterative processes as opposed to the
waterfall method, which called for all project requirements
to be defined up front, is a major step forward.”
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
1
People
(# of handoffs)
2
Maker
User
Time
(feedback delay)
Henrik Kniberg
3
Minimize distance between Maker and User
Maker
5
People
(# of
handoffs)
People
(# of handoffs)
2
1
3
4
3
2
1
Time
(Feedback delay)
0
minutes hours days weeks months years
Time (Feedback delay)
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):
Henrik Kniberg
•  Think of any ongoing project
•  What is the distance between Developer & User?
•  What can YOU do to reduce the distance?
User
Final points
Henrik Kniberg
00:17
The price of agile
(there is no such thing as a free lunch....)
Avoid Big-Bang
transformation!
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)
3 concrete changes
...gradually...
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