We have a very engineering-heavy team at Appboy, and we care deeply about maximizing efficiency and driving our product forward (just like everybody else). To that end, we’ve put a lot of effort into making our development process more efficient.
The phrase “Project Management” has a tendency to raise developers’ hackles — often with good reason. The term conjures up images of over-empowered and under-intellected “Office Space” style managers roving through cubicles and looking for trouble like bored suburban teenagers. I suspect that this is due to the fact that many of the bells and whistles of project management — status reports, roadmap meetings, and issue logging — can naturally interfere with the process of doing actual work. Conversely, however, a total lack of any management can quickly turn into a high school group project.
In an effort to meet a happy medium between heavy top-down control and a free-for-all, we’ve fully embraced the idea of pursuing a structured but minimalist project management structure at Appboy, using Github. We use Github’s built-in project management tools exclusively to manage our development teams. For those unfamiliar, Github provides a lightweight project management layer that allows anyone to group Issues into Iterations with set milestones. One can easily filter the issues that are assigned to a particular person or iteration, creating a transparent and simple system. We’ve also cherry-picked the concept of a daily standup from the Agile school of thought.
Below are a few of the lessons that we’ve learned from growing our development teams and processes:
1. Keep the process simple
Keeping project management tools simple pays off. If you give people the ability to play with many different features, one of the biggest dangers is that they’ll actually use every last one of them. Overly robust reporting tools can create a related issue with manufactured demand — if you provide managers with access to a menu of graphs every week, they’ll eventually come to demand it. This can reach comical levels in a larger organization, where you can find yourself having training meetings about how to use your project management tools to setup future meetings, like a nightmarish corporate version of Inception.
For our engineering team, we’ve mitigated this problem by using Github for our issue tracking. Github is extremely simple and bare to the metal, which I view as a feature rather than a bug. Using Github has helped us avoid trouble because there simply isn’t that much you can do with its toolkit. You can enter issues, categorize them, and get rid of them, but the system encourages efficiency in describing tasks.
In addition to ensuring that the right things get done, it’s important to make sure that you’re approaching tasks in the right order. Refactoring a crucial piece of business logic might be extremely important, but it’s a lot less urgent than upgrading your EC2 instances if your current servers are on fire. We use our daily standup as an implicit filter for developers’ priorities. It’s accepted and encouraged to question the order in which others are tackling issues to ensure that everyone is on the same page. Overall, we expect everyone in the office to be honest and direct, which helps when it comes to having a “why are you working on that” conversation during a morning meeting.
2. Be Realistic with Timelines
All of our development work (aside from the aforementioned melting servers) is broken down into iterations consisting of a group of Github issues. We tend to use very short iterations — approximately 4-5 work days. This has proven to be a great time interval, as it’s short enough that estimates usually aren’t too far off but long enough that one has time to get a coherent unit of work done. Maximizing our ability to make good estimates also reduces two often opposing pressures in any software environment: the pressure to get things done correctly, and the pressure to get them done fast. Since we’re a startup, short iterations also give us lots of opportunities to course-correct. Longer-term product decisions are discussed and structured periodically in longer meetings, but we always make an effort to ensure that meetings are as rare as possible and timed not to break up people’s “flow.”
3. Make Your Tools Responsive
Once upon a time, I helped maintain a custom tool that used several different products to pass data between multiple PMO systems. It was actually a very impressive piece of software that solved a precise business need, but came at the cost of poor performance. Many components of it were slow due to the infrastructure that we used to host it. While a second or five here or there may seem like a relatively minor issue, as time goes on these friction costs begin to add up. Even more dangerously, when it’s very time consuming or inefficient to add issues or update project roadmaps, a tendency can arise to simply ignore minor issues. Over time, these missed issues can snowball into a colossal mess. One of the great things about using an externally hosted system like Github is that it’s highly available and very responsive. The fact that Github does little things like sending pull request comments asynchronously further speeds up the process.
4. Make Expectations Clear
The best way to improve efficiency is to make it clear where responsibilities for different aspects of the product development process lie. Is it a developer’s job to ensure that the UI for a new product looks good, or is that a designer’s? Who makes sure that code reviews have happened before merging in a change? We’re very careful at Appboy to make sure that everyone understands what’s expected of them and what they can expect of anyone else. It helps that our “managers” are also developers — everybody plays by the same rules, and as a result any hiccups in the system come to the attention of the full “chain of command” very quickly. More than anything else, managing expectations helps to remove the need for hand holding and other time sinks in the development process. We’ve found that the more everybody is on the same page, the more people are able to operate independently and feel more ownership for their work.
One last benefit of Github is that it’s cheap as hell. An enterprise project management tool can cost well into the 5+ figure range even for a stripped down version. As a startup, we’re not comfortable shelling out the equivalent of a used Camry on a project management tool. Although Github’s project management tools still leave something to be desired (for example, their search functionality for closed issues ranges comfortably between bad and infuriating), we’ve definitely found it to be effective where it counts. Considering that Github also hosts all of our source code, provides an easy code review process, and integrates seamlessly with Hipchat, using their service has been a no-brainer for us.
As our team continues to grow, I’m sure that we’ll face different organizational challenges and need to rethink and adapt our overall plan. I’d love to hear about your own thoughts or personal experiences at kevin@appboy.com or in the comments below. If this type of nimble, low-friction workplace sounds compelling, check out our jobs page.