As a part of NYU Studio 20’s project with Storyful, I did an interview on how Fusion applies agile in its product development methodologies. For lack of a better word, this is the funnest thing I’ve written in a while — it encapsulates my current thinking on distributed teams, open source, and many topics in-between. It was originally published on Fusion Next.
What do you do in your role at Fusion?
As interim Director of Engineering, I consider my primarily responsibility to be very similar to a janitor — keep the lights on, clean up messes, and make sure things are happening in an orderly manner. And, when they aren’t, I jump in to get things back on track.
For instance, over the past week, I’ve:
- Helped with on-boarding two new full-time employees.
- Reviewed and provided feedback on code written by potential hires on trial.
- Edited job descriptions to go with the positions we’re hiring for.
- Reviewed and deployed code from Fusion’s engineering team.
- Worked with editorial to figure out the best way to do X, Y, or Z
- Stayed up late to build a new feature for editorial, the night before the story ran.
- Wrote code for a variety of bug fixes, feature tweaks, etc.
- Wrote Github issues for problems we want to solve over the next few months, and need product definition and UX for.
Really, it’s anything that needs to be done to keep the team on track and working on the right things.
How does Fusion use agile in its development processes?
Before we make too many assumptions, let me frame the conversation. I think Agile™, as a formal process with right and wrong procedures, is bullshit. To me, agile means the minimum process needed to ship code that exceeds product goals. What that process specifically is depends on the composition of the team and what we’re working on.
Many digital news organizations publish an article when it’s good enough to go, and then revise from there. This is in contrast to print publications, where you can’t edit a story after it’s been printed. In a similar vein, the proper way to ship web software is to deploy your Minimum Viable Product and iterate, fixing bugs and tweaking features. Your development process should foster this process — just like it shouldn’t take 15 minutes for an article edit to appear on your website, it shouldn’t take two hours for your bug fix to make it to production.
Fusion is still experimenting radically with it’s “agile” process. Our two leading tools right now are Slack and Github.
We have two Slack organizations: Fusion Product for technology and product, and Fusion Digital for editorial. Given how easy it is to simply strike up a conversation with anyone, I cannot imagine being in an office of the same number of people, having to go over to someone’s desk, see that they’re not there, etc. etc.
However, Slack comes with costs too. It can be very easy to become overwhelmed by the number of conversations happening that you’re inadvertently following along. Also, text is a low-bandwidth form of communication, where subtlety is lost.
For the technology team, because our work is so closely tied to the products we’re building, Github issues are the best place to have conversations. Currently, we have repos for each product we’re responsible for, as well as a “Fusion for the Future” repo for discussing future projects, and a “Let’s UX This Puppy Up” repo for UX / design requests and our style guide. To add a light project management layer to our repos (e.g. determining which state each issue is in), we are using Huboard.
The goal for our Github repos is that no one should ever have to wonder what’s next to work on. Backlogs should be chock-full of well-scoped issues and features to pick from.
One of Storyful’s biggest problems is communication between departments. How do you overcome this obstacle?
I love this question! It’s right up my alley.
One of my favorite phrases from my days at Automattic is “communication is the oxygen of a distributed company.” Meaning, the success of a company is directly correlated to its ability to communicate. And, if a company is struggling, it’s probably because communication is breaking down in some way.
Given this assumption about the importance of communication, it begs the question: how do you communicate well? For me, it boils down to these things:
- Use the appropriate medium.
- Be deliberate in how you speak.
- Meetings and emails aren’t communication.
Open, archived text should be the default medium for conversation. It’s helpful to have everyone in the company in a communal, synchronous chat application for quick one to one exchanges. If the conversation doesn’t need to be real-time, then there should be an open, archived space for asynchronous communication. Fusion uses O2, the successor to P2, for this. It’s a blog with threaded commenting where anyone can post or easily review past conversations. See Sara Rosso’s presentation for how it’s changed Automattic. Lastly, if the conversation needs to be higher-bandwidth than text, go to audio or video. But a team that communicates well can conduct 90% of its conversations via text.
As an aside, it’s funny to me that Slack is now worth billions of dollars, and has taken over companies like wildfire, because IRC has been around for years. But, I guess that’s what happens when you get the UX right. Many people I’ve seen hesitant with IRC love Slack.
When you do communicate primarily through text, you need to be very deliberate in how you speak — it can be much easier to miscommunicate, because you’re lacking the subtlety you normally get in face to face conversation. Emojis can help with nuance. Screenshots are often worth a thousand words. Taking a pause to edit can greatly increase impact.
I love Michael Pollan’s “food-like substance” phrase because it can be re-used in so many ways. Meetings and emails are “communication-like activities”.
Meetings, because of their coordination costs, should be used sparingly. Just think — six people in a one-hour meeting represents six hours of lost productivity. If you do need the communication bandwidth that comes from meetings, a meeting shouldn’t be allowed to begin until it has an agenda with specific discussion points and a note-taker. These notes should then be archived to your open, archived asynchronous communication space.
Granted, face-to-face interaction is still important for keeping your team human. Fusion’s technology team has twice-weekly standups of 15 minutes or less, and Hangouts as needed. Because we’re a distributed team (currently NYC, Miami, Portland, Philly, and India), we plan to have a couple in-person meetups in 2015 too.
Similarly, emails are blackholes for the information a team needs to be productive. The context and details associated with an important discussion between person A and B is totally lost when person C joins the team. Do you really want to forward your entire email archive when person C joins the team? Or lose institutional knowledge when person A leaves the team? The types of conversations that happen in email can easily be done in Slack, O2, Github issues, or whichever open tool a team chooses to use. Archives are worth their weight in gold.
Scott Berkun wrote a book, “A Year Without Pants”, about his time with Automattic’s distributed culture that many people find a useful introduction.
How should other news organizations implement agile?
Once your communication is like oxygen, agile goes best with a heavy dose of open source software. Let me give you a real-world example.
Last night (Wednesday, December 3rd), Alexis Madrigal pinged me in Slack asking whether Fusion had a native way to embed a PDF in an article. DocumentCloud and Scribd are great, but also subject to DMCA requests. Alexis and Kevin Roose were working on story about the Sony Pictures hack, and wanted to embed a PDF version of a budget at the end of article.
“Give me 30 minutes,” I said. It ended up taking an hour and a half, but I was able to cobble together a solution using Mozilla’s PDF.js and putting the PDF in an Amazon S3 bucket Fusion controls. Thus, any DMCA requests will have to go through Fusion legal. Problem solved, powered by flat, effective communication.
Open source doesn’t just mean using open source software though. It means being a responsible member of the open source communities you’re a part of. And if you use any open source software, you’re a member of its community. Your product is dependent on that software — you want it to be healthy and thrive.
Just like being a good neighbor means picking up trash when you see it, being a good member of an open source community means taking the extra effort to open bug reports or create pull requests. Open source is a tremendous catalyst for software development — aka idea to production in a couple of hours — but it’s an informed, deliberate, and strategic activity.