This abundance of data suggests that people are poor not because they lack initiative but because they lack resources and opportunities — things that, in many places, money can buy.
Hack Week Project #1 Complete
I have a number of projects on my list for this hack week at Square. The first was to switch to 1Password. Heartbleed was just the excuse I need, plus 50% off from Agile Bits is a nice incentive as well: https://agilebits.com/store
After a couple hours monotonously resetting and changing passwords, the kill count is 71. I didn’t know I had that many websites to log into! The browser plugin, automatically updating & saving along the way makes it go by pretty quickly though.
If you have the chance, I highly recommend using 1Password or equivalent.
Do not hire a man who does your work for money, but him who does it for love of it.
The literary equivalent of the emperor’s map would be a biography of everyone in the world, or a novel of every second of every minute of every day: literature, like a map, gains its power from selection, from miniaturization. And the writer, like the cartographer, must make careful decisions about every aspect of the map: from letters to words, sentences, and paragraphs, from chapters to sections and volumes. Literary cartography fascinates and guides the way that actual cartography does; that’s why we keep and carry stories in the same places we carry and keep maps: on our walls, in our pockets, and on our phones.
I must study Politicks and War that my sons may have liberty to study Mathematicks and Philosophy. My sons ought to study Mathematicks and Philosophy, Geography, natural History, Naval Architecture, navigation, Commerce, and Agriculture, in order to give their Children a right to study Painting, Poetry, Musick, Architecture, Statuary, Tapestry, and Porcelaine.
The idea that the market will solve such things as environmental concerns, as our racial divides, as our class distinctions, our problems with educating and incorporating one generation of workers into the economy after the other when that economy is changing; the idea that the market is going to heed all of the human concerns and still maximise profit is juvenile
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.
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.
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:
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.
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.
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.
Just like UserVoice, we keep track of refactoring, infrastructure, and more here.
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.
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.
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!
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!
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.
I’m Moving to San Francisco
…and I couldn’t be more excited! It is a WIN-WIN-WIN.
- I will, for the first time, live in the same city as my girlfriend.
- I will be several hours closer and several hundred dollars cheaper to my family in Seattle.
- San Francisco is the place to get involved in early stage companies.
I will certainly miss Nashville. The southern hospitality, my amazing coworkers at InVivoLink, and most of all, my friends. I’ve lived in Nashville as a student for 4 years while at Vanderbilt and nearly 2 as a “real person”. Originally from Seattle, I’ve even grown to love country music (though the corrosive anti-intellectual sentiment that dominates the state politically still horrifies me).
I look forward to some down-time in between jobs and exploring all the opportunities available! San Francisco, here I come!
Loved listening to Brad Feld and Jason on This Week in Startups while on my run last week. Brad gave the best analogy for self improvement: the only way to build your muscles up stronger is to work them so hard they breakdown.
This philosophy can apply to everything in life. Whether it’s writing more often beyond your abilities (guilty) or coding something well beyond your technical abilities (common occurrence , sometimes the best way to learn is to push yourself too far.
Thanks for the advice guys!
Why I’m Back on Reddit
After over a month of giving up Reddit, I’m back on. I originally quit to increase my productivity. I had a shit-ton to do, and kept getting sucked into reddit.
However, when reviewing the data on RescueTime (awesome service) I haven’t really increased productivity too much. Instead, those little periods of time-wasting shifted instead to Facebook, Twitter, and Hacker News.
So you win Reddit. But only at the expense of my Facebook & twitter time, not productivity. There’s a constant amount of that, apparently.