Bootstrapping Agile Projects

Bootstrapping Agile Projects Christian Nelson Carbon Five

Who is Carbon Five?

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

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.

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

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.

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

Sample Timeline

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

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

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

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

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

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

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

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

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

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

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 speciﬁcs, just capture intent clearly and succinctly. Size measured in points (on the ﬁbonacci scale).

Deﬁning 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

Story Mapping

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

Lifecycle of a Story 1. Written down and placed in the icebox [anyone], 2. Elaborated upon [product owner and designers], 3. Taskiﬁed 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

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 ﬁlled against accepted features and don't earn the team any (additional) points.

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).

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!] Reﬂection [60 mins] As needed: Working Sessions, Release Planning

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.

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

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

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

Questions?

Bootstrapping Agile Projects

by xianpants

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 31

Statistics

Bootstrapping Agile Projects Presentation Transcript