72
Failing with Agile: A How-to Guide Don’t end up with an apple instead of an Apple®! Presentation Copyright © 2008, Agile For All, LLC. All rights reserved. Presented by Bob Hartman President, Agile For All 303-766-0917 [email protected] www.agileforall.com

Failing With Agile

Embed Size (px)

DESCRIPTION

Presentation for Mile High PMI Workshop on November 15, 2008 Abstract: There are always people who want agile projects to fail. This will probably be the case until agile is the preferred process methodology used for projects. Are you one of them? In this workshop Bob Hartman will give participants a how-to guide for causing agile process failure. Attendees will learn various failure modes and how to cause them. There will be group discussions and exercises exploring how the failure modes can manifest themselves in real projects. At the end of this workshop each attendee should have the ability to cause agile project failure in a variety of ways and under a variety of conditions. Obviously the first paragraph is a bit tongue-in-cheek. Hopefully project managers do not want agile projects to fail, but they need to know how they could fail. This knowledge will translate into an ability to recognize the failure modes and take corrective action. Interestingly, many of the agile project failure modes are also failure modes in other project process methodologies. All project managers on agile projects or in organizations that are considering using an agile process should attend this workshop. Project managers in organizations which typically struggle with projects may also gain insight into their project failure modes.

Citation preview

Page 1: Failing With Agile

Failing with Agile:A How-to Guide

Don’t end up with an apple instead of an Apple®!

Presentation Copyright © 2008, Agile For All, LLC. All rights reserved.

Presented byBob HartmanPresident, Agile For [email protected]

Page 2: Failing With Agile

2

Before We Start

• Cell phones, pagers, PDA’s, etc. to silent• If you have a question, please ask it. Don’t

wait! It is better to answer the question while we are still in the same area than to go back.

• We will take a break after about 90 minutes

Failing with Agile

Page 3: Failing With Agile

INTRODUCTIONS

Page 4: Failing With Agile

4

Bob Hartman (Agile Bob)

• 30+ years of software industry experience

• Certified Scrum Practitioner• Bachelor and Masters degrees

in Computer Science• Roles included Tester,

Developer, Dev Manager, QA Manager, Product Manager, Project Manager, VP…

• Started with agile in 1999

[email protected]

Failing with Agile

Page 5: Failing With Agile

5

Who are you?

• Please introduce yourself including:– Name– Company and role– Agile experience

About

Me

Failing with Agile

Page 6: Failing With Agile

FRAMING THE PROBLEM

Page 7: Failing With Agile

7

Software project success ratesSoftware Project Success Rate

Report Date Success RateFirst CHAOS report 1994 16%“Extreme CHAOS” 2001 28%

CHAOS 2003 2003 31%CHAOS 2006 2006 35%

Source: The Standish Group

Success increasing by 1.7% per year. Will not reach 50% until 2014!

Failing with Agile

Page 8: Failing With Agile

8

Industry realities

• Most “successful” projects were deliberately over-estimated at the start (Standish – 2001)

• The average project exceeds its schedule by 63% (Standish – 2001)

• 50% of project failures are due to missing or misunderstood requirements (Ravenflow – 2006)

• Executive support and customer involvement are the two biggest critical success factors in project success by far (many studies in the past 10 years)

Failing with Agile

Page 9: Failing With Agile

9

More industry realities

• 56% of defects are attributable to missing or misunderstood requirements

• 82% of defect fixing time and dollars go to fixing requirements related defects

• NIST has estimated that 0.6% of the GDP is lost due to software defects

• NIST also estimates that 1/3 of that money could be saved by using a process allowing earlier detection and correction of defects

Failing with Agile

Page 10: Failing With Agile

10

Things I sometimes ponder…• Why do we make all important decisions on projects when we

have the least information?• Why do managers always think things will take less time than

everyone else? Why do we let them estimate at all?• Why has the software industry never improved the ability to

estimate accurately?• If we know that an average of 30% of requirements will change

during a project, why do we use a process that is intolerant to change?

• Why do companies say that quality is important while internally they give QA less time than originally allocated to do their job?

• Why do developers always do the easiest things first?• If the customer is always right, why do we only ask them their

opinion AFTER we have completed the entire project?Failing with Agile

Page 11: Failing With Agile

DOING THE RIGHT THINGBUT DOING IT WRONG

But this is supposed to work!!!

Page 12: Failing With Agile

12

Getting things to “done” – sort of!• Iteration 1 – coded and tested! • Iteration 2 – coded and tested! • Iteration 3 – coded and tested! • Iteration 4 – coded and tested!

• Where’s the problem?

• No regression testing – “done” for an iteration means all previous testing passes as well! The above scenario leads to:

• Final validation testing – FAILS!

Failing with Agile

Page 13: Failing With Agile

13

Identifying tasks – but not all of them

Failing with Agile

Page 14: Failing With Agile

14

The daily stand-up of death

