1. STC 2003 Track 3, Wednesday, 30 April 2003 1 Light-Weight (Agile) Development Methods Edward R. (Ted) Byrne Software Consultant Management Board of IEEE SESC Scott Duncan ASQ Software Division Management Board of IEEE SESC

2. 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. u Summarize Agile u Challenges when using Agile u Possible ways to use Agile u Books coming out u IEEE Standard being developed

3. STC 2003, May 2003 3 Situation Now Strong views on both sides l Government offices; “Would not even think of doing this” l 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

4. STC 2003, May 2003 4 Agile: What it is The Agile Manifesto (http://agilemanifesto.org) “ We have come to value: u Individuals & interactions over process & tools u Working software over comprehensive documentation u Customer collaboration over contract negotiation u 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

5. STC 2003, May 2003 5 Four Values (From XP, which is typical) l Communication: Problems can invariable be traced back to somebody not talking to somebody l Simplicity: What is the simplest thing that could possibly work l Feedback: Information about the current state of the system is absolutely priceless l Courage: If you don’t go at top speed, someone else is and they will eat your lunch. Reference: Beck 2001

6. STC 2003, May 2003 6 12 XP Practices l The planning game l Small releases l Metaphor l Simple design l Testing l Refactoring l Pair programming l Collective ownership l Continuous integration l 40-hour week l On-site customer l Coding standards

7. STC 2003, May 2003 7 Typical XP Scenario l Pick top priority feature off list l Create a set of tests to verify it works and add these to the complete test script l Modify the benchmark software to add this feature l Run the test suite on the modified software l If all test pass: u make the modified code the new benchmark u mark the feature as implemented l If all tests do not pass: u put the feature back on the list and try again

8. STC 2003, May 2003 8 Why Do We Care About Agile? l More cost effective: 2 to 1 not unusual l Faster development: 2 to 1 not unusual l More tolerant of requirements changes: beyond comparison l Low bidder may be using Agile

9. STC 2003, May 2003 9 It is not for Everything But there are Challenges (Problems) when large, critical projects use Agile: l Technical problems l Organizational problems l Business problems (not all of these apply in every situation)

10. STC 2003, May 2003 10 Possible Technical Problems l 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 l Typical requirements go beyond functionality to system interfaces, reliability, environment, design constraints, product support. Agile stresses functionality requirements and is poor at testing others l New micro benchmark releases are not useful. They have to be tied into system milestones

11. STC 2003, May 2003 11 Possible Organizational Problems l 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 l Even if they did, they have no one with the expertise to be a partner developer. Their business is not software development! l 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

12. STC 2003, May 2003 12 Possible Business Problems l 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. l 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.

13. STC 2003, May 2003 13 Continued l 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.

14. 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: l If Agile is wrong for a project, don’t use it. l 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.

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

16. 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. l Customer has Requirements, schedules, milestones, work breakdown packages, etc. l Agent converts these into day-by-day priorities, mini- milestones, informal progress, etc. l This is somewhat similar to what IV&V agents do. (and we do this with lawyers all the time) l Could even imagine an Artificial Intelligence computer program, acting as the agent.

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

18. 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: u Defines a common form of interaction between two groups who see the world very differently u Defines which projects are appropriate for Agile u Tells what constitutes a successful accomplishment of such a project

19. STC 2003, May 2003 19 Who To Contact Possible types of participation: l Part of Standard Working Group, to help create the standard l Part of Standard Review Group, to help Review & vote on the draft standard l Potential trial user of the standard l Ted Byrne: flatland@compuserve.com l Scott Duncan: sduncan@tsys.com

20. STC 2003, May 2003 20 Summary l Agile and High Reliability Projects are coming together (like it or not) l Substantial information is appearing in the form of books l There are major challenges and success is not guaranteed l Work on a standard is beginning

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

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

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