overcoming waterfallacies & agilephobias

Transitioning to Agile: Overcoming Waterfallaciesand Agilephobias

Mike CohnMay 15, 2007

1

© Mountain Goat Software, LLC

1. Why transitioning to agile is hard2. A framework for transitioning3. Overcoming waterfallacies and

agilephobias

Topics today...

2


Why Transitioning

to Agile Is Hard

3


Three reasons1

Change is not top-down or bottom-up; it’s both

3The transition process must be congruent with the development process

2We fall into the predictability trap

4


Top down or bottom up?Two simplistic views of transitioning to agile:

Top downPowerful 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 organizationsBehavior 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 Wheatleyin Leadership and the New Science

7


What we do on projectsOn projects we learn we cannot precisely anticipate:

our users’ requirementshow long it will take to develop a feature or entire systemwhich design will be bestthe set of tasks necessary to develop a feature

So we devise alternative approachesRather 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 Frameworkfor

Transitioning

10


An agile process

Cancel

Gift wrap

Return

Iteration2-4 weeks

Return

Iteration goal

Iteration backlog

Potentially shippableproduct increment

Productbacklog

Gift wrap

Coupons

Cancel

Daily

...

...

...

Transitionbacklog

...

Iterationmonthly

Weekly

Alteredorganization

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

Transitionbacklog

Weekly

Discuss progressRemove 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


OvercomingWaterfallacies

14


Waterfallacynoun.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 dateIt’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 lyingIf we acknowledge the impossibility of guaranteeing functionality and date

17


Knowing the scope and dateIt’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 exampleDesired

release date 30 June

Today’s Date 1 January

Number of sprints 6 (monthly)

Lowvelocity 15

Highvelocity 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 contractBut you’ll probably make money if you do

If you write a contractfor just the will haves:

You will likely win the contractBut probably not make money on it

If you write a contract thatincludes the might haves:

It’s a risk issue

Where do you want to be?

21


Fixed-scope planning: an exampleTotal story points desired 120

Low velocity 15

High velocity 20

120÷20=

120÷15=

22

Fixed-scope contracting

You’ll likely win the contractBut may not make any money

If you write a contractfor the short duration:

You probably won’t win the contractBut will make money if you

If you write a contractfor 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 bulletDoesn’t solve a single problem you have, only exposes the problems you do haveHopefully exposes these problems to those who can solve themBy repeatedly solving the problems you identify, things improveAgile 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

outWhy 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 specialistsbioinformatics, 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 onContainer (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 agileWe 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

Agilephobianoun.strong fear or dislike of agile, usually due to the uncertainty of change

35


More agilephobiasI’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 agilephobiasBeing 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 [email protected]

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 process1

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.

2All new features come with automated tests.

3Everything (maybe, we hope) has an automated test.

41


200

300

400

500

1 2 3 4 5 6 7

Months (Iterations)

Hou

rs o

f Man

ual T

estin

g

42


Mike Cohn contact [email protected]

www.mountaingoatsoftware.com

(303) 810-2190 (mobile)

43

overcoming waterfallacies & agilephobias

Business

mountain goat

projectthe

risk issuewhere

means ill

llcagile requires

waterfall

face communication

people