INNOV-9: Adventures in Development Methodologies

INNOV-9: Adventures in Development Methodologies

there’s no subtitle like a good subtitle

Gus BjörklundWizard, Progress Software Corporation

© 2007 Progress Software Corporation2 INNOV-9: Adventures in Development Methodologies

Adobe’s (old) Development Process

Waterfall method• Specify desired features, set ship date

• Work on features to “feature complete” date

• Fix bugs

• Ship beta

• Revise features based on beta tests

• Fix more bugs

• Release

PhotoShop development


the Klingon way

What is this talk of 'release'? Klingons do not make software 'releases'. Our software 'escapes' leaving a bloody trail of designers and quality assurance people in its wake.

Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!


Adobe’s results

Death-march to get features in by date• work nights and weekends as deadline looms

Lots of bugs at feature complete Fix worst bugs before beta ship No time to revise features based on feedback Death-march to get enough bugs fixed by

final freeze date• work nights and weekends as deadline looms

Buggy product

PhotoShop development

reference: blogs.adobe.com



This Just In …

“The digital signs along the 98 B-line between downtown Vancouver and Richmond are supposed to let people waiting at the bus stop know when the next bus will arrive.

The signs, which are linked to a GPS system on the buses, haven't been working for the past week, freezing up and requiring frequent reboots.

. . .Siemens has basically thrown up its hands and

say they can't make it work.”CBC News, March 8, 2007


Topics

History

Failures

Agile Methods

Results

More Important Things

Call to Action


A Bit of History

“Those who fail to learn the lessons history teaches are doomed to repeat the mistakes of the past.”


Early days of programming: “Cut and Try”

code some test some fix code some more test, fix lather, rinse, repeat


Programs got bigger.Chaos ensued


COBOL was invented.

Business people could create their own applications and programmers were no longer

needed.

order was restored.


Fred Brooks: “The Mythical Man Month”


Harlan Mills: Top-Down Programming


Edsger Dijkstra: “Goto considered harmful”


1970: Winston Royce: The “Waterfall Model”

which became US DoD STD-2167and other standards


The “waterfall model”

Requirements

Design

Coding

Integration

Test / Debug

Installation

Maintenance

Analysis


Order was restored.


Digression: A Survey

Who uses a formal development process? Who uses waterfall? Who uses DOD-2167? Who uses something else?


Back to our regularly scheduled program


Order was restored.


Waterfall assumes that

A reasonably well defined set of requirements if we take the time to understand them

Change will be small and manageable Integration will go well The schedule can be met


Waterfall assumes that

A reasonably well defined set of requirements if we take the time to understand them

Change will be small and manageable Integration will go well The schedule can be met


Development “Failures”

1960-1964: OS/360 1981-1994: US Air traffic control system 1995: Denver airport baggage handling system 2000-2005: MS SQL Server 2005 1988: Dbase IV 1994: Progress Version 7 2004: Sainsbury PLC supply chain system 2007: TurboTax online tax filing 2001-2007: Vista Many, many more.


Facts

$ 89 Billion spent on cancelled software projects

$ 59 Billion more on cost overruns Of the challenged or cancelled projects, the

average project• was 189 % over budget

• was 222 % behind schedule

• had 61 % of planned features delivered

source: Standish Group CHAOS Chronicles

That was in 1994. The situation has not improved.


Why Is Software Development So Hard?


Common Causes

1. Unrealistic or unarticulated project goals

7. Use of immature technology

2. Inaccurate estimates of needed resources

8. Inability to handle the project’s complexity

3. Badly defined system requirements

9. Sloppy development practices

4. Poor reporting of project’s status

10. Poor project management

5. Unmanaged risks 11. Stakeholder politics

6. Poor communication among customers, developers, and users

12. Commercial pressures

“Why Software Fails”, Robert N. Charette. IEEE Spectrum


How Can We Make It Less Hard?


QUIZ:

What is the 1 most important thing we need in developing software?


How do we avoid failureslike the ones that we all know about?


Agile development methods to the rescue!


The Manifesto for Agile Software Development,17 anarchists agree

by 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

Feb 13, 2001


Agile manifesto: We follow the following principles:

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 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 Manifesto - values

Individuals and interactions over processes and tools.

Working software over comprehensive documentation.

Customer collaboration over contract negotiation.

Responding to change over following a plan.

That is, while we value the items on the right, we value the items on the left more.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:


How are agile methods different?

Emphasizes direct communication Focuses on working software Raises the level of skill


Agile approaches

Chief programmer teams XP Scrum Gus’s method


Chief programmer teams

Team consists of• Chief programmer

• Backup chief programmer

• Librarian

• Programmers

• Project administrator

• Toolsmith

• Testers

An old idea that shouldn’t be forgotten

F.T. Baker, IBM, late 60’s


Agile approaches



Extreme Programming (XP)

