Basic introduction to Agile Methodology from the 2009 Saint Louis Day of Dot Net. Supplement to 2010 STLDODN Presentation for newcomers to the agile methodology

1. Basic Stretches An introduction to Agility Brian Blanchard Interim CIO / Executive Consultant Lagovent / Lagovent Ventures Email: Brian@devrevival.com Blog: www.devrevival.com Bio: www.brian-blanchard.com

2. Agenda Next ->

3. Quick History Lesson Where did agile come from?

4. History Lesson (pre-1970) Wild West for fortune 500 companies Our forefathers are Geeks Nerds Challenged cultural norms Didn’t merge with the business - Impossible to manage Inconsistent completion rates They failed regularly: 80 – 90% Failure rate Next ->

5. History Lesson (1970 – Today) Waterfall: Serial method of software management created by Winston Royce Goal: Mold dev. into a manufacturing model Produce consistent, manageable outputs Control the geeks Create development assembly lines Outcome: Major increases in productivity Failure dropped to 70% failure!!! Fatal Flaw Does not handle change well Next ->

6. History Lesson (1999 – Future) Agile: Roots in Japanese models for efficiency Lean, Kanban, Kaizan, etc… Iterative methods in production took root in IT Goal Treat dev. like a Product Development/R&D unit Allow developers to lead development Accept that IT is as much art as it is science Demonstrate that the future of IT is found in its ability to drive change Outcome Increased productivity Failure rate decreased to 24% in many studies. More manageable code bases Average Agile codebase is 20 - 40% smaller than similar waterfall products Increase in developer retention Engaged development teams are happier Increased business value 30 – 50 % reduction in time to market 200% increase in innovation & tech. capability Next ->

7. Comparison to Waterfall Handling failure in an Agile world

8. Reason for Waterfall Failure Moore’s Law: The number of transistors on a chip doubles every 24 months Universal Law: Change Assumptions Facts (Moore’s Law & Universal Law) Requirements are perfect Tech. is stable, mature, well known All new or unknown challenges are solved before dev. begins. Repetition of a known process. Application development aims to hit a fixed target Customer demand grows Tech. capabilities grow New platforms create new challenges & opportunities throughout dev. cycles Dev. strive to automate anything repetitious Application development is a moving target based on market demand and growth Next ->

9. 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 Working software Customer collaboration Responding to change Processes and tools Comprehensive documentation Contract negotiation Following a plan over Next ->

11. Change the plan

12. Feedback loop

13. Embrace improvement

14. More feedback

15. Continue to change slowly

16. Embrace failure early

17. Become responsive to changeNext ->

18. What is Agile?

19. What is Agile? Change: It is change, continuing change, inevitable change that is the dominant factor in society today. No sensible decision can be made without taking it into account. …Isaac Asimov Agile is a conceptual framework that supports & is defined by several methodologies. All of which exist to steer change. Common attributes: Embrace change throughout the development cycle Iterative or incremental development - Timeboxing Focus is placed on creating working products Product creation is driven by the customer Work is completed by collaborative, self-organized teams General focus: Producing business value rapidly Lean thinking to remove waste and improve the journey Next ->

20. What is Agile? – Agile Methodologies Scrum Prioritized backlog Daily standup meetings Demo after each iteration Correct the process through lessons learned XP Communication, simplicity, feedback, and courage Requires TDD, refactoring, pair programming, continuous integration, open workspaces, and automated acceptance tests Lean Move closer to customer Shorter cycles Eliminate waste Decisions are made at the last responsible moment Empower the team build in integrity Next ->

21. Agile Myths & Misconceptions

22. Agile Myths & Misconceptions Agile means no structure & no management Agile’s structure is well defined and easily managed Agile means no discipline Agile developers must be more disciplined to succeed Agile is ad-hoc, we have no plan Agile does not support development without planning Agile does infuse flexibility into the plan Agile creates degraded code bases that are destined for collapse In Agile, quality is a way of life not an after thought Code ownership throughout the team creates higher quality code Next ->

23. Agile Myths & Misconceptions Agile is all about paired development Some methodologies employ paired dev. techniques to improve quality, but that does not summarize Agile Agile is a cult / religion Agile is a proven methodology supported by more than statistics collective for more than a century. All of which demonstrate consistent, improvement metrics. Employing Agile or other lean management methodologies should be done as a part of a planned, calculated strategy to improve productivity and sustainability. Next ->

