1. Columbia, Maryland - Summer 2011 Introduction to Agile Principles, Practices, and Processes Steve Bohlen Senior Software Engineer SpringSource/VMware

2. Columbia, Maryland - Summer 2011 Do I suck? Let me (and the world) know! http://spkr8.com/t/7941

3. Columbia, Maryland - Summer 2011 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. Columbia, Maryland - Summer 2011 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. Columbia, Maryland - Summer 2011 RAD Controls for ASP.NET AJAX RAD Controls for Silverlight RAD Controls for Windows Phone RAD Controls for Winforms RAD Controls for WPF Telerik Reporting Telerik OpenAccess ORM Telerik JustCode Telerik JustMock Telerik Extensions for ASP.NET MVC Test Studio Express Telerik TeamPulse Telerik Test Studio Sitefinity CMS Telerik JustDecompile C#/VB.NET Converter ASPX to Razor Converter

6. Columbia, Maryland - Summer 2011

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. Columbia, Maryland - Summer 2011 What is Agile (and Why)?

9. Columbia, Maryland - Summer 2011 “Courage is the power to let go of the familiar.” -Raymond Lindquist

10. Columbia, Maryland - Summer 2011 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 interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

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

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

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

14. Columbia, Maryland - Summer 2011 Business Value of Work Executed Over Time Another way to Visualize this Relationship

15. Columbia, Maryland - Summer 2011 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. Columbia, Maryland - Summer 2011 Much Work Remains to Be Done Before We Can Announce Our Total Failure to Make Any Progress Traditional Application Development

17. Columbia, Maryland - Summer 2011 Complexity Traditional Application Development

18. Columbia, Maryland - Summer 2011 Business Value Traditional Application Development

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

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

21. Columbia, Maryland - Summer 2011 Agile Application Development Vertical Slices of Functionality

22. Columbia, Maryland - Summer 2011 Agile Application Development Penalty for Tight Coupling

23. Columbia, Maryland - Summer 2011 Agile Application Development No BDUF Required

24. Columbia, Maryland - Summer 2011 Agile Application Development

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

26. Columbia, Maryland - Summer 2011 Agile vs. Traditional Methodologies Chaos is BAD!

27. Columbia, Maryland - Summer 2011 Agile vs. Traditional Methodologies Cowboy Coders!

28. Columbia, Maryland - Summer 2011 Agile vs. Traditional Methodologies Tools to Manage Chaos

29. Columbia, Maryland - Summer 2011 Agile vs. Traditional Methodologies Perfect Scope

30. Columbia, Maryland - Summer 2011 Agile vs. Traditional Methodologies Building the Thing Right…

31. Columbia, Maryland - Summer 2011 Agile vs. Traditional Methodologies …Building the Right Thing! Building the Thing Right…

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

33. Columbia, Maryland - Summer 2011 Surviving the Chaos: Feedback Loops

34. Columbia, Maryland - Summer 2011 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. Columbia, Maryland - Summer 2011 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 Wrong metaphor 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. Columbia, Maryland - Summer 2011 Software Development

37. Columbia, Maryland - Summer 2011 Estimation During our Journey of Discovery

38. Columbia, Maryland - Summer 2011 Estimation Wikipedia: Estimation is the calculated approximation of 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

39. Columbia, Maryland - Summer 2011 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. Columbia, Maryland - Summer 2011 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. Columbia, Maryland - Summer 2011 Cone of Uncertainty

42. Columbia, Maryland - Summer 2011 Agile Estimation Wikipedia: Estimation is the calculated approximation of 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. Columbia, Maryland - Summer 2011 How to Estimate User Stories Story Points Product Backlog Velocity Re-estimation

44. Columbia, Maryland - Summer 2011 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. Columbia, Maryland - Summer 2011 User Story Modeling Narrative: (Who) wants (what) so that (why) A story is a conversation starter, and gets more detailed over time

46. Columbia, Maryland - Summer 2011 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. Columbia, Maryland - Summer 2011 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. Columbia, Maryland - Summer 2011 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. Columbia, Maryland - Summer 2011 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. Columbia, Maryland - Summer 2011 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)

51. Columbia, Maryland - Summer 2011 Calculating Team Velocity Select a regular time period (iteration length) over which to measure Velocity Add up the story points of the stories 100% completed At the end of the iteration, the figure you have is your Velocity You can then use your Velocity as a basis for your future commitments

52. Columbia, Maryland - Summer 2011 Re-estimation As you complete more iterations, your velocity will change – Velocity changes because of minor inconsistencies in the story point estimates – Team velocity will typically stabilize between 3 and 6 iterations Re-estimation of the entire project happens after each sprint – New Velocity – New story points added and removed (completed) – Use the cone!

53. Columbia, Maryland - Summer 2011 Bites at the Apple

55. Columbia, Maryland - Summer 2011 Test-Driven Development A Feedback Loop for the State of My Code

