How InVivoLink Simplifies Software Development Using Trello

At InVivoLink, we switched to using Trello 5 months ago! There are certainly been some obstacles and the initial shift was certainly a shock to the system, but overall, it has made managing software development take up less time to concentrate on what’s important: coding! I’d like to share it with everyone so hopefully you, too, can waste less time.

Fool Me Twice…

First, I just want to take a trip down memory lane and explain how InVivoLink was doing things before Trello. The two previous eras can be defined by the tools we were using at the time.

1. Pivotal Tracker. Founding - 2011

In the very beginning of the company, Pivotal Tracker was the weapon of choice. It was relatively simple and cheap. Good things for an early-stage startup without billions of dollars in funding trying to get people to share pictures. However, to no fault of Pivotal’s, there was no process or methodology to speak of. Things looked more like this as feature requests or bugs came through: 

2. Rally. 2011 - 2012

Almost like an art movement, the Rally era was a direct response to the disorder and chaos of the Pivotal Tracker Era. The tool was powerful, expensive, and was extremely opinionated pushing us into a full-on scrum methodology. This was exactly what we needed at the time to bring order to the galaxy. Unfortunately, it became too restrictive…

Imitation Is The Sincerest Form of Flattery

The gears in my head started turning when I first read Joel Spolsky’s “Software Inventory” article. Go ahead and read that! I’ll wait.

http://www.joelonsoftware.com/items/2012/07/09.html

What really struck me was how much waste our current use of Rally created. For example, sprint planning meetings regularly dragged on for 3 hours, then break for lunch, followed by another hour of tasking out. With a whole day every 2 weeks for sprint planning, we were wasting ~10% of development time!

Then I read how UserVoice was doing things. Again, I’ll wait.

http://community.uservoice.com/blog/trello-google-docs-product-management/

Great you’re back! Read through the lens of Joel Spolsky’s article, I immediately noticed a more streamlined and efficient process. Now I had process envy. Something had to change…

A New Era

On September 24th 2012, we switched to Trello. Here are the original 4 principles that guided the change. Again, like a new art movement, the Trello era is defined by a reaction to the shortcomings of the Rally Era.

• Visibility.  Given our limited resources, it’s vital we’re shipping the software that will create the most value.  This requires proper guidance from everyone: client services, operations, sales, etc.  Rally, with the limited licenses and complicated interface, effectively shuts out the business side from gaining a simple, high-level understanding of what’s coming down the pike.
• Flexibility.  To beat the competition, we must be agile & flexible in everything we do, and ship a better product faster.  Rally’s rigid design limits the ability to improve our development process.
• Simplicity.  The less time we spend preparing and doing project management, the more time to ship software.  The complexity or Rally requires tons of care and feeding, reducing the amount of value we can deliver to clients.
• Push vs Pull. It’s important to build using “pull” over “push”.  When pushing, failures and quality issues are more common with certain parts of the assembly line frantically trying to catch up to their backlog.  When pulling, workers take on what they can, ensuring quality and improving followthrough.  With Rally, when we place stories in a sprint, we’re “pushing” them on the development team which can more easily cause breakdowns and low quality.

Under the Hood

We have 7 Trello boards that feed into each other. Here’s a diagram:

1. Roadmap

The roadmap is comprised of larger initiatives, or “Epics” which will be broken down into multiple stories. Each list is a quarter in the year. Every 3 months, we review the roadmap almost in a “sprint of sprints” and commit to working on the highest priorities. We use Trello labels to assign a rough size (not points) to each epic: S, M, L, XL where XL could take the whole team most of the quarter.

2a. Priorities

After the priorities have been determined for the quarter, each epic becomes its own list on this board. Here, we begin writing the stories. TrelloBot (save him for another blog post) automatically applies hashtags to the individual stories. This holding area allows product managers and others to build out stories without interfering with the dev team until story grooming time.

2b. Inbox

