From Bits to Books: Applying Software Project Management to Book Publishing
I joined the Google+ community under duress. Perhaps it only felt like that, since I hadn’t ever successfully used the new social media site since it had launched. But this was what the editing team for Interspecies was using for its first online review session, and I reluctantly signed into the community to access resource documents and interact with the rest of the team.
Fast forward to today, and the Kōsa Press team is using a very different toolchain, in part because of my experience with the various productivity tools and processes I use as an engineer at a global software company. At times, this shift involved a lot of fast talking and demonstration of key functionality, but the team has shifted over to using tools that are, effectively, focused on solving the problem of how to keep information organized and easily accessible.
Over the past five years or so, the software industry has shifted from a method of development that passed from one major phase to another (dubbed the “waterfall” method) to one that iterates and often releases rapidly. The latter, called agile software development, is a set of principles that has reformed the way that software is made. As a result, software project management has had to scramble to keep up, and companies across the industry have adopted different ways of implementing agile.
After the launch of Interspecies, I sat back and reflected on how my background in software development best practices applied to the production process and made it much more manageable.
Kanban
“I’m getting so overwhelmed,” one teammate exclaimed.
Somewhere around T-minus four weeks until the launch of Interspecies, the team met in a casual group chat to go over what needed to be done before the launch. Our project manager, M. J. Kelley, had sent us a detailed email with a starting point for all of the required activities to launch our first book together, and we were discussing what needed to be added. The longer we talked, the more the list grew.
I realized that we needed more than a checklist; we needed a place to keep track of the complex status related to each task required for the book’s digital launch. However, it was far too simple for the tooling we used at work, which was intended for the long-term management of complex software products.
“Hey, guys,” I eventually hazarded. “Have we considered using a Kanban board?”
I’d heard a brown bag talk a couple of years ago on how the Brackets team handled their open source work and frequent releases. By using this system, which transferred a ticket from one bucket to another, they were able to communicate to each other (and the outside world) what was being worked on at any given point in time.
Within a half an hour, we had a simple, but functional, Kanban board set up on Trello, a card-based management system that was particularly good for this type of project management. Within the hour, the anxiety in the room had lessened as we realized we could, indeed, see the lay of the land and begin to grasp the scope and shape of the work that still needed to be done.
Collaboration Through Conversation
When I first joined the collaboration, the team was working in four different time zones. Team meetings were a crazy combination of juggling work and personal schedules; between bedtimes, getting kids to school, and commutes of varying types, we rarely had an hour as a team. When we did have an hour, we invariably spent the first fifteen to twenty minutes trying to get the video conference to work or troubleshooting some software. It was highly inefficient and caused a lot of stress for everyone involved, including me. (“What do you mean, the plug-in isn’t working?! I’m a software professional!”)
Most of our online collaboration at the time was done in what I can only term as forums-style communication. People could create posts and comment on them, leading to what was effectively a threaded Email conversation. This meant that decision-making, while already a cumbersome undertaking, turned into a monstrously difficult task as we sought feedback from all parties.
What we needed was a system that was both realtime and asynchronous. Just as I came on, M. J. Kelley suggested Slack. Since I use the product a lot with my distributed teams at work, I promptly seconded the motion and began showing people some of the advantages of the system and tossing out protips.
Slack has been fantastic for hashing out details and conflicts in realtime and allowing offline team members to follow along after the fact and pitch in their ideas as well. It’s had the additional advantage of allowing us to be more personal in our communications, and we’ve been able to develop a sense of community through many casual conversations about the mundane.
Potential Improvements
Our first foray into adopting software product development best practices was a success, and we’re beginning to evaluate our processes as we gear up for the second volume in the series. Despite the fact that we adopted two important processes for the development of the series, we can continue to improve by adopting more best practices from software, including:
Reflection on process
At the end of every sprint, my software team takes a half an hour to reflect on the past period of work to identify pain points and potential process improvements. Taking the time to intentionally reflect gives us the opportunity to course correct as we go along and find what works best for us as a team.
An actual backlog
Our software team’s backlog is a list of what we have to accomplish, in the order it has to be accomplished, with a single owner for each card. The Kōsa Press team ended up with a card for each major task (what I would term an “epic”) instead of breaking it up into smaller bits for an individual to take. We also didn’t prioritize the list as much as I wanted. Entire dependency chains ended up in a single card, which made it difficult to demonstrate progress on a single story.
It’s quite possible that a formal backlog process might be too heavy for the scope of the team’s product, but improving the granularity stories could help us get a better grasp of the team’s cadence, or performance over time.
Document management
We’re still working on how to best manage documents. I’ve found that documents tagged in Slack can often be the most frustrating to find, especially if I’m running complex queries to find a link to that one document I’m looking for. I began tracking some of the documents in the Trello cards, and that seems to work better. Hopefully, we’ll have something better to report after Volume 2 is released.
We’re wrapping up the work to get Interspecies out in paperback for our readers, and we’re already beginning planning the second volume of our highly rated series. The team has run its first race together and is looking forward to evaluate additional processes as we work to bring our product to market: another killer sci-fi book that our audience will love.
Learn more:
Elaine is an engineer at Adobe. You can find her on Twitter at @elainecchao. All statements in this essay are her own and do not reflect the opinions of her employer.
