So, what’s the right methodology for a developer or really small team for (hopefully) building and launching a successful SaaS? Do you bang out the minimalist of minimal viable products with no tests? I did that basically back in the day with StartupToDo.com and was overwhelmed by technical debt and bugs. Now that I’m back to being a solopreneur after 15 months developing for Brandle.net, and after seeing how other solopreneurs or small teams develop software, finding a better approach was very high on my to do list.
Yet, I always assumed that Agile development, the closely aligned practice of BDD (behavior-driven development), and in particular Scrum methodology was by and for teams of developers – that while it scaled up, they did not scale down. Two things post-Brandle.net changed my mind:
Talking two weeks ago with Aaron Schaap, CEO of the Grand Rapids, MI based development shop ElevatorUp. Aaron shared that ElevatorUp actually use Cucumber to have clients write and define user stories which are at the heart of Scrum and Agile, and that this approach actually worked extremely well both for his developers and their clients. A key benefit claimed by Cucumber and BDD is that non-developers could and would write stories instead of specifications. I had never before seen or heard of this actually happening. Aaron does it every day.
The other thing that changed my thinking about this for my own projects is reading Jeff Sutherland’s brand new book, Scrum: The Art of Doing Twice the Work in Half the Time. Jeff is the inventor of Scrum, and if you do or are considering doing Scrum, you want to read this book yesterday. Why? Because it lays out in the clearest terms possible not only how Scrum should be done but exactly why it should be done in the prescribed manner. It’s not chance – there’s a deeper logic there that Jeff lays out in this book.
Understanding the deeper why behind Scrum practices after reading Sutherland’s book and finally talking to someone running a development shop where nonprogrammers really and truly writing tests opened my eyes. When next I do development for someone else, TDD at a minimum if not BDD and Scrum have got to be baked in – no more sacrificing code quality and test coverage.
With that being said, I’ve been hammering on getting to a Scrum of One for FlashCommand – what works and what doesn’t work when there’s only one developer?
After way too many hours over the last several weeks spent reading the internets and trying out just about every Agile-related bit of software out there, tapping the power of Zapier to integrate various apps, here’s my approach:
I’ve settled on using exactly one product: Pivotal Tracker. It both seems to be the most popular agile app in the Startup world and manages to make it easy to avoid all the “team overhead” that as a budding “Agile team of 1” I don’t want, plus it’s reasonably priced for one user.
So my software dev flow is:

  1. Evernote to capture the vision of what I am trying to create, the “shared understanding” core to Scum, with links to relevant web clippings, research, posts about code and PDFs, audio notes, you name it, plus
  2. Paper prototypes on large, cheap index cards I can then scan into Evernote and digitally reference, plus
  3. High fidelity mockups, especially for mobile and tablet views, in the awesome Sketch 3, plus
  4. UI Flows ala this seminal post: A shorthand for designing UI flows, which then I scan into Evernote. These first 4 steps “get handed off to development” (me) by
  5. Creating Epics and Stories in Pivotal Tracker, writing those stories in Cucumber nomenclature (see http://cukes.info/), and letting Tracker guide my iterations based on my actual velocity. For actual coding,
  6. Copying these stories into my RSpec integration and unit tests files, but only coding actual RSpec and not Cucumber tests. While I now “get” what Cucumber is about, the overhead of maintaining two sets of tests when there’s only one developer on my project – me – is too high a cost.
  7. Taking a “TDD+” approach of tests first, then code re the guts of FlashCommand.com, but being more pragmatic about when tests get written for the UI – since I know a lot of the UI/UX is going to get iterated and I want to minimize throwing away tests because UI/UX has changed.
  8. Two specific Scrum practices get scaled down:
    1. Daily stand up meetings becomes starting each coding day asking the key Scrum questions:
      1. What did you do yesterday to help the team finish the Sprint?
      2. What will you do today to help the team finish the Sprint?
      3. Is there any obstacle blocking you or the team from achieving the Sprint Goal?
    2. And limiting work to that which I defined for the current two week sprint.

That’s my “Scrum of One” approach as I go from several prototypes for FlashCommand to actual production code: what’s yours?

Write A Comment