Yesterday I did that, today I’ll do this, nothing blocking me. Next…

Failing with Agile

Page 15: Failing With Agile

INADVERTENT SABOTAGE

Hurting by helping!

Page 16: Failing With Agile

16

Working aheadI know we are only in

iteration 1, but I did story3 and knew that story 322

depended on it, so I did thatone too! Cool huh!

Failing with Agile

Page 17: Failing With Agile

17

The return of command and control

I thought agile was supposed to

empower us?!?

Failing with Agile

Page 18: Failing With Agile

18

Hmm, how should I do this?

I don’t really know how to solve this, but that’s ok, I’ll just think like a customer

Good developers will try to think like a customer – THEN they will make the wrong decision!

Failing with Agile

Page 19: Failing With Agile

19

Invite complexityMr. Product Champion, which way should I go?

It doesn’t affect the user, so pick

either!

Complex – Yeah!Failing with Agile

Page 20: Failing With Agile

20

Small Group Exercise

Describe inadvertent sabotage you have experienced. What were the results and

how it was first detected?

Failing with Agile

Page 21: Failing With Agile

FAILURES CAUSED BY MANAGEMENT

Page 22: Failing With Agile

22

Lack of sufficient agile trainingDilbert knows agile!

Or, maybe not

Failing with Agile

Page 23: Failing With Agile

23

Asking “How are we doing?”

Hey George, how are we doing?

Apparently executives and managers have no eyes!

Failing with Agile

Page 24: Failing With Agile

24

Early hiccup = total failure

See! Iteration 1 wasn’t perfect. I

told you agile wouldn’t work!!!

Failing with Agile

Page 25: Failing With Agile

25

Seeding doubt

Psst. Be careful. I’m pretty sure this agile stuff will fail.

Failing with Agile

Page 26: Failing With Agile

26

Always follow the chain of command!

I don’t care if it worked. This is the org chart and you should

have asked me (even if it would have taken 5 extra days).

Let’s make some spaghetti to show this in action!

Failing with Agile

Page 27: Failing With Agile

27

Small Group Exercise

List a few different forms of management failure you have

experienced and what happened.

Failing with Agile

Page 28: Failing With Agile

FAILURES CAUSED BY WASTE

Page 29: Failing With Agile

29

What is waste?

Anything that does not add value!

Meetings, research that is never utilized, unfinished code, untested code,

undocumented/unusable features…

What else?Failing with Agile

Page 30: Failing With Agile

30

Building what you don’t need

Never Used45%

Rarely19%

Sometimes16%

Often13%

Always7%

Source: The Standish Group

Question: What percentage of software features are NEVER used?

Failing with Agile

Page 31: Failing With Agile

31

Poor requirements gathering technique

Failing with Agile

Page 32: Failing With Agile

32

Building infrastructure first

Layers = Allwork done

Slices = lesswork to do

Which is easier to change?Failing with Agile

Page 33: Failing With Agile

33

Being dogmatic about process

Agile says we have to have daily stand-ups. It doesn’t

matter that part of the team is in Sri Lank 12.5

time zones away!

Failing with Agile

Page 34: Failing With Agile

34

Small Group Exercise

What are some types of waste in your organization that you can start to

eliminate immediately?

Failing with Agile

Page 35: Failing With Agile

TEAM FAILURE MODES

Page 36: Failing With Agile

36

Play the blame game

It’s your fault!

Failing with Agile

Page 37: Failing With Agile

37

It’s ok to move things to the next iteration

This didn’t finish, so move it from iteration 1 to iteration 2, no 3, I

mean 4.

Failing with Agile

Page 38: Failing With Agile

38

Teams that are too largeWill this stand-up ever end?

Failing with Agile

Page 39: Failing With Agile

39

Make silos even deeper

Testers vs. DevelopersIs anyone a team member any more???

Failing with Agile

Page 40: Failing With Agile

40

Poor communication

Failing with Agile

Page 41: Failing With Agile

41

Not my job

See, right there it says it isn’t my job to do that!

It’s not my fault the team failed the

iteration because I didn’t press “Run”

Failing with Agile

Page 42: Failing With Agile

42

Small Group Exercise

Even successful teams are held back in many ways by the way they do things. What “failures” are your current teams

dealing with today?Failing with Agile

Page 43: Failing With Agile

PRODUCT CHAMPION BASED FAILURES

Page 44: Failing With Agile

44

Keep the plan in your head…

Don’t ever tell anyone else what the plan is. That way they need

to rely on you, right???Failing with Agile

Page 45: Failing With Agile

45

Be efficient – have more than one role

It’s great being a team member, Scrum Master and Product Champion! All have

to bow to me!!! Oh, and all my stuff gets done first – sweeeeeeet!

Failing with Agile

Page 46: Failing With Agile

TESTING FAILURES

Page 47: Failing With Agile

47

Confusing unit tests and acceptance tests

Acceptance Tests

Business Intent (Design of the Product)

