Scrum Of One: How to Bring Scrum into your One-Person Operation

As a solo indie developer, it’s easy to believe that things like Scrum and other Agile development methodologies are reserved for large software development teams. The overhead of implementing a development framework can seem like too much work when you’re already constrained by too-small budgets, ever-changing technologies and the limiting factor of only having 24 hours in a day.

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.

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.

Scrum of One: A How-To

Now that you’ve covered the Scrum principles of shipping, prioritizing productivity, and reflection/iteration, it’s time to get into the specifics. How can you use this technique to manage your one-person operation?

What follows is a one-person Scrum variant I created for my own work at Ten Kettles. I’ve stripped away much of the traditional Scrum jargon, so there’s no prerequisite Scrum expertise necessary. Let’s dive in!

The Sprint

A sprint is a set period of time devoted to a very defined goal, such as adding a new feature to your app or squashing a set of complex bugs. Pretty much everything you do in the sprint should be deeply focused towards making that goal (or set of goals) a reality.

A sprint is usually between one and four weeks, depending on your style and the product itself. I use two week sprints and find it to be perfect: enough time to get a meaningful set of tasks done, without giving me too much time to get off track or get carried away with unimportant tasks. Here’s what my two week sprint looks like:

As you can see, a sprint is made up of lots of focus on your core tasks, plus a handful of events: the Daily Scrum every morning; the weekly Story Time; and then the Sprint Release, Retrospective, and Sprint Plan at the end. You can read about each of these in detail below.

The Daily Scrum (5 minutes)

One of the fundamental elements of Scrum is constant self-reflection and iteration — especially when it comes to productivity. So, when you plan to complete a task one day but it doesn’t happen, you use that as an opportunity to figure out what went wrong and then improve your process. The Daily Scrum helps make that happen.

The stand-up meeting (or Daily Scrum) is the hallmark of the Scrum method. Traditionally, it’s when the team members each share yesterday’s progress, today’s plans, and anything that’s blocking their productivity. The meeting’s kept short to prevent the dreaded meeting bloat (“just one more thing…”) and having everyone stand-up helps keep it that way.

At its best, a good scrum gets everyone on the same page, brings any challenges to light — eliciting help from team members — all the while helping the team to grow.

So, how can this work for one person?

Here’s where you can use a little tech to your advantage. Your one-person stand-up meeting becomes a short video you record every morning. (And I mean short: aim for under 45 s.) Here’s how you do it:

• Review: Start by watching yesterday’s video, paying particular attention to what you said you were going to accomplish.
• Reflect: Didn’t reach yesterday’s goal? That’s OK, this is what Scrum’s for: think about why it didn’t happen and what you could have done better. Maybe you booked a meeting mid-afternoon which threw off your coding flow for the rest of the day. Or maybe you were preparing screenshots manually for the App Store, and it took much longer than expected (time to try fastlane?).
• Rehearse: For no more than a minute or two, rehearse today’s video: a couple sentences on each question: what did you do yesterday, what are you going to do today, what’s been blocking you. Here’s an example:
  “Yesterday I created screenshots for hearEQ V2.2.0 and updated all the App Store meta information. Today I’ll update my press list, write a press release, and then meet with a music teacher to discuss Waay. For blocking, it took way too long to make the screenshots, and so I didn’t get to the press list as I’d planned to. Next time, I should look into speeding things up with fastlane!”
• Record. Record the video on your phone, and you’re done! These will be particularly helpful in the Retrospective, which we’ll discuss soon.

Story Time (30–45 minutes)

In each sprint, you’ll spend most of the time with your developer hat on — fixing bugs, adding new features, and so on — rather than devoting too much time to thinking about big-picture stuff, such as making a new app or pivoting a current one. Story Time is when you put on your CEO hat and start thinking big-picture. For this part of the sprint, I like to get out of my normal work environment and go to a coffee shop, grab some food at a local breakfast spot, or even just work from a different area of my home.

Changing up your location — even to a different room — helps you think about the big picture.

During Story Time, I’ll review feedback from users, brainstorm app features I’d like to add, and consider how I might want to pivot the apps (or even the company). This is also the time that I’ll think about new apps or abandoning old ones. Then I’ll come up with some concrete ideas and add them to a special list called the Product Backlog.

The Product Backlog is an ordered list of big-picture tasks. This will be the first place you’ll look when deciding on your goal for the next sprint. But just as important as it is to add new tasks to your backlog, Story Time is about revising and rearranging what’s already there.

Maybe you’re seeing a lot of interest from Brazil in your website analytics. That could mean it’s time to consider a Portuguese translation instead of the Spanish translation you had planned. Or maybe you’ve just received some reviews about a feature that people suddenly seem to want. Time to consider moving that feature up the list.

Sprint Release

