Modern Software Engineering June 15 2000 Copyright c

Current State, Ugh (i) Some organizations are 10 (even 600) times more productive than others(1) Most Software Projects Fail Some definitions for Failure: Missed schedule Missed functionality Missed budget Too fragile for usage demands Defect rates too high once in production (1) Steve Mc. Connell, After the Gold Rush. Redmond, WA. Microsoft Press, 1999.

Ugh (ii) In 1995, only 16% of software projects were expected to finish on time and on budget. (1) Projects completed by the largest US organizations have only 42% of originally proposed functions. (1) An estimated 53% of projects will cost nearly 190% of their original estimates. (1) In large companies, only 9% of projects will be completed on time and on budget. (1) Standish Group International Report, “Chaos”, as reported in March ‘ 95 Open Computing. Copyright 1995 SPC.

Ugh (iii) Canceled projects—$81 billion loss to US in 1995(1) Average MIS— 1 year late, 100% over budget(2) (1) Standish Group International Report, “Chaos”, as reported in March ‘ 95 Open Computing. Copyright 1995 SPC. (2) Capers Jones, Applied Software Measurement, Mc. Graw-Hill, 1991.

The Venerable Waterfall Process Postpones Confronting Risk Late Design Breakage Maintenance Testing Implementation Design Analysis Can work on well-defined efforts Can work in smaller efforts Great for reporting apparent progress

Scrum – an activity that occurs during a rugby match. Scrum—distinguishing features Development work is partitioned into “packets” Testing and documentation are on-going as the product is constructed Work occurs in “sprints” and is derived from a “backlog” of existing requirements Meetings are very short and sometimes conducted without chairs “demos” are delivered to the customer with the time-box allocated Scrum incorporates a set of process patterns that emphasize project priorities, compartmentalized work units, communication, and frequent customer feedback.

Scrum Principles Small working teams used to maximize communication and minimize overhead Process must be adaptable to both technical and business challenges to ensure best produced Process yields frequent increments that can be inspected, adjusted, tested, documented and built on Development work and people performing it are partitioned into clean, low coupling partitions Testing and documentation is performed as the product is built Ability to declare the product done whenever required

Scrum - 1 Backlog prioritized list of requirements or features the provide business value to customer items can be added at any time) Sprints work units required to achieve one of the backlog items must fit into a predefined time-box affected backlog items frozen

Scrum - 2 Scrum meetings 15 minute daily meetings what was done since last meeting? what obstacles were encountered? what will be done by the next meeting? Demos deliver software increment to customer for evaluation

SCRUM – Management Controls SCRUM projects are not "Out of Control" and, in fact, have several good management and control elements: Daily SCRUM Meeting. This is a daily meeting attended by all team members for a Sprint. The call is generally very brief (15 mins. ), the purpose of which is to update the project manager and other team members on progress and to raise any issues that the project manager or other team members can assist with. Three questions are answered by each participant: l What did I do in the last 24 hours? l What do plan to do in the next 24 hours? l What obstacles are standing in my way? Visible Progress Demonstration. At the end of each Sprint, the customer and all project team members get to see a visual demonstration of progress to date. Customer feedback can be obtained early in the process this way, and avoid costly changes late in the project lifecycle. Overall project progress is very visible and very easy to track in this way via a function/feature checklist, function points, or other similar means. (C) 2002 Kevin Aguanno.

SCRUM – Management Controls Sprint Burndown Charts. During a Sprint, the team provides an updated estimate on the number of hours/days to complete their work during the daily SCRUM meetings. The project manager can use this data to build a Sprint Burndown Chart showing the progress within a Sprint. The total projected number of hours for a Sprint usually increases in the early days of the Sprint as nuances and additional work are uncovered, but then rapidly decline as work gets underway. Text (C) 2002 Kevin Aguanno. Chart (C) 1997 Advanced Development Methods Inc.

SCRUM – Management Controls Accelerated Customer Approval. Because the customer reviews visible deliverables at the end of each Sprint and provides feedback at that time, coupled with the fact that subsequent Sprints build upon the work of earlier Sprints, the final output should not contain any surprises to the customer and will already include the bulk of his feedback. This should allow for a faster final customer approval/acceptance of the deliverables. (C) 2002 Kevin Aguanno.

A Solution Feature-Driven Development Client-centric Architecture-centric Repeatable process Pragmatic, livable methodology Great for developers Great for managers Great for the application!

Feature Driven Development Practical process model for OO SW engineering. Applicable to moderate sized and larger SW projects. FDD—distinguishing features Emphasis is on defining “features” • a feature “is a client-valued function that can be implemented in two weeks or less. ” Uses a feature template • the a(n)