Scrum of One: How to Bring Scrum Into Your One-Person Operation

But there are a lot of really great upsides to adopting a development methodology — even if you’re working by yourself.

Alex Andrews of Ten Kettles struggled with structuring his workflow when starting out, but once he learned about Scrum and discovered how to right-size it for his one-person company, he found that working within a structure as a solo developer was incredibly liberating — and productive.

Read on to see how he adopted Scrum in his development workflow — and how you can make it work in your own solo development efforts!

Ground Zero: Getting Organized as an Indie

When you start working at a new company, there’s usually a whole system in place for “how things are done”: when to show up in the morning, how often to expect meetings, how deadlines are treated, and so on. That system helps define whether a company will be successful, and just as importantly, whether the team will be happy.

But on your first day at that company, you don’t really have much say in the system. It’s your job to learn how things are done, and then start coding!

For indies, it’s a little different.

I first went independent with Ten Kettles on March 1st, 2014. It was just me in a room with my 2011 MacBook Pro, a notebook, and some ideas. There was no system to follow. Everything was up to me! What time I started work, what apps I focused on, how to lay out tasks…

At first, I loved the freedom, but it was also a bit overwhelming. One of my biggest points of pride in my past life as a research engineer was my time estimates: give me a project, I’ll tell you a date, and you’ll get the code on that date. I figured that skill would transfer over to making my own apps. I mean, the only difference was who was dreaming up the projects, right? But as 2014 progressed into 2015, that’s not what was happening — not at all.

I soon discovered that “indie developer” is not the most accurate job title. Coding was just one of many responsibilities, and arguably not even the most important one. What was slowing me down wasn’t the coding — it was the product decisions:

“Just one more feature… no, that design isn’t quite right… let’s wait to launch until there’s cloud support…”

It was taking forever.

The bloating timelines really started to bum me out. My music theory app, Waay, took much longer to complete than I had originally planned. Although I was really happy with how it turned out, it was difficult to look back at the company after a couple years and wonder “why didn’t I get more done?”

It’s surprising as an indie developer how little time you spend…developing.

It’s surprising as an indie developer how little time you spend…developing.

The products were good, but the process wasn’t. I knew I needed a better approach. Something to make me more productive, boost company profits, and make me happier.

Enter: Scrum

Though I was always iterating my work structure, it was just that — iterative. Gradual. Slow. I was ready for a big change to my approach, but didn’t really know what to do. I decided to put the problem on hold for a while and jump into some exciting client work that had cropped up. Little did I know that it would lead me to exactly the solution I needed.

This particular client was a medium-size development company that adopted (in part) a project management technique called Scrum. Maybe you’re familiar with Scrum, but at the time I didn’t know much about it at all… beyond something about daily stand-up meetings and being “agile.”

I wanted to learn more, but at first it was really just for the sake of professional development. But the more I immersed myself in books and articles about the topic, the more excited I got. Scrum seemed to touch on three of the biggest pain points in my process:

• More productivity
• More profit
• More happiness

This make me wonder: “How can I bring this approach back to my own products”?

As soon as the project was done, I hopped on a plane to one of my favorite cities, Montréal, to hole away for a few days and ponder how I could bring this approach back to my own projects. I pored over my notes, re-read a couple of great books on the topic, thought about the real-life problems I was facing with my own apps, and came up with a one-person Scrum variant for my company. I’ve been using this process ever since, and the change has been remarkable (I’ll get into this in detail later).

Let’s talk about Scrum and how it can work for your one-person operation.

Scrum: Key Principles

What is Scrum, anyways? Here’s an excerpt from the first book I used to study up on Scrum:

Because a one-person team is so different from the normal 5–9 person team, it’s not the specifics of “team” Scrum that I’ll cover in this article, but rather the key principles that define the whole process. It’s these principles that form the backbone of one-person Scrum.

Here are the core principles of Scrum:

• Ship and share. Get your product into other people’s hands on a regular basis — whether that’s end users, Beta testers, or even just a few discerning friends. Why? Because if you don’t, then you could be wasting your time on a feature or product no one wants (or wants in the particular way you’re doing it). It can be far too easy to lose perspective on the importance of certain tasks, especially as a one-person operation. Sharing a Beta release with your testers can be such a quick process, and yet the time it saves can be huge!
• Prioritize productivity, and quantify it. Your most important short-term metric is productivity. Not sales, not number of releases — just pure productivity. How much valuable work are you getting done each week? To answer that question, you really need to quantify your progress. You’ll cover how to track — and optimize — your progress using Task Points in the next section.
• Self-reflection & meaningful iteration. I hope you have a good mirror, because a big part of improving your productivity, income, and happiness involves taking a close look at yourself, your process, and your plans on a regular basis. As you inspect how you are currently doing things, it becomes much easier to start testing other approaches and see the effects in real-time.