Agile?! Are You Crazy???

Agile?! Are you crazy???

Presented byBob HartmanAgile For [email protected]

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

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.

Agile?! Are you crazy?2

3

INTRODUCTIONS

Agile?! Are you crazy?

Bob Hartman

• 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 1999Agile?! Are you crazy?4

[email protected]

Who are you?

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


About

Me

6

JACK AND BILLTwo typical project managers have a chat


7

Meet Jack


A really hard-driving project manager. Jack is young and ambitious and believes by making his team work harder they will get superior results.

8

Meet Bill


Project manager that is older than Jack with many more battle scars. Bill is at a point in his

career where he is starting to question the logic behind the way things have always been done.

9

Jack and Bill meet at the water cooler


Hey Bill, haven’t seen you in quite a while. How is your project going these days?

Jack, you know how it is. Late, overbudget, stress, not enough time for QA. Blah, blah, blah…

10

Jack tries to help


Dude, that stinks. What are you going to do?

I’m getting desperate. I think I’m going to try agile on my next project and see if it will work.

11

Jack is in shock


Agile! Are you crazy???

12

Bill responds


I know it’s crazy, but I’m out of ideas. Hey, you’re the new hard-driving guy, how is your project going?

13

Jack’s reality


Umm… ahhh… uhhh… I mean…Hey, don’t change the subject here! Are you crazy???

(to himself) Hmmm, Maybe not as crazy as I thought if his project is in the toilet too!

14

Group discussion

• Do you relate more to hard-driving Jack, or desperate Bill?

• As project managers do you ever feel like you are personally failing when projects are failing?

• If you have used agile in the past, why was the switch made from traditional software development processes? How did agile work for you?


15

INDUSTRY STATISTICS(SOFTWARE PROJECTS)


16

Software project success rates


Software Project Success RateReport Date Success Rate

First CHAOS report 1994 16%“Extreme CHAOS” 2001 28%

Most Recent CHAOS 2003 31%

Source: The Standish Group

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

2014!

17

Feature use in software

Never Used45%

Rarely19%

Sometimes16%

Often13%

Always7%



Question: What percentage of software features are NEVER used?

18

Industry realities• Most “successful” projects were deliberately over-

estimated at the start (Standish – 2001)• 64% of features in products are rarely or never used

(Standish – 2002)• 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)


19

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


20

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?Agile?! Are you crazy?

21

BUT AGILE IS CRAZY!ISN’T IT???

Excuses for not using agile


22

We’re agile so…• we don’t need to do documentation any more• (more generically) we don’t need to do X because we’re

agile• developers get to decide what goes into each iteration• we’re going to have a lot more meetings• we don’t have to plan more than the current iteration• we can be undisciplined because QA will catch all the

errors in near real time

• Which of these have you heard? Which of these do we believe? Which of these is the worst?


23

No documentation

• A simple question – is this even possible?• The correct phrase is “Just enough

documentation, just in time.”


24

We don’t need to do X

• Again, just enough, just in time.• It doesn’t matter what X is– Design– Architecture– Project charter– Vision– …

• We MUST keep business requirements in mind. If it is required by the business for reasons outside our control, then we have to do it!


25

Developers pick what to work on

• Well, they do say that most myths are at least partially based in reality


Developers don’t get to pick and choose what they want to work on

They DO commit to what they will complete – but it is in priority order and they don’t make the priorities!

26

More meetings• Release planning – once• Iteration planning – once per iteration• Iteration demo/retro – once per iteration• Daily standup – every day• Hmm, that IS more meetings, but• Release planning – 4 hours• Iteration planning – 2 hours x iterations• Iteration demo/retro – 2 hours x iterations• Daily standup - .25 hours x iterations x days• Total might look like: 4 + 2x5 + 2x5 + .25x5x10• Total meeting time is 36.5 hours of meetings• How long would we have met to analyze, design, code and test an

average 3 month release with our current process?• More importantly – would the product have been as good?


27

No planning

• Don’t confuse NO planning with ADAPTIVE planning!

• Would any company actually allow no big picture planning???


Figuring it all out up front Adapting as we go. Notice we still have all the items!

28

No discipline• Reality check… In traditional projects of a year in length how hard

are people working during the first 2 months? Does that sound disciplined?

• Planning, demos and retrospectives every two weeks and daily standups. Does that sound disciplined?

• Making a commitment to work that will be accomplished in two weeks – disciplined?

• Working in priority order – disciplined?• Coding AND testing need to be done in order to be considered

complete – disciplined?• The heart of the matter – Code needs to pass unit tests AND

acceptance tests in order to be complete. High performing teams use the phrase “Add value quickly now AND be able to add value quickly in the future!” In other words, no undisciplined hacking!!!


29

Myth recap• When you hear something about agile that sounds

stupid there are two possibilities:– It’s false because someone is misunderstanding– It’s true and agile has a fundamental flaw

• Keep in mind that it may sound “odd” which is very different from “stupid”– No documentation required = stupid– Teams use points (sizes) rather than hours and minutes for

estimating = odd• Remember that some VERY successful companies are

using agile, and it’s highly unlikely that ALL of them are stupid


30

AGILE BASICS


