1. How can I be agile and still
satisfy the auditors?

2. © 2011 VersionOne 2
Welcome & Introductions
• Steve Ropa
– Steven.ropa@versionone.com
– Agile Coach
– Certified Scrum Master
– Certified Scrum Product Owner
– 19 years software development
• 11 years programming
• 8 years director of development
– 10 years Agile experience
• XP
• Scrum
– http://blog.versionone.com/blog/agile-
musings

3. © 2011 VersionOne 3
Agile Values
• Individuals and Interactions OVER Processes and
Tools
• Working Software OVER Comprehensive
Documentation
• Customer Collaboration OVER Contract Negotiation
• Responding to Change OVER Following a Plan

4. © 2011 VersionOne 4
That is to say…
• While there is value to
those items on the
right, we value the
items on the left more.
• So there is no law
saying that you may not
do those items on the
left – we won’t even
withhold your merit
badge

5. © 2011 VersionOne 5
The Big Fallacy..
• We are Agile
• We don’t need documentation

6. © 2011 VersionOne 6
The Other Fallacy..
• We are {CMMI;ISO;HIPAA;EIEIO} compliant
• We need reams of documentation

7. © 2011 VersionOne 7
What about auditing?
• Most audits are based on a
very specific set of
requirements, to address a
specific need or vulnerability
– Sarbanes-Oxley
• Confirm financial calculations
are correct
• Ensure compliance with
visibility
– PCI
• Ensure software is secure
• Protect private, personally
identifiable information
– HIPAA
• Protect privacy of health
information

8. © 2011 VersionOne 8
Auditable/Standard specific stories
• “As a healthcare customer, I
can use the OnlineRx
system in a secure manner,
so that I am confident that
my personal information
will not be accessible by the
public”.
– This may be an epic,
perhaps break down into
specific security measures
– Consider citing the specific
standard and requirement.
– Be sure to write acceptance
tests that confirm, and are
automated

9. © 2011 VersionOne 9
Automated Acceptance Tests
• The best possible checklist
on standards
• Write automated tests that
are run *every* check in
– Verify each standard is
adhered to
– Break the build when they
are not
• Fitnesse is a great example
of automated acceptance
tests
• These tests become ideal
tools for documenting each

10. © 2011 VersionOne 10
Definition of Done
• Teams need to agree
on what “done” means
for each story.
– Usually starts with all the
tests passing
– Add a standard that
stories aren’t done until
audit requirements are
met

11. © 2011 VersionOne 11
Agile and CMM(I)
CMM(I) KPA’s Level 2 Agile Practices
Requirements Management •User stories
• product backlog
Software Project Planning •Release planning
•Iteration planning
Software Project Tracking and
Oversight
•Daily stand-ups
•Burndown charts
•Iteration reviews.
Software subcontract
management
Not addressed
Software Quality Assurance •Automated user acceptance
tests
•Automated unit tests
Software Configuration
Management
Continuous Integration

12. © 2011 VersionOne 12
Requirements Management
• A well maintained
product backlog is a
list of every user story
and feature that is in
the system
• User stories include the
acceptance criteria that
define the story, and
many times will also
include the tasks that
satisfy the actual
criteria

13. © 2011 VersionOne 13
Software Project Planning
• Release Planning provides a vision early on
as to what will be delivered.
– When a release will happen is fixed, thus
removing a large amount of uncertainty
• Sprint planning is a tight, well defined
feedback loop
– Change is recognized early and implemented
quickly
– Teams that reach a sprint rhythm are highly
effective and repeatable

14. © 2011 VersionOne 14
Software Project Tracking and Oversight
• Daily stand-ups provide
near instantaneous
feedback
• Sprint burndown shows
status and projected path
to completion of stories
• Iteration reviews show
working software
• Retrospectives proved a
continuous improvement
mechanism

15. © 2011 VersionOne 15
Software Quality Assurance
• Automated Acceptance Tests
– The test have to pass every time, not just the first time
– Broken tests are found quickly, before the system can reach
entropy
• Automated Unit Tests
– Code is rigorously exercised continuously
• Merciless refactoring
– Design is improved continuously

16. © 2011 VersionOne 16
Software Configuration Management
• Continuous Integration
– Code is checked in several times a day
– Builds and tests are run every time
• Continuous delivery
– Working software is available all the time

17. © 2011 VersionOne 17
What about Level 3?
• Most level 3 KPA’s are organizational in nature
– Process focus
– Training program
– Intergroup coordination
• Agile practices are exceptionally well suited to the
organizational changes and attitudes that will
satisfy these requirements.

18. © 2011 VersionOne 18
The bottom line
• CMM(I) level 2 is a “slam-dunk” if
you are using agile practices
• CMM(I) levels 3 and 4 are highly
facilitated by the collaborative
nature of agile teams.
• Even level 5 gets a great jump
start from agile practices
– Defect prevention – unit tests, pair
programming coupled with
automated acceptance tests make
this a slam dunk also
– Other KPA’s are again more
organizational in nature at this level

19. © 2011 VersionOne 19
Requirements Traceability
• Early on, XP said “tear up the cards”
• Keep your stories somewhere
– Excel spreadsheets
– Project management tools
• You can still be agile with these tools, just
remember to keep it light.

20. © 2011 VersionOne 20