Presented at SFRuby July 21, 2010.

1. Bootstrapping Agile
Projects
Christian Nelson
Carbon Five

2. Who is Carbon Five?

3. Agile at Carbon Five
Born from the strong desire for a
collaborative process
Focus on delivering real (and visible) value
very quickly
Practicing variants of eXtreme Programming
since 2000

4. Agile Manifesto
2001
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.

5. What I value most...
Collaboration
Transparency (and Trust)
Build on Small Successes, Iteratively
Listen and Learn - Feedback Loop
Working Software
Reality Based and Sustainable

6. Truth about software
development
We believe developing software is an
empirical process; we experiment, observe,
measure, and react.
We want to use this to our advantage.
We have the tendency to live in a bubble; a
focus on customer-value with short iterations
helps keep us honest.

7. Strategy
Build the Smallest Whole1, then continuously
enhance the product.
Generate buzz and start identifying users.
Put the product in front of users as soon as
possible (and collect feedback).
Balance Vision and Feedback.
1. see also Minimum Viable Product

8. Sample Timeline

9. Sample Timeline
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ...

10. Sample Timeline
#
Features
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ...

11. Sample Timeline
#
Features
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ...
We are here!

12. Sample Timeline
#
Features
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ...
We are here!
M1: Smallest whole

13. Sample Timeline
M2: Visual design
#
Features
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ...
We are here!
M1: Smallest whole

14. Sample Timeline
M2: Visual design
#
Features
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ...
We are here! M3: Private beta
M1: Smallest whole

15. Sample Timeline
M2: Visual design
#
Features
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ...
We are here! M4: ???
M3: Private beta
M1: Smallest whole

16. Sample Timeline
Audience M2: Visual design
Size
#
Features
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ...
We are here! M4: ???
M3: Private beta
M1: Smallest whole

17. Kick Off Goals/Activities
Discuss process and development philosophy
Establish a clear theme and plan for the first
milestone, by...
Story writing and story mapping
Whiteboard wire-framing
Conceptual domain model
Understand roles and agree to responsibilities
Logistics (schedule meetings)

18. What’s a User Story?
A story describes a user-facing feature that
provides describable value.

19. User Stories
As a ___, I want to ___, so I can ____.
Stands up on its own with clear acceptance
criteria.
Typically take a couple of hours to a couple of
days to fully implement; they’re pretty granular.
Leave out the UI specifics, just capture intent
clearly and succinctly.
Size measured in points (on the fibonacci scale).

20. Defining the Smallest
Whole for M1
Identify differentiating features with laser
focus (leave out the rest)
Focus on one or two user activities
Strive for the simplest version of each story
Don’t waste time on duplicating functionality
Skip admin functionality and registration

21. Story Mapping

22. Roles
Product Owner
Developer
Designers (UX and Visual)
QA
Process Coach / Facilitator
User Testing Coordinator

23. Lifecycle of a Story
1. Written down and placed in the icebox [anyone],
2. Elaborated upon [product owner and designers],
3. Taskified and Estimated [developers],
4. Prioritized into the Backlog [product owner],
5. Implemented [developers and designers],
6. Accepted (or Rejected) [product owner],
7. QA ‘d [qa], and released to production

24. Velocity
The rate at which the team is able to deliver
bug-free, user-facing features. Measured in
points.
Used to estimate how many story-points can
be completed per iteration.
Chores don't directly provide user-value and
don't earn the team points.
Bugs are filled against accepted features and
don't earn the team any (additional) points.

25. Expectations of the
Product Owner
Channel all feedback and vision into a clear,
focused plan (set of stories).
Very responsive to ad-hoc questions; you
must be very available.
Willingness to ruthlessly prioritize.
Acceptance of delivered features (within a
couple of hours).

26. Timeline (micro-level)
Daily: Standup [15 mins]
Once per Iteration (weekly):
Demo [30 mins]
Review of Plan [30 minutes]
Once per Milestone (every ~2-3 weeks):
Kick-off [hours!]
Reflection [60 mins]
As needed: Working Sessions, Release Planning

27. Development Practices
Pair Programming
... most of the time.
Test Driven Development
... when not working on a spike.
Simple Design
... always.
Refactoring
... when a superior solution is clear and you feel
pain.

28. Final Words
The process evolves to suit the needs of the
project through feedback and regular reflection.
The challenge is almost never technical, it's
getting everyone working together really well
and keeping a clear, focused product vision.

29. Check out...
Pivotal Tracker Eric Ries - Lessons
pivotaltracker.com Learned
Carbon Five Story Jeff Patton - Story
Mapper Maps
trackerstorymaps.com
Steven Blank - Customer
Kent Beck - XP Development
Explained
Martin Fowler -
Mike Cohn - <all> Refactoring
Art of Agile - James 37 Signals - Getting
Shore Real

30. Carbon Five is hiring!
http://carbonfive.com/jobs
Recent Grads
Rails Developers
Awesome Java developers who want to learn
Rails
Mention SFRuby!

31. Questions?