Communication Simplicity Feedback Courage Respect

XP Values:


XP Summarised

Team of 5 to 10 work at one location with customer representation

Development occurs in frequent iterations• each is releasable

• each delivers more functionality

Requirements specified as “user stories”• each is a chunk of functionality user needs

Programmers work in pairs Requirements, architecture, and design emerge over

the course of the project


XP Summarised

In an iteration• Write automated tests first

• Coding, by pairs of programmers– follow strict coding standards– complete when

all tests pass programmers can’t think of any more needed tests

• Refactor

• Demo


XP works best for

New or prototype technology• requirements change frequently

Research projects• goal is knowledge gained, not product

Smaller projects


Agile approaches



Scrum Summary

Timebox everything Work from “backlogs”

• Product backlog

• Sprint backlog

Short cycles Small teams


Scrum: Teams

Team of 5 to 9 people One member serves as “Scrum Master” to

• Facilitate meetings

• Manage outside interference

• Record decisions, track action items

• Keep everyone informed


Scrum: phases

Review release plans Distribution, review and adjustment of product

standards “Sprints” lasting about 4 weeks Repeat as many times as necessary Closure


Product backlog

ID Name Imp Est How to demo Notes

1 Deposit 30 5 Log in, open deposit page, deposit €10, go to my balance page and check that it has increased by €10.

Need UML sequence diagram. No need to worry about encryption for now.

2 See your own transaction summary

10 9 Log in, click on “transactions”. Do a deposit. Go back to transactions, verify the new transaction shows up

Use paging to avoid large queries. Design similar to view users page

Source: “Scrum and XP from the Trenches”, Henrik Kniberg


Scrum: sprints

Plan Develop Wrap Review Adjust


Scrum: Team meetings

Daily, always at same time 15 minutes 3 questions only, by Scrum master

• What have you done since last meeting?

• What impedes your work?

• What will you do by next meeting?

Follow-up meetings held after, if needed


Scrum: advantages

Product becomes series of manageable chunks Progress made, even if requirements not stable Everything visible to everyone Communication improves Success shared along the way Customers see how product actually works Strong customer relationships develop Culture created where everyone expects project to

succeed


Agile approaches



Gus’ Method

Think Think more Think still more Write code Test, fix Write code again, test Write code again, test Doc

Not recommended for general use. Works for me.


Adobe’s Recent Experiencewith a new development process


Adobe: the new process

Incremental development• Work on a few features at a time, finish them

before moving on

Any dev with 20 bugs can’t work on features Only complete features can be merged Ready to ship within short notice

• some features may not be there

• everything that is there is complete and works

More beta cycles

PhotoShop CS3


Adobe: results with new dev process

Higher quality• Fewer bugs overall

• Fewer bugs in mid cycle

• Much more useful (and earlier) beta cycles

More predictable dev cycles Can demo product at almost any stage No more nights and weekends

PhotoShop CS3


The question I knowyou are all wanting to ask:


Does this stuff actually work?

Yes. Agile methods succeed at• Fidelity, VA Software, Medtronic, Adobe, IBM,

Sapient, Yahoo, SAP, BMC Software, Symantec, Verizon, Microsoft, others

Results can be excellent Agile scales Agile methods will NOT solve every problem.


Agile Works

Standish Group:16 percent of waterfall projects succeed41 percent of agile projects succeed !!!

(2006 Chaos report)

Forrester:Agile works.17% of companies using agile.

(2006 Agile Adoption Survey)


Agile Development Myths

No process No documentation Only works for small projects Only works for small teams Chaotic


Agile Development Myths

No process No documentation Only works for small projects Only works for small teams Chaotic


"A great lathe operator commands several times the wage of an average lathe operator, but a great writer of software code is worth 10,000 times the price of an average software writer.”

Bill Gates

There’s something else to consider …


Methodology/process isn’t everything

Huge difference between best and worst• 10 x and more variance in productivity

• 10 x and more variance in quality

Motivation Experience Work environment

• Top performers have quiet work area and few interruptions

http://www.stevemcconnell.com/ieeesoftware/eic14.htm

People are the most important thing


Call to Action

Try something on a small scale first• Share your stories

A given methodology may not suit your or your development teams

Adapt to suit your needs Adapt and adopt, based on your results Read this:

“Scrum and XP from the Trenches”, Henrik Kniberg

www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf


Homework

Books• “The Mythical Man Month”, Fred Brooks• “Scaling Software Agility”, Dean Leffingwell• “Agile Software Development”, Alistair Cockburn

Paper• “Chief Programmer Team Management of Production

Programming”, F.T. Baker, IBM Systems Journal, Vol 11, No 1, 1972

Wikipedia articles (www.wikipedia.org)• Agile software development• Waterfall Method• Extreme Programming• Software development process


Answers

Documents

INNOV-9: Adventures in Development Methodologies