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: [email protected] Scott Duncan: [email protected]
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