Introduction to Agile Principles, Practices, and Processes

1. Introduction to Agile Principles, Practices, and Processes Steve Bohlen Senior Software Engineer SpringSource/VMware

2. Do I suck? Let me (and the world) know! http://spkr8.com/t/7941

3. Who am I? • …and why should you care? • Steve Bohlen • I Read Books + Write Software • vs. “Read Software + Write Books”  • Blog, Screencast, Speak, Share, Learn

4. Steve Bohlen Nearly 20 years developing software LISP, Delphi, C/C++, VB, VB.NET, C# Senior Engineer Springsource/VMware Co-Founder, NYC Alt.Net User Group http://nyalt.net • Co-Organizer, NYC DDD User Group • http://dddnyc.org Contributor: various OSS projects NHibernate http://www.nhforge.org • NDbUnit http://www.googlecode.com/ndbunit • Spring.NET http://www.springframework.net blog: http://blog.unhandled-exceptions.com e-mail: sbohlen@gmail.com twitter: @sbohlen

5. Test Studio Express TelerikOpenAccess ORM RAD Controls for ASP.NET AJAX RAD Controls for Windows Phone ASPX to Razor Converter RAD Controls for WPF TelerikTeamPulse Sitefinity CMS C#/VB.NET Converter TelerikJustDecompile Telerik Reporting TelerikJustMock RAD Controls for Winforms RAD Controls for Silverlight TelerikJustCode Telerik Extensions for ASP.NET MVC Telerik Test Studio

6. 85!

7. Agenda • What is Agile (and why Should I Care)? • Estimation in the Age of Agile • You Test, I Test, we all Test • Continuous Integration as Transparency Tool

8. What is Agile (and Why)?

9. “Courage is the power to let go of the familiar.”-Raymond Lindquist

10. The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactionsover processes and tools Working softwareovercomprehensive documentation Customer collaborationover contract negotiation Responding to changeover following a plan That is, while there is value in the items on the right, we value the items on the leftmore.

11. Thanks for Coming Out Tonight Don’t forget to complete an evaluation on your way out the door! (kidding!)

12. Traditional Building of an Application Iteration 5 User Interface Layer BV = 100% Iteration 4 (whatever) BV = 0% Iteration 3 Business Logic Layer BV = 0% Iteration 2 0% VALUE Data Access Layer BV = 0% Iteration 1 Database BV = 0%

13. Agile Building of an Application Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 UI UI UI UI UI (whatever) (whatever) (whatever) (whatever) (whatever) 60% VALUE Business Logic Layer Business Logic Layer Business Logic Layer Business Logic Layer Business Logic Layer Data Access Layer Data Access Layer Data Access Layer Data Access Layer Data Access Layer Database Database Database Database Database BV = 20% BV = 40% BV = 60% BV = 80% BV = 100%

14. Another way to Visualize this Relationship Business Value of Work Executed Over Time

15. Traditional Application Development Horizontal Layers of Functionality • Build from the Ground Up • Lower Layers ‘Baked’ • Expensive to Change Later • No Penalty for Tight-Coupling

16. Traditional Application Development Much Work Remains to Be Done Before We Can Announce Our Total Failure to Make Any Progress

17. Traditional Application Development Complexity

18. Traditional Application Development Business Value ZERO!

19. Traditional Component Stabilityduring Project Lifecycle Done This model is an unattainable hypothetical that isn’t borne out by experience Percent Stability over the Life of the Project (100% = totally stable component)

20. Traditional Component Stabilityduring Project Lifecycle …or here… …or here… Something always happens here Done The Point: This model is an unattainable hypothetical that isn’t borne out by experience  …or here… …or here… …or here… …or here! …or here… Percent Stability over the Life of the Project (100% = totally stable component) …or here… …or here…

21. Agile Application Development Vertical Slices of Functionality

22. Agile Application Development Penalty for Tight Coupling

23. Agile Application Development No BDUF Required

24. Agile Application Development

25. Agile Component Stabilityduring Project Lifecycle Everything maintains a similar level of stability until the end of the project Done Nothing is inviolate for change Solution can adapt to changing conditions as needed Percent Stability over the Life of the Project (100% = totally stable component)

26. Agile vs. Traditional Methodologies Chaos is BAD!

27. Agile vs. Traditional Methodologies Cowboy Coders!

28. Agile vs. Traditional Methodologies Tools to Manage Chaos