A fundamental principle of Scrum is getting your work out into the world on a regular basis. This is what happens in the Sprint Release. It doesn’t need to be a full app release, but it is really important that you get something new out into other people’s hands — especially people who you feel a little nervous to impress! This can be a new version out to your Beta testers, a set of wireframes out to a new designer you’re really excited to work with, or even a minor update out to some discerning internal testers.

The scope of your release will likely change throughout your sprint, especially at first. For example, maybe you’ll end up releasing a Beta with only two of the three planned features. That’s OK. By trimming down the scope as you approach the release date, you prioritize the most important features without delaying that valuable tester feedback. If your testers don’t even comment on the missing feature, maybe it wasn’t all that important. If they do, then you have a clear idea of what to prioritize in your next sprint!

Last Day of the Sprint

You’ve spent nine days working towards your sprint goal, and now it’s time for the final day. The good news is that this is an easy one — you can keep your developer hat in the closet for today! :] This is a day to do a Retrospective, wipe the slate clean, plan your next sprint, and then do something fun.

At first, this seems like a very odd thing to spend a day on — especially if you’re drowning in deadlines. But I think of it like this: when I was young and walking home from school, I’d sometimes read a book as I walked. If I was really engrossed in the book, I’d find myself constantly zig-zagging across the sidewalk as I almost tripped into the road on the one side, or into someone’s garden on the other. (Agile, indeed.) And if I didn’t look up often enough, I might even end up going the wrong way.

Making sure you’re on the right path is what the last day of your sprint is all about. It’s a single day (or half-day, if the pressure’s really on) every two weeks where you pull your head up, look around, and make any necessary course corrections. Because even if you’re being super productive, that productivity isn’t worth much if it’s being wasted on the wrong task.

Now, let’s jump into the three main tasks for the day.

Retrospective (~2 hours)

Open up a new text document or turn to a fresh page in your notebook, and start writing down your thoughts about the past two weeks’ productivity. Here’s your opportunity to discover what’s stopping you from becoming even more productive and happy.

Some sample questions to get you started:

• What did you accomplish?
• Did you meet your sprint goal?
• What worked really well this sprint? What could have worked better?
• Are there any productivity blocks that kept cropping up? Review all your Daily Scrum videos for this information.
• Is there anything that needlessly stressed you out, or that you really enjoyed?

If you find that a walk is better for reflecting than sitting at a desk, hit the pavement and simply type up a quick summary afterwards. I also find that doing this outside of my usual work environment is helpful too.

Sometimes a walk in the woods is just what you need for a good Retrospective task.

Finally, based on your reflections, pick two simple things to improve on in your next sprint:

1. One thing to make you more productive.
2. One thing to make you happier.

Here are some examples of reflections from my recent sprints:

• Productivity: Especially during a Beta testing period, I found that constantly jumping in and out of email was really slowing me down. I started limiting email checks to three times over the workday, and it definitely helped my focus.
• Happiness: Because I work from home, it’s sometimes difficult to transition from “work mode” to “home mode” at the end of the day. So, I started taking a long walk at the end of each workday to “reset” before the evening. This one was a big success!

Sprint Plan (~2 hours)

Between the Retrospective, the two Story Times, and your Product Backlog, you should have a pretty good idea of what to work on for your next sprint. Just pull up that well-maintained backlog and pick the top few items! Your Sprint Planning stage is when you write down those sprint goals, the tasks that’ll take you there, and assign something called Task Points. More about that in a moment.

Here’s a simple example. Let’s say you have an app almost finished, and your next sprint will be for adding that final feature, doing some internal testing, and then putting out a Beta for user feedback. In your Sprint Plan document, lay out something like the following:

Note that for a two-week sprint, you’d likely have a lot more tasks here! But it’s enough to illustrate the point.

See those numbers beside each task? They’re called Task Points. They don’t represent hours or anything readily measurable — they’re completely abstract. All that matters is consistency.

For example, a one-point task should take about half as long as a two-point task (on average). Use whatever you like for your own scale. Personally, I like to use the numbers 1,2,3,5,8 which have a way of correcting for our human tendency to underestimate bigger tasks. For example, because there’s no 4, I have to round up to 5. :]

As you lay out your sprint’s tasks, think about how long each one will take relative to the others. Throw hope out the window here; take a cold and calculating look at each task and make a reasonable prediction for how long it will take you to complete.

If a task is complicated, but you’ve done that task a million times, then it will go a little faster and you can reduce the points. If a task is simple, but you’re unfamiliar with it, it will take longer and you should increase the points allocated to that task. No problem.

When you’re done, simply add up all the Task Points and compare the sum to what you achieved over your last few sprints. For example, if you usually get through 80–100 Task Points in a sprint, make sure this next sprint has around 80.