Sometimes, there’s miscellaneous work that needs to be done, but isn’t related to a priority for the quarter. Account Managers, Sales, and others can add one-off cards into this holding area.

2c. Engineering

Just like UserVoice, we keep track of refactoring, infrastructure, and more here.

3. Planning

Cards are pulled onto the planning board from all the 2-level boards (Priorities, Inbox, Engineering). Before making it into a sprint, every story must make it through a number of stages:

• Grooming. Our meeting where dev and business come together and nail all the requirements details. At the end, we give a more accurate point-size using the Fibonacci Sequence (1, 2, 3, 5, 8, 13).
• Design Review. Any larger UI changes are run past an account manager or the CEO. This is because we developers may not have all the clinical experience to properly lay things out.
• Tasking. No we do not collect hours. But we do lay out in broad strokes the tasks the developers will have to take. e.g. “New Controller method: returns survey from valid token.”

By walking through all these stages, we ensure that once development starts, the path to completion is known.

3b. Defects

Bugs are special and don’t go through the regular planning process. Instead, they start on this board as a holding area to eventually get pulled into a sprint. 

4. Current

This is the current sprint and where we spend most of our time as engineers. Here’s the typical life of a card.

• Defined. Starts here. Nothing’s been done, but we know the requirements & tasks are defined from story grooming.
• In Progress. Hack hack hack! Someone’s writing code.
• Code Review. Using feature branching, we require all code to be peer reviewed before being merged into master. For larger stories, the engineer will also do some manual testing. We prefer regular developers to test each other’s code because by reviewing the code, the developer can more intelligently know which parts of the system to test and save time. This is one of the most effective ways to stop bugs from getting into production.
• Completed. Code’s been reviewed, (tested if necessary), and merged into master. It’s now available in our staging environment. The business owner can now review it.
• Accepted. They like me! They really like me! Business owner approved and we’re all set to deploy this code.
• Deployed. With out feature-branching, we can deploy individual stories as they get completed throughout the week. Yay all done!

Meetings

Most of the meetings from the Rally Era live on. Here’s what we do:

• Daily - Standup (10 min). Just for the developers, we cover what you worked on yesterday, what you’re working on today, and if you have any roadblocks. Mostly done over Skype, this is just a good chance to make sure things are humming along.
• Weekly - Story Grooming (1 hr). Here, business and development come together. Picking either the stories already built up in the planning board, or drawing from priorities, inbox, and engineering, we talk together to understand not just what should be done, but why. Knowing the why behind a story is even more important so the engineer can make intelligent decisions on her own rather than blindly following what may not be the best solution to a problem.
• Every 2 weeks - Sprint Planning (1-2 hrs). A big part of sprint planning is the retrospective. What went well for you? What didn’t go well? Each person gets time for their “Airing of the grievances” - Festivus style. That way, issues can quickly be recognized and resolved. The rest sprint planning is determining which, of the stories that are ready, should be pulled in. Our velocity helps determine if we’re taking on too much.
• Every 3 months - Quarterly Roadmap Planning (2 hrs). The “sprint of sprints planning meeting” where the large initiatives are prioritized and pulled into the upcoming quarter. This has been extremely helpful in keeping us focused. It’s very easy to get distracted and work on a ton of different projects, but by doing the quarterly planning, we make sure to follow-through with fewer distractions.

Metrics + TrelloBot

One of the things we missed moving to Trello was regular agile metrics, such as velocity. Thankfully, Trello has a robust API. Using a Google Script running every 30 minutes, our dear friend TrelloBot gathers data from each board and dumps our metrics into a Google Spreadsheet. I’ll cover how he operates in a future post and look forward to sharing the code with everyone!

Thanks!

I appreciate you hanging with me and learning about the process we built at InVivoLink. There’s a whole lot of stuff left out of this, but I just wanted to focus on getting the general gist. Please feel free to contact me if you want to learn more about how we manage our development. Thanks!

For comments, check out the Hacker News post.