Overcoming Waterfallacies & Agilephobias

Transitioning to Agile:
Overcoming Waterfallacies
and Agilephobias
Mike Cohn
May 15, 2007
1

© Mountain Goat Software, LLC
1. Why transitioning to agile is hard
2. A framework for transitioning
3. Overcoming waterfallacies and
agilephobias
Topics today...
2

Why Transitioning
to Agile
Is Hard
3

Three reasons
1
Change is not top-down or
bottom-up; it’s both
3
The transition process must
be congruent with the
development process
2 We fall into the predictability
trap
4

Top down or bottom up?
Two simplistic views of transitioning to agile:
Top down
Powerful leader shares a vision
Bottom-up
new approach
But, transitioning to agile is neither top-down
nor bottom-up
It’s everywhere, all together, all-at-once
1
5

How we traditionally view our organizations
Behavior is highly predictable
Once set in motion, will continue in motion
Predictable
An organization change strategy can be
mapped out:
And we’ll end up right where I predict
Dispense with predictability2
6

“This machine imagery [Newtonian view]
leads to the belief that studying the parts is
the key to understanding the whole.Things
are taken apart, dissected literally or
is that the more we know about the
workings of each piece, the more we will
learn about the whole.”
~Margaret Wheatley
in Leadership and the New Science
7

What we do on projects
On projects we learn we cannot precisely anticipate:
our users’ requirements
how long it will take to develop a feature or entire system
which design will be best
the set of tasks necessary to develop a feature
So we devise alternative approaches
Rather than ask for upfront specs, we deliver partial
solutions, solicit feedback, and repeat
Rather than design the whole system, we design
incrementally and adjust based on what we learn
We need to do the same for the transition effort
8

Use a congruent approach3
Part of the move to
agile is a move to
self-organizing teams
Moving to self-
organization requires
self-organization
“You will self-organize!”
9

A Framework
for
Transitioning
10

An agile process
Cancel
Gift wrap
Return
Iteration
2-4 weeks
Return
Iteration goal
Iteration
backlog
Potentially shippable
product increment
Product
backlog
Gift wrap
Coupons
Cancel
Daily
...
...
...
Transition
backlog
...
Iteration
monthly
Weekly
Altered
organization
An agile transition process
11

Activities
to support
the goals
Quarterly Monthly
3-4 goals
Decide how pervasive to go
with agile—development
only or full company
All
Identify which issues agile
can solve or help with.
DF
Transition
backlog
Weekly
Discuss
progress
Remove
impediments
Meet weekly to execute,
monthly to plan,
quarterly to strategize
12

Treat the transition as a project
Establish an “Agile Transition Team” (“Agile
Adoption Team,” etc.)
Who?
Sponsor—senior person responsible for success
Area managers or leads who can make it happen
Meet weekly
Run monthly iterations managing work from a
Transition Backlog
Run a quarterly cycle like the release cycle on an agile
project
13

Overcoming
Waterfallacies
14

Waterfallacy
noun.
mistaken belief or idea about agile that
stems from prolonged exposure to
waterfall projects
15

and a commitment to what will
be in the product.
1
Is the answer just to under-
commit and then deliver more
than expected?
16

Knowing the scope and date
It’s always been impossible to know both the scope
and the date of a project
The vast majority of waterfall projects get this wrong, too
so by either padding or lying
If we acknowledge the impossibility of guaranteeing
functionality and date
17

Knowing the scope and date
It’s always been impossible to know both the
scope and the date of a project
The vast majority of waterfall projects get this
wrong, too
And then end up delivering too little of the wrong
functionality
both do so by either padding or lying
18

1. acknowledge the impossibility of guaranteeing
functionality and date
2.
risk management
If we...
And use the same principles on non-contracted
projects that have a similar need for a low risk of
dropped scope or schedule overrun
Then we...
19

Fixed-date planning: an example
Desired
release date
30 June
Today’s Date 1 January
Number of
sprints
6 (monthly)
Low
velocity
15
High
velocity
20
6×15
6×20
Will have
Might have
Won’t have
20

Fixed-date contracting
6×15
6×20
Will have
Might have
Won’t have
You won’t likely win the contract
But you’ll probably make money
if you do
If you write a contract
for just the will haves:
You will likely win the contract
But probably not make money
on it
If you write a contract that
includes the might haves:
It’s a risk issue
Where do you want to be?
21

Fixed-scope planning: an example
Total story points desired 120
Low velocity 15
High velocity 20
120÷20=
120÷15=
22

Fixed-scope contracting
You’ll likely win the contract
But may not make any money
for the short duration:
You probably won’t win the
contract
But will make money if you
for the long duration:
It’s a risk issue
Where do you want to be?
23

