1. Phoenix Scrum User Group Simplifying Scrum Online May 21 st 2009

2.  Privately funded technology company  Toronto based  Founded in 1999  Founders are serial entrepreneurs Rails shop focused on building internet businesses. We also do outsourced Rails development work Our process is Scrum and XP Brightspark – who we are

3. Build leading edge Internet businesses using core competencies in web application software development  Agilebuddy.com  Collectionbuddy.com  iStopOver.com Brightspark 3.0 – Our Mission

4.  20 year software veteran  Led Teams both large and small  Worked on many successful projects and some failed ones  Most of my career was based on Waterfall  Practicing Agile for almost 5 years  CSM certification Jack Milunsky – Little bit about myself

5. What is Agile  Agile = Scrum + XP for most companies practicing agile  PLUS Lean is creeping into the picture more and more now Agile means  Iterative incremental development  Engineering discipline (process and quality)

6. Two major Agile benefits:  Transparency  Means you get to see exactly where things are at all of the time  Rhythm (heartbeat)  Deliver soon and deliver often - this means you mitigate risk Most Important Agile benefits

7. Two major problems that kill productivity  Churn  Code quality/Technical debt Scrum helps mitigate this through:  Uninterrupted time for developers to get their work done  Build quality in right from the start Additional benefits

8. Lean thinking "Stop Starting, Start Finishing" “If you don’t know how to get the story out of the iteration – don’t let it in”

9.  Lean thinking  Minimize Work In Progress  Work in progress = Liability  Focus on cycle time rather than productivity  We ship every 2 weeks – DEPLOYED TO PRODUCTION  This means you can’t have too much in the pipeline  Fix the bugs when you find them Lean thinking “ Defect tracking systems are queues for partially done work” - Mary Popendiek

10. The biggest risks of All #1 There is no greater risk than delivering the wrong product Mitigating business risk…  Deliver early and often  Iterate, Inspect and adapt  Involve the customer and stakeholders

11. Technical debt #2 Technical debt can kill companies by painting them in a corner. Tell tale signs:  Features take longer and longer to get implemented  Releases have longer cycles  Ever increasing QA cycles  Increase release bug counts  Increase in support calls/emails  Unsatisfied customers  Internal Morale problems  Fewer individuals on the team that know the entire codebase

12. Technical debt Mitigating risks in regards technical debt What you want is an Agile Architecture and codebase  Strong engineering discipline – setting the dials to ten  Emergent Architecture – the antithesis of BDUF  Unit test coverage – strive for 100% we have 95% coverage  Pair programming  Definition of Done

13. Emergent architecture Make room on your backlog for refactoring 20% of our time devoted to refactoring out codebase every sprint  This requires discipline – so tempting not to do this  Requires buy-in from stakeholders  Ruthless focus on highest priority items

14. Results  First full release in 6 months  Started using Agilebuddy after 1 st sprint  No staging environment for 1 st version  New production builds deployed every 2 weeks  95% unit test coverage – Rails makes it real easy  No defined QA closure phase  Very low bug count  Highly Agile architecture and codebase  Fully automated continuous integration  Fully instrumented code

15. Our process – without fail Cadence!!!!  2 Week sprints  Mondays we plan  Fridays we deploy, demo’s an retrospectives Requirements, requirements  We really try hard to minimize the number of stories we throw into a sprint

16. Engineering discipline Our definition of “DONE” Coded to standards Documented Unit tested – Strive for 100% code coverage Functional tested Zero defect policy Deployed to production at the end of every sprint

17. T EST D RIVEN D EVELOPMENT What is it? Not just about writing tests first Red-Green-Refactor Cycle

18. T EST D RIVEN D EVELOPMENT Red Green Refactor 1.Write one test and make sure it fails 2.Write just enough code to make it pass 3.Refactor the code 4.Repeat

19. TDD is hard! T EST D RIVEN D EVELOPMENT Discipline Robustness Performance Exploratory Programming

20. TDD is hard!... But it’s worth it! T EST D RIVEN D EVELOPMENT Actually easier and faster than manual testing Safety net

21. Tools are important T EST D RIVEN D EVELOPMENT Autotest Mocking/Stubbing Continuous Integration

22. Miscellaneous T EST D RIVEN D EVELOPMENT What to test How to get your feet wet Don’t test what you didn’t write

23. Website: www.agilebuddy.com Blog at: blog.agilebuddy.com Acceptance Test Criteria