UsabilityTesting

ExploratoryTesting

Unit Tests

Developer Intent (Design of the Code)

PropertyTestingResponse, SecurityScaling,…

from Brian Marick

Technology Facing

Business FacingSu

ppor

t Pro

gram

min

g

Criti

que

Prod

uct

Automated(QA)

Manual(Anyone)

Automated(Developer)

Tool-Based(Expensive)

Durin

g Ite

ratio

n

When

possible

Failing with Agile

Page 48: Failing With Agile

48

Testing at the end of an iteration

Coding Testing

Day

1D

ay 2

Day

3D

ay 4

Day

5D

ay 6

Day

7D

ay 8

Day

9D

ay 1

0

Code Freeze

Q: What are developers doing during the testing period?

Failing with Agile

Page 49: Failing With Agile

49

Coding in one iteration, testing in the next

• Each tester– 40% of time writing tests for current iteration– 20% of time running tests for current iteration– 40% of time regression testing

• Iteration 1 this tester has 40% slack time• Iteration 2 this tester has 20% slack time

– 40% writing new tests, 20% running new tests, 20% running tests from iteration 1

• Iteration 3 this tester has 0 slack time– 40% writing new tests, 20% running new tests, 20% running tests from

iteration 1, 20% running tests from iteration 2• Iteration 4 we can no longer complete all testing!

• This is most often caused by dependence on manual testing

Failing with Agile

Page 50: Failing With Agile

50

Lack of automated testing

Failing with Agile

Regression Deficit Disorder

Page 51: Failing With Agile

51

Group discussion

What testing challenges currently exist in your organization?

Failing with Agile

Page 52: Failing With Agile

FAILURES DUE TOLACK OF TRUST

Page 53: Failing With Agile

53

Measure inappropriately

DILBERT: © Scott Adams/Dist. by United Feature Syndicate, Inc.

You will get what you measure!!!

Failing with Agile

Page 54: Failing With Agile

54

The “no power” Product Champion

I know you told the team to do that, but I’m your manager and I

think it’s wrong, so change it!

Failing with Agile

Page 55: Failing With Agile

55

Agile in name only

Here is the scope and the date, now be agile and deliver it all on time!

Failing with Agile

Page 56: Failing With Agile

56

Micromanagement

This project is important and as CTO, I want to make sure we’re

measuring up every day!Failing with Agile

Page 57: Failing With Agile

PROCESS FAILURES

Page 58: Failing With Agile

58

Changing process before it is understood

This is a simple process, why do we need to meet each day to discuss things?

Failing with Agile

Page 59: Failing With Agile

59

Lack of commitment to improvement

Woohoo! A new record! That retrospective only took 2 minutes!!!

Failing with Agile

Page 60: Failing With Agile

60

Watching metrics, not the people

Great job! Another successful iteration.

Failing with Agile

Page 61: Failing With Agile

FIXING FAILURE

Page 62: Failing With Agile

62

Small Group Exercise

Talk about some fixed failures and how they were fixed. Talk about some

failings that are not yet fixed and what might be done to fix them.

Failing with Agile

Page 63: Failing With Agile

AGILE EXPECTATIONS

Page 64: Failing With Agile

64

What others are seeing

Failing with Agile

Page 65: Failing With Agile

65

VersionOne Survey Results (2008)

Improvement Noted >10% improvement >=25% improvementIncreased productivity 89% 56%Reduced software defects 84% 56%Accelerated time-to-market 83% 54%Reduced cost 65% 30%

Survey asked people: Please try to estimate SPECIFIC IMPROVEMENTS you have actually realized from implementing Agile practices.

Source: VersionOne 2008 State of Agile Development Survey

NOTE: All 2008 data is within 2% of 2007 data implying these numbers are not one-time anomalies

Biggest causes of company-wide agile failure: Company philosophy or culture could not be overcome – 23% Lack of experience with agile – 21%

Failing with Agile

Page 67: Failing With Agile

RESOURCES

Page 68: Failing With Agile

68

Places to go for help

• My website! www.agileforall.com• Organizations– Agile Alliance (www.agilealliance.org)– Agile Project Leadership Network (APLN –

www.apln.org • Yahoo Groups– PMI Agile (pmiagile) – giving direction to people that

will be responsible for the Agile PMI Virtual Community to be formed in 2009

– Agile Denver (agiledenver)– APLN Denver (apln-denver)

Failing with Agile

Page 69: Failing With Agile

RETROSPECTIVE

Page 70: Failing With Agile

70

Help me out!

• I’m doing this again at the PMI Mile Hi Symposium in March 2009 and I want to make sure it is as good as possible!

• What went well?• What went less well?• How can I improve things next time?

Failing with Agile

Page 71: Failing With Agile

FINAL QUESTIONS?

Page 72: Failing With Agile

THANK YOU!Please fill out evaluation forms

Get on my mailing list if you want to receivea PDF of this presentation via email