This is one of the most effective parts of Scrum, in my experience — and the most difficult. It’s often at this point where I find myself cutting tasks that I want to do in favor of tasks that are important to do. This gets me thinking more like a CEO than a developer, which can be helpful from time to time.

Now, once you’ve got your Sprint Plan down, clear off your Task Board from your last sprint, and prep it for Monday!

Wait, what’s a Task Board?

Keeping Organized: The Task Board

Time to step away from the sprint for a moment and talk about the Task Board. Although I type up my Sprint Plan in some detail (usually in OneNote), my day-to-day task organization occurs on this infamous Task Board. The board (usually my office wall) can have a few different elements, but the most important part starts with these three post-its, placed a foot or two apart: TODO, DOING, and DONE.

At the end of each day, I write down the next day’s tasks on separate post-it notes and then stick them up under TODO. Let’s say I’ve gotten through 10 daily Task Points on average over the past couple sprints or so. I’d then put up about 10 points of tasks for the next day.

The next morning, I walk over to the Task Board and move my first task of the day from TODO to DOING. When most of the day is normally spent in front of a computer, this simple act feels especially intentional which I find really helps with focus.

Then, when the task is done, I move the post-it to DONE. Oddly satisfying. As the sprint progresses, the DONE section really fills up. :]

Rest and Explore

Back to the sprint. You’re now getting into the final Friday afternoon of the sprint. End the day with something fun! This is the time I bring my laptop to the couch and pull up that raywenderlich.com tutorial I’ve had bookmarked for a few days, or maybe this is when I finally take the time to figure out the ins and outs of Regex.

Don’t pick something that feels like a chore; just do something loosely related to work that you enjoy. Pour yourself a drink, turn on some music, and celebrate a sprint well done!

One-Person Scrum vs. The Real World

Choosing the right work structure as an indie developer is a very personal thing. It needs to resonate with your strengths, motivate you, and encourage constant growth. With that in mind, you may find that certain elements of my one-person variant of Scrum work for you, while others don’t. Feel free to adapt the daily practices to suit your needs and style — do whatever works to keep those principles of shipping, quantified productivity, and reflection/iteration in place.

A few parting tips:

• Don’t feel bad if you get through fewer tasks than you’d planned in your initial sprints. Just adjust your estimates and task load for the next sprint. Meaningful iteration is the name of the game!
• Revise your Sprint Plan every day (or two) of the sprint. Review each task and tweak the Task Points (“you know what, this actually looks like more of a three-point task”). If your total count starts getting too high, you’ll want to remove some lower priority tasks to compensate.
• It’s hard to plan detail from a distance. If you’re using two week sprints, it’s OK if your task plans for the second week are a little less detailed. Your daily tweaks to the Sprint Plan will fill out that detail as the second week approaches.
• It’s great to have long term plans for your company, but don’t stick to them blindly. It’s better to have a great Product Backlog that’s alive, always changing, and always adapting to new evidence.
• Although this is the plan I use for building Ten Kettles’ apps, I’ve found that it’s also great for client work with just a couple minor variations. For example, a shared Trello board instead of a physical Task Board can keep the clients up to speed on what you’re working on, although I tend to use a Task Board as well, and there’s obviously no need for the “CEO-hat” stuff (Product Backlog, Story Time, etc.)
• Don’t forget to buy lots of markers and a big stack of post-its!

When I first realized that I needed a better work structure as an indie, it came down to three things: more productivity, more income from my own apps, and more happiness. I’m happy to report that this one-person version of Scrum has really delivered: the frequency of meaningful app updates at Ten Kettles has skyrocketed, income from our apps is now increasing at an average of 18% a month, users are very happy (both apps are now rated at 4.75 stars on the App Store), and my work-life balance has gotten way better — hello evenings and weekends!

Where to Go From Here?

Here’s a recent interview where I get into more detail about my work at Ten Kettles and my daily workflow.

Remember that the three core principles of Scrum are:

• Regular shipping
• Prioritizing productivity
• Regular reflection

It looks simple, but with a good structure, the power of these principles can start to manifest in your work.

If you want to learn more about Scrum (especially the team elements that we didn’t cover here), there are loads of great resources out there.

Here are a couple of short books to get you started:

• Scrum: The Art of Doing Twice the Work in Half the Time (Sutherland, Sutherland)
• Scrum: a Breathtakingly Brief and Agile Introduction (Sims, Johnson)

Time pass the microphone to you! Have you been doing your own one-person Scrum? Do you have any tips to share? Or, if you’re an expert “Scrummer” and have some advice to help the rest of us really reap the rewards (and avoid the common pitfalls) of Scrum, it’d be great to hear your take too. Come join the discussion below!

The post Scrum Of One: How to Bring Scrum into your One-Person Operation appeared first on Ray Wenderlich.