1. Auditing in an Agile Environment
Andres Camacho
August 2012

2. Agenda Intro to Agile Software Development Highlight practices
Things to look for in an audit
Questions
Debunk some myths along the way

3. access to all of their expenses and online accounts
Manilla
Security is top of mind at Manilla
Secure software development
Secure, one-stop “Digital Life Management Dashboard” that gives consumers simple, instant, direct
access to all of their expenses and online accounts

4. What happens when things change?
Waterfall
Standard waterfall software development
Along the way documents are created:
MRD (Marketing Requirements Document)
PRD (Product Requirement Document)
Design documents
QA Test plans
“Wicked Problem” – a term coined in the 1970s, a problem whose requirements and limitations cannot be entirely known before completion
What happens when things change?

5. Agile Software Development
Iterative
Working software over comprehensive documentation
Collaboration over contract negotiation
Responding to change
Early visibility
How does Agile reconcile with IT audits and secure software development?

6. Agile Software Development
User stories
Whole team
Backlog
Early visibility
Automated tests
Fast iterations
Continuous integration
Pair programming
User stories
Whole team
Backlog
Early visibility
Automated tests
Fast iterations
Continuous integration
Pair programming
User stories
Velocity
Whole team
Test driven development
Estimation session
Sustainable pace
Backlog
Daily standups
Early visibility
Automated tests
Simple designs
Fast iterations
Planning game
Continuous integration
Refactoring
Pair programming
Collaboration over contract negotiation
Many companies don’t implement all practices
We’ll cover a few and highlight things to look for in audits

7. User Story Unit of work Small, stands on its own two feet Estimable
Placeholder for a conversation
One of the hardest exercises for those new to Agile is breaking down big features into small stories
No front end vs backend
As a … I can … so that …

8. User Story Requestor of the story accepts
Owner of the story is the one who implements
Acceptor is not necessarily QA.
At Manilla blackbox,QA may come in after the fact

9. Story Workflow Started Finished
Delivered – Ready for Requestor to take a look in a staging environment
Rejected
Accepted

10. Backlog User stories that are ready to be implemented
Developers work next story in queue
No P’s
We use Pivotal Tracker

11. Pivotal Tracker Pivotal Tracker – Built from the ground up for Agile
Pivotal Tracker – 380,000 users

12. Git Standard source code control software for Ruby community
Github, social coding
Rigorous commit workflow
At Manilla we use enterprise GitHub
2 million projects, 1 million users
Is GitHub secure?

13. Commit Workflow All work done using feature branches Format:
feature Add_custom_reminders
feature branch
Commit hook ensures story id

14. Iteration Stories and bugs that are released to production
Stories labeled (tagged) by release date
We can always go back to Pivotal and see what was released on a particular date
When something goes wrong, always ask what changed?
Tagging iterations helps us trace back changes.

15. Release W TH F M T W TH F Production Staging
bug fixes
tag and release to production
bug fixes
Staging
release branch
feature branch
Stole from another presentation, won’t get into details
3 branches of code, called branches because they resemble branches on a tree
Blackbox QA, still a need at Manilla
Walk through release to production
Remember what I said about fast iterations?
Some companies do continuous deployment
----- Meeting Notes (7/13/12 14:43) -----
Can recall what happened on stories
Master
Staging branch merged
End of Iteration

16. Whole Team Hire generalists Everyone gets to work on everything
Automatic cross training
Small teams
Product/QA are part of the team
Team size: Enough to share a pizza – 4-8

17. Pair Programming 2 developers 1 story Built in code review
Built in cross training
Collaboration
Workspace is important: desks for easy pairing, large monitors, spare mice and keyboards

18. Collaboration

19. Pull Request
Request by a contributor to pull code changes into a codebase
Used extensively by open source projects
Adopted as a code review tool
We can’t always pair program

20. Pull Request

21. Automated Tests “pay me now or pay me more later”
Critical, especially with dynamic languages (Ruby, Python)
Unit tests, acceptance tests
Test Driven Development
At Manilla 3 lines of test code for every 1 line of code

22. Continuous Integration
Check in early and often
Automated builds and deployments
Keep the build fast
Everyone can see the results

23. Continuous Integration
Not only are tests automated but deployments are too
Java – compiling is a test
Dynamic language like Ruby/Rails no compile step, tests are critical
As a manager it is much easier to get Ruby/Rails dev to write tests.
The community is a big proponent

24. Early Visibility
Early visibility also means iterate fast, get your product out there
Minimum Viable Product – the minimum core set of features/functionality. Get it in front of users and have then give feedback.

25. Where is the documentation?

26. Documentation Tests serve as documentation
When tests fail they are described using plain English. Example.

27. Documentation New project, makes an HTML site by inspecting tests
Allows for test descriptions
Not documenting code here, instead documenting tests

28. Resources Manilla – http://www.manilla.com
Pivotal Tracker –
Github –
Relish -

29. My Background Degree in Finance, many courses in Accounting
Auditor for Price Waterhouse in San Jose, CA
Computer Science courses at San Francisco State
Positions at Price Waterhouse, NextCard, QRS, Yaga, Vinfolio, and Manilla