56. Columbia, Maryland - Summer 2011 The Rationale for Unit Tests 99 little bugs in the code, 99 bugs in the code — We fixed a bug, compiled it again, 101 little bugs in the code ♫

57. Columbia, Maryland - Summer 2011 The Rationale for Unit Tests Debatable Software Engineering ‘Facts’ (Agile/XP/SCRUM/etc.) is better than (Agile/XP/SCRUM/etc.) Test-first (TDD?) is better than Test-After Non-Debatable Software Engineering Facts: There will always be bugs Complex programs have more bugs than simple programs Code is more maintainable when its divided into bite-sized chunks The cost of fixing a bug escalates non-linearly over time as the project progresses

58. Columbia, Maryland - Summer 2011 ‘Code Complete’ Defect Cost Graph

59. Columbia, Maryland - Summer 2011 Allocation of Developer Effort

60. Columbia, Maryland - Summer 2011 What is Test-Driven Development? Testing while coding not before or after

61. Columbia, Maryland - Summer 2011 What is Test-Driven Development? Think “Test-Driven Design” or “Specification-Driven-Development” Consider your design from the perspective of the consumers of your methods, classes, etc. Outside-in design instead of Inside-Out design

62. Columbia, Maryland - Summer 2011 What is Test-Driven Development? “How-Do-I-Use-This-Driven-Development” For every line of code you write, ask yourself a simple (but powerful) question: “HOW WILL I TEST THAT?”

63. Columbia, Maryland - Summer 2011 What about… Costs Additional time spent on code that isn’t part of delivery.

64. Columbia, Maryland - Summer 2011 What about… Costs We are programmers, not testers! We should concentrate on developing features, not testing!

65. Columbia, Maryland - Summer 2011 What about… Benefits Every class and method immediately has at least TWO consumers: Your APP and your TEST!

66. Columbia, Maryland - Summer 2011 What about… Benefits Better-isolated code leads to easier to extend, enhance, replace, maintain (lifecycle costs)

67. Columbia, Maryland - Summer 2011 What about… Benefits Waiting until code is written to write the tests often means hard (impossible?) to test code!

68. Columbia, Maryland - Summer 2011 What about… Benefits Less likely to write code that you eventually don’t need Write nothing that you think you will need (YAGNI – You Ain’t Gonna Need It!)

69. Columbia, Maryland - Summer 2011 Of course you can't count on tests to find everything. As it's often been said: tests don't prove the absence of bugs. However perfection isn't the only point at which you get payback for a self-testing build. Imperfect tests, run frequently, are much better than perfect tests that are never written at all. - Martin Fowler

70. Continuous Integration A Feedback Loop for the State of my Whole Development Team

71. Columbia, Maryland - Summer 2011 Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. --Martin Fowler

72. Benefits of Continuous Integration Broken build Failed tests Can’t deploy Shorten feedback loop Exercise whole build and deployment process Reduce risks Unit, integration, functional testing Code metrics Code conformance Provide confidence of quality

73. Columbia, Maryland - Summer 2011 Components Background process Web site Notification (email, system tray, RSS, etc.) CI Server Compile Deploy Run tests Build Scripts

74. Columbia, Maryland - Summer 2011 Manage Dependencies Consider adding 3 rd party tools to SCC Add 3 rd party libraries to SCC – Commit binaries so that you don’t need to build these every time. – Prefer a public release. Avoid custom changes. – Document clearly which version you use.

75. Columbia, Maryland - Summer 2011 Oops, Steve Broke the Build again! Build status must be visible Use the systray app for your CI server Consider adding the Build Dashboard to an “Information Radiator” Some have used ambient lights, lava lamps, or even songs to let the whole team know when a build breaks

76. Columbia, Maryland - Summer 2011 Notifications EmailsSystem Tray utilities (CCTray, CCMenu, etc.)RSS feedText Message

77. Columbia, Maryland - Summer 2011 Notifications – Lava Lamps http://agileworks.blogspot.com/2009/02/lava-lamp-with-cruisecontrol.html

78. Columbia, Maryland - Summer 2011 Notifications – iPhone app

79. Columbia, Maryland - Summer 2011 Getting Started with CI Compile-Only builds can work as “training wheels” for a team that is new to CI. Add metrics early so that you can measure your progress as you add automated testing. Add automated tests ASAP. Make a clear distinction between automated Unit Tests and Functional Tests. Automate deployment.

80. Columbia, Maryland - Summer 2011 Quality in Depth Compilation Unit Testing Functional/UI Testing Code Metrics Deployment

81. Columbia, Maryland - Summer 2011 Extending the Value of the Build NUnit, MbUnit, xUnit.NET, MSTest PartCover, NCover, OpenCover, Clover.NET NDepend, Structure101 Simian, FxCop StyleCop

82. Columbia, Maryland - Summer 2011 Wrap Up (I thought we’d never get here!)

83. Columbia, Maryland - Summer 2011 Software Development

84. Columbia, Maryland - Summer 2011

85. Introduction to Agile Principles, Practices, and Processes fini