INNOV-9: Adventures in Development Methodologies

1
INNOV-9 Adventures in Development Methodologies

• theres no subtitle like a good subtitle

Gus Björklund
Wizard, Progress Software Corporation
2
Adobes (old) Development Process
PhotoShop development

• 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

3
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!
4
Adobes results
PhotoShop development

• 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

reference blogs.adobe.com
5
(No Transcript)
6
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
7
Topics

• History
• Failures
• Agile Methods
• Results
• More Important Things
• Call to Action

8
A Bit of History
Those who fail to learn the lessons history
teaches are doomed to repeat the mistakes of the
past.
9
Early days of programming Cut and Try

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

10
Programs got bigger.Chaos ensued
11
COBOL was invented. Business people could create
their own applications and programmers were no
longer needed. order was restored.
12
Fred Brooks The Mythical Man Month
13
Harlan Mills Top-Down Programming
14
Edsger Dijkstra Goto considered harmful
15
1970 Winston Royce The Waterfall Model which
became US DoD STD-2167and other standards
16
The waterfall model
17
Order was restored.
18
Digression A Survey

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

19
Back to our regularly scheduled program
20
Order was restored.
21
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

22
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

23
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.

24
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

That was in 1994. The situation has not improved.
source Standish Group CHAOS Chronicles
25
Why Is Software Development So Hard?
26
Common Causes
1. Unrealistic or unarticulated project goals 7. Use of immature technology
2. Inaccurate estimates of needed resources 8. Inability to handle the projects complexity
3. Badly defined system requirements 9. Sloppy development practices
4. Poor reporting of projects 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
27
How Can We Make It Less Hard?
28
QUIZ What is the 1 most important thing we need
in developing software?
29
How do we avoid failureslike the ones that we
all know about?
30
Agile development methods to the rescue!
31
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
32
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.
• Simplicitythe art of maximizing the amount of
  work not doneis 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.

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

• 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.
34
How are agile methods different?

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

35
Agile approaches

• Chief programmer teams
• XP
• Scrum
• Guss method

36
Chief programmer teams
An old idea that shouldnt be forgotten

• Team consists of
• Chief programmer
• Backup chief programmer
• Librarian
• Programmers
• Project administrator
• Toolsmith
• Testers

F.T. Baker, IBM, late 60s
37
Agile approaches

• Chief programmer teams
• XP
• Scrum
• Guss method

38
Extreme Programming (XP)
XP Values

• Communication
• Simplicity
• Feedback
• Courage
• Respect

39
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

40
XP Summarised

• In an iteration
• Write automated tests first
• Coding, by pairs of programmers
• follow strict coding standards
• complete when
• all tests pass
• programmers cant think of any more needed tests
• Refactor
• Demo

41
XP works best for

• New or prototype technology
• requirements change frequently
• Research projects
• goal is knowledge gained, not product
• Smaller projects

42
Agile approaches

• Chief programmer teams
• XP
• Scrum
• Guss method

43
Scrum Summary

• Timebox everything
• Work from backlogs
• Product backlog
• Sprint backlog
• Short cycles
• Small teams

44
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

45
Scrum phases

• Review release plans
• Distribution, review and adjustment of product
  standards
• Sprints lasting about 4 weeks
• Repeat as many times as necessary
• Closure

46
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
47
Scrum sprints

• Plan
• Develop
• Wrap
• Review
• Adjust

48
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

49
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

50
Agile approaches

• Chief programmer teams
• XP
• Scrum
• Guss method

51
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.
52
Adobes Recent Experiencewith a new development
process
53
Adobe the new process
PhotoShop CS3

• Incremental development
• Work on a few features at a time, finish them
  before moving on
• Any dev with 20 bugs cant 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

54
Adobe results with new dev process
PhotoShop CS3

• 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

55
The question I knowyou are all wanting to ask
56
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.

57
Agile Works
Standish Group 16 percent of waterfall projects
succeed 41 percent of agile projects succeed
!!! (2006 Chaos report)
Forrester Agile works. 17 of companies using
agile. (2006 Agile Adoption Survey)
58
Agile Development Myths

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

59
Agile Development Myths

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

60
Theres something else to consider
"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
61
Methodology/process isnt everything
People are the most important thing

• 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.h
tm
62
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/ScrumAndXpFromTheTrenc
hes.pdf
63
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

64
Answers
?