From a marathon to a sprint

Developing and launching a theme on WordPress.com is a long, multi-step process that can take weeks, if not months in some cases. We would typically do it all alone, working in relative seclusion, sharing our progress only at certain points.

This approach has a few drawbacks — it limits the potential for synergy, it makes it hard to keep up the momentum and stay motivated. It also contributes to the feeling of isolation, which is already present in our geographically distributed team.

So about five weeks into the development cycle of our latest theme — Radcliffe 2 — we decided to try something different, namely sprints.

Borrowing loosely from agile approach, here’s how we structured our sprints:

• Planning — we’d kick off with a post on our internal blog, outlining suggested scope, and give everyone 48 hours to weigh in. We would also decide on sprint length, and who would lead/participate. Each team member would self-assign one or more tasks.
• Product Sprint — working on the product, as outlined in the scope. During the sprint team members would do daily stand-up updates in Slack (in a dedicated channel), and the sprint leader would make sure no one is experiencing any blockers.
• Retrospective — after the sprint has ended, a post with a few questions would go up on our internal blog, and we’d all discuss how the sprint went. Based on that we’d make changes to our next sprint cycle.

So far, we’ve done two product sprints, and as a result we were able to launch Radcliffe 2 with three experimental features much faster then it would be possible with our old process! 🎉 🎉 🎉

What went well?

• Creating and launching a theme is mammoth task, one that requires wide range of skills from design and development to user testing, copy-writing, and marketing. By breaking it down into smaller tasks, we were able to play into our individual strengths and achieve synergy.
• Working as a team on one theme sparked tighter collaboration, and made us feel more connected.
• Completing smaller tasks helped us to gain momentum and keep it going throughout the sprint.
• The individual effort of each team member was more visible thanks to daily stand-up updates, which helped us stay motivated.
•  It was simply a lot of fun to work together on one project 🙂

What didn’t go so well?

• Loose scope — first time around we defined the tasks to be tackled too broadly, without defining what constitutes a task as done.
• Confusion over who’s doing what, particularly with our first sprint.
• Steeping on each other’s toes — working collaboratively on one theme had some technical challenges, and we ended up overwriting each other’s code on a few occasions.
• Lack of design oversight — most of the tasks had a design element to them that would impact the end product. With different people working on small parts, it was easy to lose the cohesion of the design as a whole.

Learnings

• Smaller projects (a theme refresh for example) might require just two people working on it, but can still benefit from the sprint approach.
• Proper planning is key – we need to get better at defining the scope at the start of the sprint, and sticking to it.
• We can apply this approach not only to product work, but to theme maintenance as well (fixing bugs in our existing themes).

Photo: Steven Lelham – Unsplash.com

#remote-work