From one, there were many.
When I started at NoRedInk in March 2013, one of my first goals was to put together a backlog of what we needed to get done before the start of the 2013-2014 school year. We were going to have our first paying customers, and we needed to thrill them. There was already a Pivotal Tracker account and a huge backlog and icebox of issues to sort through, so I started there. I’d used Pivotal Tracker before for personal projects and was happy enough with it. At my last company, we started our Agile experience using Grasshopper and actually switched to using Post-It notes and magnets on a whiteboard.
As we hired up the engineering team, we quickly realized it was difficult to have a good discussion using Pivotal Tracker. Discussions just worked better in GitHub. We looked at a few alternatives that might bridge the gap, but none worked as well as GitHub for our needs, so we did something foolish: we started using both.
At the same time, various parts of the company were using Asana to track lists of this and that. And, there were a bunch of important requirements being discussed via email. As you and I and everyone we know could tell you, keeping all these systems in sync was a real pain.
There needs to be one source of truth. This is just as good advice for product development as it is for software.
From many, there was one.
Obviously, we did not decide to build our own issue tracker. We’re an education company, and like most companies we’re lucky if we get to do one thing well. That wasn’t going to be issue tracking.
I’m lucky to work with brilliant, talented people with a depth of experiences. Half of us have taught in a classroom. Half of us have founded a startup. And when we added a new member to the team in Oct, 2013, he soon took the reins of the situation and gave us the kick in the pants we needed to make everything work in one place. For us, that one place was GitHub.
GitHub was not designed to run Agile sprints, but most of the elements are there. There are no “sprints” but there are “milestones”. Each user story, task, and epic is an “issue”, and we track and link them together using checkboxes and, well, hyperlinks. We use Zenhub to define our backlog and track issues from started to resolved. And while there are no story points, and we have no idea what our velocity is, the truth is we haven’t missed it.
Equally as important, all of our discussions, even non-engineering ones, are now out of email and categorically in GitHub. This has been a tremendous win! We not only have a solid record of the discussions, but in a public forum where anyone with a good idea can contribute.
There’s no silver bullet
Are we saying you should stop what you’re doing and switch over to doing everything in GitHub? Absolutely not! We’re not even saying you should try to have all parts of your company using the same system. We happily use RelateIQ to track customers through our sales pipeline, and we won’t be replacing it with GitHub anytime soon.
But whenever possible, it is valuable to have all steps of a process - in this case product development - in one place. From ideation, to specification, to prioritization, to task breakdown, to implementation, pull request, quality assurance, and all the way through to resolution, we can not only see what we’re building, but see why we decided that was the right thing to build.
Discuss this post on Hacker News
Josh Leven
Director of Product at NoRedInk
github.com/jleven