Simplifying Scrum Online
Phoenix Scrum User Group
May 21st 2009

Brightspark – who we are
 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 3.0 – Our Mission
Build leading edge Internet businesses using core
competencies in web application software
development
 Agilebuddy.com
 Collectionbuddy.com
 iStopOver.com

Jack Milunsky – Little bit about myself
 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

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)

Most Important Agile benefits
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

Additional benefits
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

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”

Lean thinking
 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
“ Defect tracking systems are
queues for partially done work”
- Mary Popendiek

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

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

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

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

Results
 First full release in 6 months
 Started using Agilebuddy after 1st sprint
 No staging environment for 1st 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

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

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

TEST DRIVEN DEVELOPMENT
What is it?
•Not just about writing tests first
•Red-Green-Refactor Cycle

TEST DRIVEN DEVELOPMENT
Red Green Refactor
• Write one test and make sure it fails
• Write just enough code to make it pass
• Refactor the code
• Repeat

TEST DRIVEN DEVELOPMENT
TDD is hard!
•Discipline
•Robustness
•Performance
•Exploratory Programming

TEST DRIVEN DEVELOPMENT
TDD is hard! ... But it’s worth it!
•Actually easier and faster than manual testing
•Safety net

TEST DRIVEN DEVELOPMENT
Tools are important
•Autotest
•Mocking/Stubbing
•Continuous Integration

TEST DRIVEN DEVELOPMENT
Miscellaneous
•What to test
•How to get your feet wet
•Don’t test what you didn’t write

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