The value of customer feedback
projects harder
Because it acknowledges
the importance of customer feedback
and the existence of emergent requirements
Sequential processes treat these as changes of
scope
24

Agile requires our testers to be
involved and testing right from
the start. But they’re tied up on
other projects.
2
We can’t move to agile because
we can’t move testers from
these other projects.
25

Agile is not a silver bullet
Doesn’t solve a single problem you have, only
exposes the problems you do have
Hopefully exposes these problems to those
who can solve them
By repeatedly solving the problems you
identify, things improve
Agile is hard work
There will be days you wonder why you’re doing
this
26

Digging out of this problem
do so
Perhaps just enough to move some small number of testers
(1?) to the new project
Have the new project run cross-functionally
Whole team does whatever it takes to pay off the testing
debt
Rule from day one: On new projects don’t allow any
new debt to build up
27

Agile requires everyone to be
a generalist.
3
That isn’t cost-effective and
doesn’t make sense for my
project. Some of what we do
is highly specialized.
28

Everyone must be a generalist
out
Why can’t we?
Not everyone needs to be a generalist
people;“generalizing specialists”
This happens naturally on most agile teams because
of their cross-functional composition
Some domains require specialists
bioinformatics, video game development, etc.
29

We work in distributed
environment, frequently with
some team members in India,
China, or the Ukraine. Self-
organization seems to clash
with some cultures.
4
How will agile development
work in these environments?
30

Self-organization around the world
I suspect it’s true that that self-organizing teams in
the different countries will organize differently
organization
Self-organization relies on
Container (in which to organize)
Differences (among people)
Transforming Exchanges
Self-organization leads to more creativity, ownership,
productivity, engagement
31

Agile relies primarily on face-
to-face communication. Our
projects are distributed across
many time zones.And many
people choose to work from
home.
5
How does this work with
agile?
32

Multi-site agile
We rarely choose to highly distribute a project for
We do it for cost or because of mergers and similar
reasons
Working from home is detrimental to the short-
term progress of the project
But may be necessary for the long-term success (e.g.,
it’s a recruiting tool)
Experiment: Is it better to all be at home one day per
week or all on different days?
33

Encourage face-to-face communication
Do whatever you can to have as much face-to-
face communication as possible
Videoconference > phone > email
Fly people together at the start of the project
Send three people from one to the other
Get people together for iteration planning
meetings and reviews
34

I’m afraid I’ll have nothing to do
I’m afraid I’l lose my job
I’m afraid people will see how little I actually do
I’m afraid I won't be able to keep up
I’m afraid I won’t be able to learn the new software
I’m afraid this will mean hard work
Agilephobia
noun.
strong fear or dislike of agile, usually due to
the uncertainty of change
35

More agilephobias
I’m afraid I won’t get raises or promotions anymore
Drat! There go my 3-hour lunches
Drat! This means I can’t mosey in at 10:30 anymore
Drat! This means I’ll have to actually think now
Drat! This means I’ll actually have to talk to people now
It’s just so much easier and safer when someone else tells me
exactly what to do
Its just so much easier and safer when I can tell them exactly
what I want them to do
36

Overcoming agilephobias
Being aware of what people fear is half the
challenge
Acknowledge these agilephobias and over time
work to have solutions for them
Over time people will lose their fear of losing
their job
But will likely still need revised job descriptions in
an agile enterprise
37

Mike Cohn contact info
mike@mountaingoatsoftware.com
www.mountaingoatsoftware.com
(303) 810-2190 (mobile)
38

Agile puts a lot of emphasis
on unit testing. I’m not
working on a legacy
application (yet!) but we are
nine-months in and haven’t
made automated testing a
priority.
6
Can we still be agile?
39

Agile without a lot of tests in place
Two most important principles of agile:
1. Inspect and Adapt
2. Iterate
Start where you are, do something, see
how you did
And then do it again until you get to
where you want to be
40

A three-step process
1
We end this iteration with less manual testing than
we started.
Go after the “low-hanging fruit” by automating
some easy-to-automate tests of great value.
2
All new features come with automated tests.
3
Everything (maybe, we hope) has an automated
test.
41

200
300
400
500
1 2 3 4 5 6 7
Months (Iterations)
HoursofManualTesting
42

Mike Cohn contact info
mike@mountaingoatsoftware.com
www.mountaingoatsoftware.com
(303) 810-2190 (mobile)
43

Overcoming Waterfallacies & Agilephobias

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Overcoming Waterfallacies & Agilephobias

Semelhante a Overcoming Waterfallacies & Agilephobias (20)

Mais de Mike Cohn

Mais de Mike Cohn (9)

Último

Último (20)

Overcoming Waterfallacies & Agilephobias