Adopting Agile


Published on

These slides quickly illustrate how you can successfully adopt Agile to improve your development efforts. In addition to discussing how and why teams are interested in Agile, it covers some of the challenges of adopting it and suggestions for ensuring success.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Adopting Agile

  1. 1. Adopting Agile Ensuring Success Copyright 2013 Coverity, Inc.
  2. 2. Today’s Reality More. Better. Faster. • Customers demand new, innovative features • And quickly • Features are often implemented in software • Size of software projects is exploding • And often includes third-party/open-source code • Security and stability cannot be compromised In other words: software organizations must provide more, with excellent quality, security, and stability, using reliably less time 2
  3. 3. Agile A popular way to address these challenges Many organizations are adopting practices commonly associated with Agile: • Development via rapid iteration over bite-sized, selfcontained work units rather than large process phases • Automated testing: unit, regression, etc. • Continuous integration builds • In some cases, even continuous delivery 3
  4. 4. Why Agile? Business Benefits: • More easily manage change • Better align IT and business objectives • Accelerate time to market Development Benefits: • Visibility: Discover problems sooner • Efficiency: Fix problems more quickly and easily • Predictability: Avoid late-stage schedule disruptions 4
  5. 5. Shorten Cycles, Distribute the Load Theme: Avoid large backlogs; get early feedback • Test code as it is written, minimizing significant last-minute disruptions Practice/Benefit Split development cycle into bite-sized sprints Improve responsiveness, predictability Developers code, test, design All team members are experts with the code; improve efficiency Use small, fast, automated tests like unit tests Get early feedback about whether the code is working properly Routinely integrate, build, test code changes Get early feedback about whether the product is in a working state 5
  6. 6. Adopting Agile We need to go Agile—it will solve our development problems! We can’t put the business on hold to rebuild R&D, Bob! 6
  7. 7. It’s Not Always Easy • Even with a plan and support, adopting Agile practices often encounters resistance • Business Risk: How to maintain developer productivity while onboarding testing responsibilities? • Culture: How to convince developers to actually write tests? • Adoption: How to enforce adoption of the new practices? • IT: How to manage infrastructure? • Politics: How to assure QA that their jobs are safe? • Governance: How to manage the transition to ensure it is successful? 7
  8. 8. Justifying Agile We can’t put the business on hold… 8 We don’t have to! We’ll ease in, starting with our new code and new projects.
  9. 9. Overcome the Resistance • Business Risk (productivity with new testing requirements) • Ease into Agile, e.g. focus on new code/projects first • It’s not all-or-nothing, so plan a transition • Culture (developers must write tests) • Enforce testing standards for important/high-risk code • Phased deployment convinces skeptics and provides escape hatch • Adoption (new practices stick) • Automate enforcement as part of standard process • Politics and Governance • Provide visibility into the new process • Reassure stakeholders—process enables them to fulfill their mission, e.g. independently verify quality or security; not police R&D 9
  10. 10. But…the Devil’s in the Details • How do you determine if code is sufficiently tested? • It’s not practical (or possible) to automate tests for all code • Are you testing all of the important code? • Are you wasting effort testing unimportant code? • How do you enforce testing of changes to legacy code? • You need to require tests for all important code • Without trying to boil the ocean • How do you eliminate manual interpretation and noise? • You need to reduce adoption barriers and increase confidence • Visibility without sufficient context is (worse than) useless 10
  11. 11. Is Code Sufficiently Tested? Sweet, safeClose() is fully tested now! I’m glad I don’t need to test that catch block—I’m not sure I can even trigger an IOException there. 11
  12. 12. Partial Visibility is Worse Than Useless Only 86% coverage for safeClose()? That untested 14% worries me… dbgStub() Why are we wasting time testing dbgStub()? 12 Hey Bob, we need to fix this!
  13. 13. Let Your Tools Do the Heavy Lifting • Leverage static analysis to get early feedback about common coding errors • No need to invest time writing test cases for these issues • It’s critical to automate, look for important problems and configure for minimal noise • Don’t simply measure testing coverage • Enforce a testing policy that focuses on the important/high-risk code • Focus on certain components, modules, classes or functions • Test all code impacted by recent changes • No need to test debug, logging or exception-handling code • Recognize field-tested code; consider code complexity • Leverage SCM systems (age, author), testing artifacts, etc. to improve accuracy and automation 13
  14. 14. Make It Easy On Developers Just add a test covering line 1084 and I’m golden. Glad I don’t need to test those aborts! Don’t need to be tested 14
  15. 15. Make It Easy On Developers • Automate, automate, automate • Use a consistent workflow for all types of issues • Generate prescriptive work items for identified problems • Automatically interpret and prescribe action • “Here is your problem. Do this to fix it…” • AVOID: “Does anything look wrong in this output? Don’t forget to check the build logs and the test output, too.” • Provide easy access to all information, especially the source code and context relevant to the problem • Automatically assign to appropriate team members for accountability • E.g. by most recent SCM committer, or component owner 15
  16. 16. Visibility With Context is Priceless Awesome progress on our improvement goals! Development is right on schedule 16
  17. 17. Visibility and Governance • Measure coverage in the context of your testing policy and definition of “important” and “high-risk” code • Eliminate manual interpretation • Measure performance against objective, meaningful standards • All stakeholders will understand the reports • Automate development testing in your process • Objective, meaningful assessments enable you to automate with confidence and accurately fail the build when something is wrong • Developers become accountable for code quality/security • Gain visibility into pending problems and completeness • Gain scheduling predictability 17
  18. 18. Bob, you did a great job fixing our development problems. I’m giving you a raise! 18
  19. 19. Want to try Coverity on your code? For a free trial, visit: