#clegivecamp lessons learned with @BenWoz @MikeKvintus & @danshultz

Everyone I know that helped out at Cleveland’s GiveCamp this year had a great time. We helped out nearly 2 dozen non-profits, met new people and learned a lot.

I worked with a couple of teams: one for the Cleveland Rowing Foundation and another for the Joan C. Edwards Charitable Foundation. The CRF marketing-focused Drupal site went really well. The core team was comprised of Dirk Dorony & Sue Marrone with some fantastic help on Saturday night from Greg Svitak (@gsvitak).

The JCECF proposal was for a web application designed to foster interest in inner-city students to become physicians and station their practice in Cleveland. JCECF does this through education and funding a full-term (undergrad to graduate) scholarship, the only one of its kind that I’m aware of. My teammates on this effort were Mike Kvintus (@MikeKvintus), Daniel Shultz (@danshultz) and Patrick Sullivan (@pragmaticpat) with assists from Greg Malcolm (@gregmalcolm), Jon Stahl (@jonstahl) as well as a whole slew of other people who selflessly stepped in! Thank you all!

This 2nd project is where we learned our lessons and first experiences in why we need an agile development approach.

I met with Mike & Dan to collect our thoughts about the experience and lay down a framework for what we can do better when we take the project on again in the next couple weeks. In general, the high-level experience points broke down into “What went well”, “What could have been better” and “What was broken.”

I should mention that none of this meant to be critical of the participants. We all want to be great at what we do and the compressed timeframe of givecamp offers unique challenges that we’ve never faced in corporate Cleveland. This is a way for us to self-assess and come up with ways to improve.

What went well

  • Great facility & host (on a boat and an airport!)
  • Very cooperative atitudes-no big egos
  • Creating and tracking activities through detailed Backlog, WIP (Work in Progress), Testing and Complete stages, with PostIt notes, of course
  • Wireframe (low-fi mockups)

What could have been better

  • More graphics & theme designers (the ones we had were great!)
  • Emphasis on user experience & less focus on technical details up-front
  • Segregation of responsibility to delegate tasks
  • Hosting & domains

What was broken

  • Waterfall-style project management
  • Time/work estimation
  • Requirements (wireframes created way too late in process)
  • Version control
  • Unsustainable pace (~4 workdays over 48 hrs)

Using all of this as our input, we batted around some ideas for a framework that wouldn’t have too many rules but would enable us to focus on the most important tasks first. It needed to deliver measurable business value without trying to take on everything at once.

A process we think would have helped effectively digest & prioritize

Prep before camp:

  1. Create personas (incomplete e.g. google doc “Personas” tab.)
  2. Create end-to-end narrative user story for the most common scenario
  3. Create user story map with steps along the top axis and business values along the left, starting with the “Minimum Business Value” and increasing complexity as you go down. (incomplete e.g. google doc “User Story Map” tab)

At GiveCamp:

  1. Identify the minimum business value add scenario within a User Story Map (horizontal rows in above google doc)
  2. Draw screens to support the current minimum business value add scenario
  3. Identify application chunks necessary to support screens
  4. Identify time estimates for each chunk (include detailed test case steps as a chunk)
  5. Assign owners to each chunk
  6. Work & test against the current minimum business value add scenario
  7. Standup every 50 min for:
    • What I’ve done since the last standup
    • What I’m going to get done next
    • Obstacles that I need someone to remove
    • Take a couple minutes afterward to reset your mind & body before going back to step 1 or 6, as appropriate
  8. Demo every 4 hours to client, adjusting as needed to their feedback

From what I’ve seen, this process borrows heavily from Agile & Scrum. I’m sure it’s not perfect but I’m also sure we would have had much more to deliver at the end of 48 hrs following this process. In addition to the process changes, we also discussed some resources that would have been useful.

Could have used on a local wiki

  • Basic project process template
  • Resources by stack: .net, LAMP, ruby, etc.
  • Version control tools: e.g. git hub, CVS, subversion, etc
  • Software dev tools: e.g. Microsoft visual studio CDs
  • Hosting providers “how to” directions/codes: .net, LAMP, Ruby, etc.
  • Dev & prod environment creation guides
  • Password repositories for each team
  • Participant twitter/email/phone directory with skill sets, including expertise (beginner, adept, expert)
  • Instructions for clients with CMS/Blog projects:
    • How to backup
    • How to make edits to existing content
    • How to create new content

Could have used flexible resource expertise

  • Expert-level mentors who float between teams, as skills are best used
  • Teams or mentors dedicated to creating dev & prod environments at kick-off

These are only a few ways we could have approached the situation differently. I’m sure there are many other approaches and we’d like your input on other approaches to simplify the problem and streamline the solution.

Feel free to include your thoughts, experiences & resource links in comments.

Easy, BenWoz