The theme team at Automattic handles much more than just building themes, and we work collaboratively on many projects.
However, when creating themes for WordPress.com — designing and developing new themes, or converting an existing GPL theme — we tend to work alone. Occasionally one person will design a theme and another will build it, but in those cases the roles are pretty separate.
We gather feedback at certain points during the work, at the end getting a teammate to thoroughly test the theme and review the code (what we call “breaking”).
Lately we’ve been discussing enhancements that would be helpful to customers who run small businesses. We opted to try them out in a series of theme refreshes we’d been working on.
Because it involved some new approaches, David A. Kennedy suggested we tackle finishing one of the in-progress themes, as a team. That way, we could figure out how to handle these new ideas together, and collaborate on them more easily than we could working on separate themes.
Tackling the Work
We needed to approach this a little differently than a regular theme project.
We used an agile-inspired approach, breaking the work into two one-week sprints. Each sprint had a “captain,” someone to keep things running and clear blockers as they came up.
Within the sprints, we enforced stricter time management than we typically do with themes. With a lot of people involved, it was more important to nail down the scope.
Different team members volunteered to “own” different tasks. This didn’t necessarily mean they had to complete the task themselves, so much as make sure their assigned tasks got done.
For communication, we kept the to-dos and feedback on dedicated posts on our P2-run internal team blog.
We also created a dedicated Slack channel. This isn’t unusual here — Automattic has hundreds! — but it helped keep the conversation focused on the project. Things stayed on topic, and it was much less likely something would be missed in the noise of our busier general team channel.
We each kicked off our work days posting a “stand up” in the Slack channel — what we accomplished the day before, and what we planned to work on that day.
We didn’t clash too much while working on so few files, but we have an odd advantage: our team spreads over several time zones, with up to a 20-hour time difference between some folks. This made code conflicts less likely, but made the communication part all the more important.
During standard theme development, it’s not unusual to post points for discussion, to make sure we’re on the right track and get feedback. But these things are usually very specific things someone is stuck on — we don’t generally discuss the minutiae of a theme.
When working collaboratively, everything was up for discussion, and because we all felt we “owned” the theme. Working together also fostered the environment of sharing — we weren’t just breaking out of our individual theme bubbles to ask for help, the project belonged to all of us.
Sharing the Load
On the theme team, we all build themes, but we each have our own strengths. The process, as we approach it, has a lot of steps: UX, design, development, user testing, and writing the documentation and announcement post.
Working as a team allowed us to distribute those tasks, and let people play to their strengths.
It also allowed us to collaborate on single tasks, and to try out something new and get help from a team member with more experience when needed.
At this time, we’re still mid-sprint. I expected this approach to be productive and result in a solid theme, but it was also a lot of fun! I was reminded yet again what a talented team I work with, and how enjoyable it is to collaborate with them. It was also a good reminder to shake things up from time to time, and don’t get stuck on one way of doing things.
We plan on trying this again. We learned a lot from our first attempt working together on a theme, and will continue to experiment with new ways to improve the process as we go along.
How did the theme turn out? You’ll see in a few weeks 🙂