29. Agile vs. Traditional Methodologies Perfect Scope

30. Agile vs. Traditional Methodologies Building the Thing Right…

31. Agile vs. Traditional Methodologies …Building the Right Thing! Building the Thing Right…

32. Why the Focus on Tests? Iteration 1 Iteration 5 UI UI High rate of Change to all components always (until done!) (whatever) (whatever) Business Logic Layer Business Logic Layer Data Access Layer Data Access Layer Database Database BV = 20% BV = 100%

33. Surviving the Chaos: Feedback Loops

34. Feedback Loops: Examples • Unit Tests • Rapid feedback on the impact of my own changes • If manual testing is req’d to validate every change, then the cost of change becomes too high to consider making it • Continuous Integration • Rapid feedback on the impact of everyone else’s changes • Duration between breaking changes and awareness of issue is zero! • Iterations/Sprints/Intervals/Whatever • Stakeholder feedback on the impact of changes • Confirm/Verify/Validate direction of solution

35. Different Solutions to The Same Problem: Change • Traditional Software Development Approach • Assumes change is avoidable • Tries to manage change by sufficient pre-planning and design to avoid change altogether • BDUF approach • Treats the process of constructing software as if it’s a building construction project • Wrongmetaphor • Agile Software Development Approach • Assumes change is inevitable and unavoidable • Assumes its impossible (or at least impractical) to attempt to plan-around or design-around change • Tries to manage change by ensuring that the software remains flexible enough to respond to the change • Ensures that sufficient tooling, process, and methods are in place to allow response to change within the context of an incredibly tight feedback loop

36. Software Development

37. Estimation During ourJourney of Discovery

38. Estimation • Wikipedia: Estimation is the calculated approximationof a result which is usableeven if input data may be incomplete or uncertain. • Problem is that estimates become a unbreakable schedule, where any deviation is considered bad

39. Problem #1 with Estimates • Estimate for our project: • 1 month for design and architecture • 4 months for development • 1 month for testing • Scenario: • Your first estimate is wrong by 1 week (design) • What do you do???

40. The Estimation Problem • When you come up with a project idea, your first estimate is off by +/ 4x • Not enough details are known • Traditionally too much time is spent on building a specification which is not complete • Again, not enough details are known • As time progresses, more details emerge about the system and its details • The cone of uncertainty

41. Cone of Uncertainty

42. Agile Estimation • Wikipedia: Estimation is the calculated approximationof a result which is usable even if input data may be incomplete or uncertain. • Problem is that estimates become a unbreakable schedule, where any deviation is considered bad • Agile Estimation throws this logic away and always re-estimates a project after each iteration • Different value system: deviations are not deviations, they are more accurate estimations • Uses the cone of uncertainty to your advantage

43. How to Estimate • User Stories • Story Points • Product Backlog • Velocity • Re-estimation

44. User Stories • Users break down the functionality into “User Stories” • User Stories are kept small • User Stories include acceptance criteria • Mike Cohn suggests: • As a (role) I want (something) so that (benefit).

45. User Story Modeling Narrative: (Who) wants (what) so that (why) • A story is a conversation starter, and gets more detailed over time

46. User Story Modeling GOOD: Billing wants to see a summary page of all unpaid accounts, so that they can collect payments. BAD: Users want rounded corners on the search button. Our company wants a new website to increase sales. • Good stories satisfy INVEST: • Independent • Negotiable • Valuable • Estimable • Small • Testable

47. Story Points • Break down user stories to units of relative size • So you can compare features • Alternative to time • Story Points are not a measurement of duration, but rather a measurement of size/complexity • Start with 1 standard feature and then other features are either 1x, 2x, etc larger or smaller than that relative feature in size/complexity

48. Product Backlog • All User Stories are put into a bucket • This represents all of the tasks for the project (work items) • Backlog items have estimates! • Remember this estimate is not time based, but point based • Backlog can also contain the item priority

49. Iteration 1 • Developers will commit to ## story points • Warning, they will usually over commit! • After the end of Iteration 1, you have your first Velocity measurement

50. Team Velocity • Velocity is the number of story points per iteration completed • You calculate velocity to predict how much work to commit to in an iteration • Velocity only works if you estimate your story points consistency • Over time you will know: team has a velocity of 32 story points per iteration • Over time this will self-correct • Over time you will be able to predict the project schedule (and release)