Agile (Scrum) roles


Users/Stakeholders•Those that are going to use the product or have a vested interest in how it turns out

Team•The team that will create the product•Includes EVERYONE that is part of product creation

Agile Project Manager (Scrum Master)•Facilitates meetings•Removes impediments•Runs interference for the team•Helps team focus on what’s important•Can act as a process coach and help team improve the process

Product Champion (Product Owner)•Owner of the prioritized product backlog•Represents users and stakeholders when talking to team•Represents team when talking to users and stakeholders•Is a combo of Product Manager and BA

32

Complete agile process


33

Iteration – the basic unit of agile


Iterations create a “product increment” of “potentially shippable software.” This means everything is working. It DOES NOT mean we can get it wrong in an iteration and then fix it all up in the next iteration!!!

34

MAYBE AGILE ISN’T SO CRAZYReasons for being agile


35

Building a business case for agility

• Business case essentials:– Bottom line dollars and cents– Improvements

• For this business case we should discuss:– Business value– Customer expectations and quality– Team dynamics– Planning– Other improvements


36

Adding Business Value Quickly – A Simple Example

• Stuffing envelopes can tell us a lot about agile

• What are the advantages of getting something released more quickly?


37

Delivering business value quickly

Never or Rarely Used

64%

Sometimes16%

Often13%

Always7%



Question: If we get rid of the 64% of software that is rarely or never used, what happens to our overall software development efforts?

38

Discussion: Customer expectations

• When does the customer know what they really want in a product?

• How can we help them know earlier?

• Does that sound agile to anyone???

• Did we mention the highest value items get the most testing so quality perception is better as well?


39

Changes to team dynamics

• Morale improves– Team succeeds more often– Teams work together– Teams empowered to succeed

• Failures are very limited– A single iteration– Correction happens immediately– Team fails together so no blame– Happens quickly rather than

bleeding to death from a papercutor finding out about problems too late!


40

Planning improvements

• Retrospectives for correction and improvement

• Accurate management visibility

• Better predictability leading to success


41

Other improvements

• Change tolerance (30% of requirements will change!)– Due to short iterations, change is free or nearly free

most of the time• Increased collaboration– Everyone works together to create a great product

rather than all groups working in isolation• Risks are handled earlier– Everyone identifies risks and impediments as soon

as they are noticed so there is more time to mitigate the risks and remove the impediments


42

Recap: Agile…

• … adds business value quickly• while meeting customer expectations• with high value and high quality products• produced by teams with high morale• through projects that are easier to plan• even while being tolerant to change


43

INDUSTRY STATISTICS PART II(AGILE PROJECTS)


44

What others are seeing


45

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

Average of 74% of agile projects completed successfullyBiggest causes of agile project failure: Company philosophy or culture could not be overcome – 23% Lack of experience with agile – 21%

46

Standish Group further results

• #5 success factor for projects is using agile methodology

• Jim Johnson from the Standish Group says:– Agile is an important success factor because its

incremental nature allows for leaving entire features or portions of features out without affecting the overall value of the project

– He also notes agile is difficult for some because of corporate culture (as also found in the VersionOne survey)


47

Agile is a Proven ApproachSome Agile Companies (there are MANY more)


http://images.google.com/imgres?imgurl=http://www.pennmanor.net/schools/hs/canady/Images/Adobe-Logo.jpg&imgrefurl=http://www.pennmanor.net/schools/hs/canady/&h=343&w=300&sz=20&tbnid=UJ6OeziRNn7RCM:&tbnh=120&tbnw=105&prev=/images?q=adobe+logo&um=1&start=1&sa=X&oi=images&ct=image&cd=1

http://images.google.com/imgres?imgurl=http://www.lpds.sztaki.hu/dapsys/images/hp_logo.jpg&imgrefurl=http://www.lpds.sztaki.hu/dapsys/index.php?m=14&h=719&w=866&sz=45&tbnid=S_6SQ1FpkNEZBM:&tbnh=120&tbnw=145&prev=/images?q=hp+logo&um=1&start=1&sa=X&oi=images&ct=image&cd=1

https://www.eligibility.nedelta.com/index.html

http://www.rbauction.com/index.jsp?WT_svl=home_img

http://www.mapquest.com/

48

WHO IS REALLY CRAZY?


49

One big question to answer…


What does the data say about

how crazy agile is?

50

2nd big question


How should you respond when someone says

“Agile!? Are you crazy???

51

Jack and Bill 6 months later…


Hey Jack, I just heard. Sorry dude. You should have tried agile. All of my projects are actually being successful for a change!!

Don’t rub it in. Both of my projects stunk, so I deserved it. One was on time but had all wrong features, and the other was WAAAAAAAY late.

52

Take away thoughts…• Projects in the software world are NOT completing

successfully today– Teams are trying hard– Project Managers are trying hard– Effort is NOT the issue (don’t be Jack!)

• There is a business case to be made for an agile process

• The world of project management is changing and you have to decide if you are going to be an agent for change, a person that reacts after change has been made, or a person that will not be a part of project management in the future.


53

QUESTIONS?


54

THANK YOU!Please email comments to [email protected]


Technology

Agile?! Are You Crazy???