The Agile Alternative

1. The Agile Alternative Carl Erickson, PhD Atomic Object LLC

2. active, acute, alert, athletic, brisk, buoyant, bustling, clever, deft, dexterous, easy-moving, energetic, fleet, frisky, limber, lithe, lively, mercurial, prompt, quick, quick-witted, rapid, ready, sharp, spirited, sportive, sprightly, spry, stirring, supple, swift, vigorous, vivacious, winged, zippy brittle, clumsy, oafish, ponderous, stiff

3. World-class software development process • Instead of particular domain or technology • Publications, diverse customer base • How we do it • Be the best place in Grand Rapids for software developers to work • Partner effectively with our customer’s staff • Facts • Spring 2000 • 13 full-time software journey and craftspeople • 3 part-time apprentices

4. State of our industry 2004 Standish Group study 30% total failure, cancelled 50% over budget 90% late Chaos report, 1994 31% cancelled 53% more than 2x over budget

5. Status quo "Our challenge is to get our software to the point that people expect it to work instead of expecting it to fail." Jim Larus, leader of software quality project at Microsoft Research MIT Technology Review, April 2003

6. The price we pay NIST - industry losses $60 billion a year Doesn’t even count… government education home loss of life Therac-25 Denver Airport Ariane 5 USS Yorktown FBI Virtual Case File

7. Successful software projects Paid for itself per the business needs (ROI) Met important deadlines Produced software that satisfies end users is stable and reliable performs acceptably is extensible and maintainable Left developers and managers happy

8. To the rescue?

9. Scientific Management "In the past the man has been first; in the future the system must be first.” Frederick Taylor

12. Page 2 "I believe in this concept, but the implementation described above is risky and invites failure.” Winston Royce “Managing the Development of Large Software Systems” IEEE WESCON, August 1970

13. (Ron Jeffries inspired these graphs) Waterfall according to plan Nirvana requirements features functionality infrastructure time

14. Waterfall reality requirements Death March features functionality infrastructure time

15. Agile Alternative • Learn enough to start • Work together in the same space • Express solution in features • Maintain working system, fully tested, ready to ship • Deliver features consistently • Evolve the design as you learn

16. Agile as planned ? requirements features features infrastructure time

17. Data-driven Projects How do you know the state of a project? How can you predict delivery date? How well does a project cope with change?

18. Infrastructure first

19. Features first

20. Measure and Predict

21. Data-driven projects

22. Making adjustments requirements features features infrastructure time

23. Extreme Programming? 2am, marathon, Cheetos, hacking, greasy, undocumented, brilliant, tests?, mysterious, Jolt Cola, protective, ad-hoc, brittle, cubicle, fear change, cowboy, overly elegant, code ego, real soon now, stress difficult to talk to

24. 8-5, teamwork, code reviews, communication, coding standards, snacks, communal code tests, tests, tests, maintainable, documented predictable, copes with change Extreme Programming! 2am, marathon, Cheetos, hacking, greasy, undocumented, brilliant, tests?, mysterious, Jolt Cola, protective, ad-hoc, brittle, cubicle, fear change, cowboy, overly elegant, code ego, real soon now, stress difficult to talk to

25. Ron Jeffries, XProgramming.com XP Practices

26. Core of XP Story-driven dev Test-driven dev One-big-room, pairing Continuously working system

27. Test-Driven Development White box, by the developers, concurrently Much more than finding bugs • JIT specification of a class/method • Useful documentation • Means towards improved design • Knowing when you’re done • Improving morale, feeling confident

28. TDD Loop • Write a test, run it, watch it fail. • Write the simplest possible code to pass the test. • Run it, watch it pass, refactor as necessary. (Automation is necessary, not very difficult.)

29. xUnit main loop suite(); suiteSetUp(); for (each test method X) { testObj = new TestClass(); testObj.setUp(); testObj.X(); testObj.tearDown(); } suiteTearDown();

30. public void testConstructor() throws Exception { WheelData wD = new WheelData(); assertNotNull("dataLabels not initialized", wD.dataLabels); assertEquals("wrong size", 0, wD.dataLabels.size()); } // throttle starts at 0.0, runs at 10Hz void ThrottleOverTime::testRampUp() { float target = 20.0; ThrottleOverTime testObj(mock_throttle, target, 5.0); testObj.createAndRun(); CPPUNIT_ASSERT_EQUAL(target, testObj.position()); CPPUNIT_ASSERT_EQUAL(51, mock_throttle->moveCalled); }

31. Design for testability

32. Easier test, better design

34. TDD Impact 10x

35. One Big Room & Pairs

36. Day in the Office

37. Pair programming Two people, one computer roles: driver, navigator Produces better software Huge reducer of risk Spreads knowledge and expertise avoid single point of expertise great for training/mentoring

39. Pair programming studies Laurie Williams, NC State University Pairs solve problems faster (wall clock time) Code produced is simpler, better Overhead (person hours) is around 20% My observations Getting stuck less often Becoming distracted (“pair pressure”) Challenged by another POV Following good practices Higher morale (more fun)

40. Continuous IntegrationContinuously Working System • Binary status Done, not started • Breaking the build Finding bugs faster Big bang problems • Change in business Budgets Priorities Scope • Feedback Clients Users

41. Adopting Agile • Do so with agility • Know you’ll need to adapt • Find a supportive customer • Find a coach to help