The document discusses the adoption of agile practices in software development to meet increasing customer demands for faster, high-quality features while managing security and stability. It highlights the benefits of agile, such as improved efficiency, better alignment between IT and business, and enhanced problem visibility. The document also addresses the challenges of transitioning to agile, including resistance from developers, managing productivity, and ensuring effective testing procedures.

1. Adopting Agile
Ensuring Success
Copyright 2013 Coverity, Inc.

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Visibility With Context is Priceless
Awesome
progress on our
improvement
goals!
Development is
right on schedule
16

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. Bob, you did a great
job fixing our
development
problems. I’m
giving you a raise!
18

20. Want to try Coverity on your code?
For a free trial, visit:
www.coverity.com