24. Agile Advantages Why Agile

25. Agile Advantages – Iterative Release Cycles Smaller batches Higher quality Increased feedback Ease of adjustment Increased customer satisfaction Frequent releases Reduced time to market Regular regression testing Better team collaboration Avoids release based conflicts Gauge true value faster Compatible with Moore’s Law and Universal Laws of Change Next ->

26. Agile Advantages – Increased business value Supports IT’s shift from old model People/Process/Technology to Value/People/Process Increase innovation Business leaders (Product Managers) guess what customers need Active customers know what they need Reduce IT investment Iterative releases allow business to test theories and adjust investments Focus on customer need reduces excessive features Next ->

27. Agile Advantages – Increased quality Less Code / Less Defects: Industry average: 15 – 50 defects per 1,000 lines of code Agile creates more features with less code Code ownership Responsible owners write better code Cost of change curve Next ->

28. Agile Advantages – Delayed technical decisions Absolutes are often false Uncertainty is acceptable Emergence is good Absolutes generate waste Delayed technical decisions Decisions based on absolutes are often poor decisions Avoid technical lock-in Creates additional options Mitigates risk Reduces complexity Reduces management responsibilities Steer technical improvement Rather than controlling & planning Next ->

29. Agile Advantages – Increased visibility Stakeholders are peers in the team Unnecessary decisions are adverted Necessary decisions are made faster Iterative releases Clear examples of work completed / eliminates guest-imated completion times Visible examples of customer adoption during development Create check points to certify completion Stakeholders can steer the ship Rather than planning the course Next ->

30. Agile Shortcoming Why isn’t Agile everywhere

31. Agile Shortcomings – Lack of expertise Lack of expertise / Self proclaimed experts You wouldn’t build a plane without consulting an expert Why would you rebuild your organization without an expert Forrester 2008 Agile Survey 33% using some form of Agile 10% of “Agile” IT teams consider themselves “true practitioners” 35% using a waterfall approach Organizations are more interested in optimizing their processes than defining or understanding them in the first place. New EDS ad. “We build planes in the sky” Next ->

32. Agile Shortcomings – Corporate resistance Agile methodologies change the way business is conducted Agile requires a fusion of IT and Business practices Value / People / Process model “Customers” must be active in the development process At some point the Agile approach will appear to fail People will resist Agile Change without proper executive support/understanding will be quickly terminated Next ->

33. Agile Shortcomings – Scalability concerns Enterprise Agile is a difficult concept Implementing a new methodology in the enterprise takes time Ex: IBM converted 25,000 developers to Agile Challenges: 5 year completion (2002 – 2007) Several $million invested in the methodology conversion High degree of risk involved in this conversion Required support from several teams Executive sponsors Architecture committee Agile coaches Trust from business leaders Final result Net return of $4 per $1 invested 400% ROI in 7 years ROI continues to grow Next ->

34. Life as an Agilist What can I expect?

35. Life as an agilistWhat can I expect? Before an Iteration: Iteration Planning: No specs / just user stories (feature requests) Discuss the stories with the customer or product Iteration planning can last a few hours Build a plan May include UML, white boarding, defining unit or functional tests, etc… Plans / Estimations: You will make some decisions w/ little information You may have to give rough estimates They will be wrong. It’s ok. You may have to learn a new way to estimate. Next ->

36. Life as an agilistWhat can I expect? During an Iteration: Accountability: Meet with the team at least once a day 5 minute standup meetings: What was completed today? What roadblocks need to be resolved? The team: Delivers code in rapid cycles. Possibly once a week. Get’R’Done mentality. Open to discussion (often working in “bullpens”) Development: Working features not partial tasks Quality is a way of life. Responsible code ownership Next ->

37. Life as an agilistWhat can I expect? After an Iteration: Review: Show the customer Release the product New ideas Concerns The journey: Development is a journey not a destination Share lessons learned Help the team improve Improve the process Next ->

38. Advanced Discussions / Comparisons Concepts that challenge traditional thinking

39. Internal customers Business leaders/product managers Guess the needs of users Guesses may lead to adoption Guesses will bloat the application and increase complexity Requested features may produce revenue External/True customers Actual system users Understand their own needs Clear needs will lead to innovation Known needs will streamline the application Necessary features will produce revenue immediately Advanced Discussions – Who’s the customer Next ->

40. Specs / Requirements 10 or more pages Attempt to answer every question that could be asked about a feature. Very detailed Extensive technical details Limit creative input Serves internal customers User Stories 3 – 5 sentences Attempt to explain the basic need at the highest level Only high level detail No technical details Maximize creative input Serves True customers Advanced Discussions – What are user stories? Sample User Story: Search for products. The user wants to view a list of products. The application asks the user to select attributes of a product (price, color, etc…). After the user specifies the search criteria, the application displays a list of products that match the desired attributes. Next ->

42. Embrace customer feedback

43. Applaud team member feedback

44. Openly accepting and encouraging feedback avoids the internal group think that kills products

45. Encourage feedback about the product & processes at the end of each iteration.

46. Work quickly to incorporate feedbackNext ->

47. Advanced Discussions – Testing Agile development does not allow for the quality control cycles seen in a typical waterfall development. It requires new methods for managing product quality. Old models: Testers are often second class citizens Testers write all tests Testing occurs in the last 10% of a project Defects caught downstream are costly and time consuming Only critical defects are addressed before release Agile models: Testers are always apart of the team Developers and testers partner to complete testing. I.E. TDD, Unit tests, & Test repositories Testing occurs prior to the completion of each iteration Defects caught early can be resolved quickly and easily I.E. Continuous integration & daily meetings All defects are accounted for prior to release Next ->

48. Advanced Discussions – Estimation Estimates created by a group of direct contributors are more accurate than those from business leaders or IT managers. In Agile, you do not estimate time. Instead you estimate the size, complexity, or risk of a story. Overtime, a consistent velocity is established. The velocity per sprint will allow the scrum master to estimate time. Size Estimation techniques: Story points: Estimates are based on risk and complexity not time. The more complex or risky a request is, the more story points it will consume. Power of Two: Team members assign each user story a point value between 1 and 8. 2 is twice as complex or risky than 1. 4 is twice as risky as 2. 6 is twice as risky as 4. Etc… Scrum poker: The scrum team “votes” on the story points each user story will require. If the vote is not unanimous, the scrum master may decide to use the highest estimate. Some scrum masters will ask team members to discuss the story, followed by a revote. Usually in either scenario, the highest point value is used as the estimate. Next ->

49. Advanced Discussions – Metrics To truly accept agile methodologies, you must accept that development does not adhere to old business models. It requires a new management model & new metrics. Key metrics: Earned value: A measurement of the value created for the business by a given feature, iteration, project, and/or product. Monitoring this metric at each level, after each iteration helps to correct misconceptions regarding adoption, revenue, usability, market presence, etc… Velocity: The amount of software a team can create in a given iteration. This is not an estimate of time, it is a gauge of forward motion. It is used to determine if the team can truly meet the commitments made during each iteration. It is also used to set iteration and release expectations. Burn Down: The measurement of the features completed over time. Demonstrates the amount of software created against the amount requested. Used to monitor development capacity. Burn Up: The measurement of features requested over time. Demonstrates the growth of the applications scope over time. In a waterfall project this is the dreaded “Scope Creep”. In Agile projects, this is applauded innovation. Used to monitor product growth. Next ->

50. Advanced Discussions – Collective Code Ownership In an agile environment, the team owns the code. Effective Agile developers must let go of ego and share their code. Agile ownership rules: Anyone can make necessary changes anywhere Everyone is responsible for fixing problems they find Be a responsible owner of the code Re-factor dirty code Follow coding standards Apply naming conventions If you do not know the code base, partner with the product expert If the product expert does not exist, or is unavailable: Assume prior developers followed the rules of responsible code ownership Unit test everything you write – No Exceptions Next ->

51. Questions & Answers Basic Stretches An introduction to Agility Brian Blanchard Interim CIO / Executive Consultant Lagovent / Lagovent Ventures Email: Brian@devrevival.com Blog: www.devrevival.com Bio: www.brian-blanchard.com