Our team at OpenStudy has been using Flowdock for some time. It's become our chief collaboration tool for development and design, and one of our main ways to communicate news. We're a small team -- 1 full-time developer, 2 development interns, 1 QA intern, 1 full-time designer, 1 CEO and 1 marketing manager. We keep Flowdock oriented towards development and forward motion; information about market analysis, business development, and competition generally is kept on Yammer.
Flowdock gives us one place with everything we need, and has been a huge boon to team communications. First and foremost, we use it for team chat. But in this case, Flowdock doesn't really offer much over an IRC room and a decent client, or something of that general sort. There are some small niceties, but nothing significant. Flowdock's real power comes from the features it adds on top of chat. Indeed, the one feature that gives us the largest benefit after chat is the ability to send emails directly into our dock.
Before I get into the multi-faceted use we make of emails, I'll mention how we use chat. OpenStudy has an office, and all the full-time employees are there during the day. Chat is useful in two broad cases: when the development interns are able to do some work, but aren't at the office, and when we're trying to get someone's attention in the office. Like many people, we like to work with headphones on sometimes to concentrate on what we're doing (though not always -- most days at least some of us are spinning up some tracks in the OpenStudy turntable room at http://turntable.fm/openstudy_trax). Flowdock lets us mention someone's name to ping them (audibly and by a desktop notification) and let them know we need to ask them something. We don't always respond immediately; indeed, that's not the point. The point is that we have an easy way to let someone know we need them without necessarily interrupting their flow. Chat also comes in useful when we're staying home sick, for obvious reasons, or when an emergency comes up at an off hour and we need to coordinate.
Email, email, email
Email makes our Flowdock go 'round. We use email for two key flows:
- Design feedback/assets
- Bug tracking
Sometimes, design gets completed at off times when we aren't in the office -- weekends, evenings, etc. To give us a head start, our designer,Siddharth, emails the designs into Flowdock so we can get a look and start thinking about/commenting on them. Other times, he needs feedback on different variations, and sends them to the dock so we can all look on our computers at our leisure.
Sometimes feedback on variations happens on the dock, sometimes in person in the office.
The more important use is for assets/final designs. These get put on the dock, tagged #design, and we can access them whenever and wherever we are. In particular, this means Siddharth can finish his designs at will, and whatever developer is tasked with implementing them grabs the one they need and builds. If we need anything else -- for example, if the developer doesn't have time to extract assets from the PSD -- we can ping him either inline or in the general chat and ask him for it, and he sends that onto the dock in turn. We haven't been missing assets since we've started using flowdock.
Part 2 is bug tracking. Yes, I saved the most interesting part for last ;) We've tried lighthouse, we've tried github issues, and they all feel just plain too heavy-weight. Flowdock offered us an opportunity to lighten the workflow up when we signed up for it back in February; we did, and our flow has been essentially painless ever since. It's the perfect fit for us.
To file a bug, we email the dock with tag #bug (we also add other tags, such as the browsers where the bug happens, depending on the situation). The email for us ends up being main+bug@openstudy... If we have any questions, we can comment on the Influx entry and ask any clarifying questions.
The next step for us is `verification' -- when a dev commits a fix and pushes it, it's time for our QA intern, Min-hee, to double-check that the bug is fixed (beyond our own checks). At this point, we tag the bug email #verification. Usually, we also comment on the bug so Min-hee has an easy link from the main group chat to the bug.
The comment added to the email puts an entry in the right-side chat pane. This is particularly useful for older bugs.
Last but not least comes the check itself. If Min-hee finds that the bug isn't fixed yet, he removes the #verification tag and comments on the bug to let us know, including any additional details if needed. We repeat this process until the bug is actually fixed; at this point, Min-hee removes the #verification and #bug tags, and adds a #resolved tag. As a side note, we've never actually searched for resolved bugs ;) I have the #bug and #design tags favorited on my Influx, since I use them so often.
The one disadvantage to this flow is that we can't associate a git push with a bug, nor can we mark a bug `verification' with a git push. Realistically, we've found the inability to mark bugs with a push to be a minimal problem. Our flow is interrupted already to do the git push itself, and, as we've just fixed a bug (or three), we are at a natural stopping point. Since we usually have the bug open in Flowdock already, we can just pop over, add the tag, and then get back to what we're doing; my average time to complete that action is 3 seconds or so. And ultimately, though it makes me feel good and cool in lighthouse, I haven't missed the lack of association between commits and bugs with Flowdock at all.
Missing Features
Two things are the only ones that are really missing in Flowdock that make things slightly harder for us. First up, the fact that we can't search for things tagged #bug that aren't tagged #verification. This can be a minor annoyance when we're on a bug whomping spree and have to find where the next un-fixed bug lies. Fortunately, #verification is usually the last applied tag, and Flowdock lists all tags in search result pages. As such, we can still reasonably skim and see where #verification tags are missing.
If we scan the right side of the search results, we can see if there is a #verification tag.
The second issue is that we don't have a clear count of how many bugs we have. If one of the top 8 or so tags is #bug, then there is an entry on the search page that, when hovered, will show the number of bugs; however, it would be nice if saved searches had a visible counter indicating how many items match that search. On the flip side, that would be useless for the design tag, so I'm not complaining too much.
General Happiness
All in all, the two issues above are minor nitpicks. The second feature may not even be a good idea beyond for the specific use case of bug tracking in Flowdock. The net conclusion is: Flowdock rocks, and we absolutely love our team workflow using it. Whether it'll work for you is a different question, but if it sounds appealing, you should give it a shot.