Successfully reported this slideshow.

Agile and Auditors


Published on

Published in: Technology, Business
  • Be the first to comment

Agile and Auditors

  1. 1. How can I be agile and stillsatisfy the auditors?
  2. 2. © 2011 VersionOne 2Welcome & Introductions• Steve Ropa–– 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–
  3. 3. © 2011 VersionOne 3Agile Values• Individuals and Interactions OVER Processes andTools• Working Software OVER ComprehensiveDocumentation• Customer Collaboration OVER Contract Negotiation• Responding to Change OVER Following a Plan
  4. 4. © 2011 VersionOne 4That is to say…• While there is value tothose items on theright, we value theitems on the left more.• So there is no lawsaying that you may notdo those items on theleft – we won’t evenwithhold your meritbadge
  5. 5. © 2011 VersionOne 5The Big Fallacy..• We are Agile• We don’t need documentation
  6. 6. © 2011 VersionOne 6The Other Fallacy..• We are {CMMI;ISO;HIPAA;EIEIO} compliant• We need reams of documentation
  7. 7. © 2011 VersionOne 7What about auditing?• Most audits are based on avery specific set ofrequirements, to address aspecific need or vulnerability– Sarbanes-Oxley• Confirm financial calculationsare correct• Ensure compliance withvisibility– PCI• Ensure software is secure• Protect private, personallyidentifiable information– HIPAA• Protect privacy of healthinformation
  8. 8. © 2011 VersionOne 8Auditable/Standard specific stories• “As a healthcare customer, Ican use the OnlineRxsystem in a secure manner,so that I am confident thatmy personal informationwill not be accessible by thepublic”.– This may be an epic,perhaps break down intospecific security measures– Consider citing the specificstandard and requirement.– Be sure to write acceptancetests that confirm, and areautomated
  9. 9. © 2011 VersionOne 9Automated Acceptance Tests• The best possible checkliston standards• Write automated tests thatare run *every* check in– Verify each standard isadhered to– Break the build when theyare not• Fitnesse is a great exampleof automated acceptancetests• These tests become idealtools for documenting each
  10. 10. © 2011 VersionOne 10Definition of Done• Teams need to agreeon what “done” meansfor each story.– Usually starts with all thetests passing– Add a standard thatstories aren’t done untilaudit requirements aremet
  11. 11. © 2011 VersionOne 11Agile and CMM(I)CMM(I) KPA’s Level 2 Agile PracticesRequirements Management •User stories• product backlogSoftware Project Planning •Release planning•Iteration planningSoftware Project Tracking andOversight•Daily stand-ups•Burndown charts•Iteration reviews.Software subcontractmanagementNot addressedSoftware Quality Assurance •Automated user acceptancetests•Automated unit testsSoftware ConfigurationManagementContinuous Integration
  12. 12. © 2011 VersionOne 12Requirements Management• A well maintainedproduct backlog is alist of every user storyand feature that is inthe system• User stories include theacceptance criteria thatdefine the story, andmany times will alsoinclude the tasks thatsatisfy the actualcriteria
  13. 13. © 2011 VersionOne 13Software Project Planning• Release Planning provides a vision early onas to what will be delivered.– When a release will happen is fixed, thusremoving a large amount of uncertainty• Sprint planning is a tight, well definedfeedback loop– Change is recognized early and implementedquickly– Teams that reach a sprint rhythm are highlyeffective and repeatable
  14. 14. © 2011 VersionOne 14Software Project Tracking and Oversight• Daily stand-ups providenear instantaneousfeedback• Sprint burndown showsstatus and projected pathto completion of stories• Iteration reviews showworking software• Retrospectives proved acontinuous improvementmechanism
  15. 15. © 2011 VersionOne 15Software 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 reachentropy• Automated Unit Tests– Code is rigorously exercised continuously• Merciless refactoring– Design is improved continuously
  16. 16. © 2011 VersionOne 16Software 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. 17. © 2011 VersionOne 17What 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 theorganizational changes and attitudes that willsatisfy these requirements.
  18. 18. © 2011 VersionOne 18The bottom line• CMM(I) level 2 is a “slam-dunk” ifyou are using agile practices• CMM(I) levels 3 and 4 are highlyfacilitated by the collaborativenature of agile teams.• Even level 5 gets a great jumpstart from agile practices– Defect prevention – unit tests, pairprogramming coupled withautomated acceptance tests makethis a slam dunk also– Other KPA’s are again moreorganizational in nature at this level
  19. 19. © 2011 VersionOne 19Requirements 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, justremember to keep it light.
  20. 20. © 2011 VersionOne 20