STC 2003 Track 3, Wednesday, 30 April 2003 1

Light-Weight (Agile) Development Methods

Edward R. (Ted) ByrneSoftware Consultant

Management Board of IEEE SESC

Scott Duncan

ASQ Software Division

Management Board of IEEE SESC

STC 2003, May 2003 2

Agile in High-Reliability Systems

“Light-Weight /Agile development techniques are wildly popular everywhere - except here!”

We are working to see if this technique can be brought to the Government and large business area, where appropriate.

Summarize Agile Challenges when using Agile Possible ways to use Agile Books coming out IEEE Standard being developed

STC 2003, May 2003 3

Situation Now

Strong views on both sides Government offices; “Would not even think of doing

this” Agile Developers: “ho-hum. Too busy to think about

them”

But recall STC 2002: “There are two risks: having bad software, and not having the software in time.

We are optimistic enough to try but not confident of success

STC 2003, May 2003 4

Agile: What it is

The Agile Manifesto (http://agilemanifesto.org)

“We have come to value: Individuals & interactions over process & tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan”

Agile includes: XP, Scrum, ASD and others (which are similar but not identical)

Not undisciplined, Not cowboy coding: there is a methodology

STC 2003, May 2003 5

Four Values(From XP, which is typical)

Communication: Problems can invariable be traced back to somebody not talking to somebody

Simplicity: What is the simplest thing that could possibly work

Feedback: Information about the current state of the system is absolutely priceless

Courage: If you don’t go at top speed, someone else is and they will eat your lunch.

Reference: Beck 2001

STC 2003, May 2003 6

12 XP Practices

The planning game Small releases Metaphor Simple design Testing Refactoring

Pair programming Collective ownership Continuous integration 40-hour week On-site customer Coding standards

STC 2003, May 2003 7

Typical XP Scenario

Pick top priority feature off list Create a set of tests to verify it works and add these to

the complete test script Modify the benchmark software to add this feature Run the test suite on the modified software If all test pass:

make the modified code the new benchmark mark the feature as implemented

If all tests do not pass: put the feature back on the list and try again

STC 2003, May 2003 8

Why Do We Care About Agile?

More cost effective: 2 to 1 not unusual Faster development: 2 to 1 not unusual More tolerant of requirements changes: beyond

comparison Low bidder may be using Agile

STC 2003, May 2003 9

It is not for Everything

But there are Challenges (Problems) when large, critical projects use Agile:

Technical problems Organizational problems Business problems

(not all of these apply in every situation)

STC 2003, May 2003 10

Possible Technical Problems

The concept of relative importance of requirements is not valid. In real-time and high-reliability systems substantially all of the requirements are necessary if the product is to be useable at all

Typical requirements go beyond functionality to system interfaces, reliability, environment, design constraints, product support. Agile stresses functionality requirements and is poor at testing others

New micro benchmark releases are not useful. They have to be tied into system milestones

STC 2003, May 2003 11

Possible Organizational Problems

The customer cannot provide full-time on-site representation and participation at the developer. They are contracting precisely because they do not have such ability

Even if they did, they have no one with the expertise to be a partner developer. Their business is not software development!

Even if they did, their representatives could not make day-by-day decisions. Decisions in large organizations require interaction with many stake-holders and levels of management

STC 2003, May 2003 12

Possible Business Problems

The customer does business by development contract, with costs, results, milestones, penalties/incentives, etc. This is contrary to the “do-your-best” Agile philosophy, which is more like hiring contract programmers.

Even if the customer could create such a “best-effort” contract, they would have trouble getting funding approval for it and paying for performance of it. Funding agencies want oversight that is pre-specified by objectives, schedules and milestones.

STC 2003, May 2003 13

Continued

The customer wants some demonstration of competence up front, such as ISO9000 compliance or SEI CMM certified level of performance. That is not likely for, and philosophically incompatible with Agile developers.

STC 2003, May 2003 14

So, What to do

The two methods are really different and are incompatible (reference: Scott 2002)

The two all-or-nothing options are: If Agile is wrong for a project, don’t use it. Change your way of doing business, and learn to live

with Agile.

But some middle ground might be much more possible and achievable. Two alternatives follow.

STC 2003, May 2003 15

Fit Some Agile Concepts within Rigorous Methodology

Define Requirements by Use Cases (i.e. stories) Validate Requirements by creating tests up-front Specify some requirements by actual code Empower developers with more flexibility Break a big project down into many smaller projects Break a big development down into smaller phases Get close early and then trim later Make choices so as to minimize risk Do the riskiest parts first, not last

STC 2003, May 2003 16

Add an Interface between Customer and Developer

Customer interacts with the Agent in a rigorous manner, and the Agent interacts with the Developer in an Agile manner.

Customer has Requirements, schedules, milestones, work breakdown packages, etc.

Agent converts these into day-by-day priorities, mini-milestones, informal progress, etc.

This is somewhat similar to what IV&V agents do. (and we do this with lawyers all the time)

Could even imagine an Artificial Intelligence computer program, acting as the agent.

STC 2003, May 2003 17

Books Coming Out

Scott 2002: “The Unified Process Explained”, Kendall Scott, ISBN 0-201-74204-7, Addison-Wesley 2002

“Balancing Agility and Discipline: A Guide for the Perplexed:, Barry Boehm & Richard Turner, Addison-

Wesley, to be published

STC 2003, May 2003 18

Work on IEEE Standard

IEEE Standards work is designed to complement, not conflict with books, papers, etc.

A standard can be attached to an RFP or contract.

Advantages of a Standard are: Defines a common form of interaction between two groups

who see the world very differently Defines which projects are appropriate for Agile Tells what constitutes a successful accomplishment of such

a project

STC 2003, May 2003 19

Who To Contact

Possible types of participation: Part of Standard Working Group, to help create the

standard Part of Standard Review Group, to help Review &

vote on the draft standard Potential trial user of the standard

Ted Byrne: flatland@compuserve.com Scott Duncan: sduncan@tsys.com

STC 2003, May 2003 20

Summary

Agile and High Reliability Projects are coming together (like it or not)

Substantial information is appearing in the form of books

There are major challenges and success is not guaranteed

Work on a standard is beginning

STC 2003, May 2003 21

References

There are Agile articles in almost every issue of every software publication and there are many books.

IEEE Software Magazine, November/December 2001

Crosstalk Magazine, October and November 2002

IEEE Software Magazine, May/June 2003

STC 2003, May 2003 22

Relevant Books

Beck 2001: “Extreme Programming Explained: Embrace Change”, Kent Beck , ISBN 201-61641-6, Addison-Wesley 2000

Succi 2001: “Extreme Programming Examined”, Succi & Marchesi, ISBN 0-201-71040-4, Addison-Wesley 2002

Scott 2002: “The Unified Process Explained”, Kendall Scott, ISBN 0-201-74204-7, Addison-Wesley 2002

Highsmith 2000: “Adaptive Software Development”, Dorset House, 2000

Beedle 2000: “Pattern Languages of Program Design 4”, Harrison et al. Addison-Wesley 2000.

Cockburn 2001 http://members.aol.com/humansandt/

crystal/clear

“Balancing Agility and Discipline: A Guide for the Perplexed:, Barry Boehm & Richard Turner, Addison-Wesley, to be published

STC 2003, May 2003 23

Acronyms

XP: Extreme Programming Ref: Beck 2001

ASD: Adaptive Software Development Ref: Highsmith 2000

Crystal: Ref: Cockburn2001

Scrum: Ref: Beedle2000