Scrum for One

That’s a funny word, isn’t it? “Scrum.” Scrum is a project management strategy for software development teams. The name comes from rugby (I guess) where it refers to the start of a new play. In the programming world, it’s a technique of coordinating a team’s work without a clear plan, working towards attainable short-term goals, and then repeating the process towards another set of goals – which I suppose is kind of like playing towards a goal in rugby. Except, you know – fewer broken bones. Hopefully.

I’m not part of a software development team. I’m not even a programmer. But when I came across an article on Scrum recently, it struck me that, while intended for big, collaborative projects, there were a lot of elements of Scrum that could be adapted pretty well to individual productivity. Although Scrum can be implemented at any stage of a project, it really excels as a way of dealing with projects that have stalled out for some reason – projects that have gotten stuck for lack of resources, lack of direction, even lack of teamwork – and that’s something that happens to all of us at one time or another. Maybe, just maybe, the principles that get teams of programmers back on track can apply to the projects every one of us has gotten stuck on.

Scrum 101

Although there are whole textbooks devoted to managing teams and their projects using Scrum, the basic principles are very simple:

• Do what you can with what you have. Projects stall because some resource – whether it’s material, knowledge, or manpower – is missing. Usually, though, there are plenty of things that can be done even without those resources – other parts of the system to build, creative workarounds, standards to devise, and so on. During the planning of each stage, and in daily “check-in” meetings along the way, these shortfalls are taken into account and work designed around them so that a lack of resources doesn’t have to create a lack of progress.
• Constant feedback. As I just mentioned, Scrum encourages daily contact between its team-members, so that a) nobody stalls and holds up the whole project, and b) the collective knowledge of the whole team can be brought to bear on new problems in creative ways. Meetings are short, as short as 15 minutes, and center around three questions:
  1. What have you accomplished so far?
  2. What will you accomplish today?
  3. What’s preventing you from making progress right now?

  These simple questions are meant to identify any “logjams” and break them up before they hold up the entire project.

• Work towards clearly-defined short-term goals. Scrum projects are, generally-speaking, point-releases of the software under development – that is, they are significant but relatively simple evolutionary improvements of the state of the project at the beginning of the project. For example, a set of new functions could be implemented, an interface designed, a database structure mapped out, and so on. “Write browser” is too big of a project, it’s realization too far off, to make for a meaningful Scrum project; “correct bug in line 1178” too small. Ideally, as each project is completed, the software under development should be in a usable state – Scrum was developed to deal with the contingencies of the software world, where projects often need to be rushed into market to combat a competing project, or just to bring in an income.
• Sprint. The basic working unit of Scrum is the Sprint – a focused dash towards the completion of the immediate project goals. At the beginning of the Sprint, the team determines exactly what resources are available to them, what they intend to achieve given those resources, and how long they’ll work on it. Then, they work on those objectives, and those objectives only. The Sprint is sacrosanct – its members work on the project they’ve put together and nothing else until the Sprint is completed. It might be a week, it might be 30 days, or anywhere in between – whatever time they’ve agreed on is dedicated solely to the Sprint. When it’s done, team members might rotate out of or into the team, or be assigned to other projects, but until then – they Sprint.

Scrumming Solo

Seems to me that, with a little modification, those are pretty good principles for anyone with some big projects on their plate – especially if you, like me, have a tendency to get side-railed. Of course, most of our projects aren’t collaborative, and they’re rarely as compartmentalized as computer programs, either. The idea of developing a project by evolutionary steps, with each step creating a potentially usable end-product, simply doesn’t apply to the kind of long-term projects most of us have as individuals – things like writing a book, learning a foreign language, or earning a promotion.

But the idea of Scrum is, I think, very applicable to our personal lives. The whole point is, through a process of constant self-awareness, to identify what’s holding us back, how we can work around it, and where the next few days or weeks should take us. Consider, then, “Scrum for One”:

• Do what you can with what you have. There are bound to be hang-ups in any project worth doing, and it’s all too easy to look at a project and despair because you don’t have whatever you need to finish it. Well, you may not have what you need to finish, but chances are you have what you need to start, to do at least some of the steps needed to get yourself somewhere close to the finish line. And you can take heart from this peculiarity of Scrum: often, when working under less than ideal circumstances without all the necessities to finish a project, Scrum teams find that either a new solution emerges that’s much more within their grasp or, just as often, that the missing element isn’t really needed in the first place. At the worst, you’ll give yourself the time you need to come up with the missing piece – and meanwhile you’ll be moving inexorably closer to your goal.
• Constant self-reflection. If you’re a fan of Allen, Covey, or Drucker, you’ve probably already accepted the importance of a weekly review. Scrum for One suggests that more frequent reflection might be helpful – nothing at the scale of a full weekly review, but a few moments of honesty each morning to define the work in front of you and any problems that might be standing in the way. Brainstorm a few minutes to see if you can solve the issue, and if not, put it in your to-do list for later action. A lot of time, just asking “What’s standing in my way?”is enough to trigger a solution – more often than not, the problem lies more in ourselves than in our situation.
• Work towards clearly-defined, short-term goals. Give yourself a time limit and set a reasonable goal – reasonable, but meaningful – to reach by the end of that period. Projects that stretch out in front of you for months or years are discouraging (which is why so few people write books) while projects that are too small often aren’t very satisfying to complete.
• Sprint. Sprinting the way Scrum teams do it won’t really work for individuals – you probably have a lot of different roles to play on a day-to-day basis, which means focusing on a single project to the exclusion of everything else is going to be difficult, if its even possible. What you can do, though, is block out a number of hours every day and use them to focus strictly on one project – no distractions, no knocking off early, no nothing until you reach your goal.

Obviously this isn’t anything like a complete productivity system, but it’s interesting nonetheless. Scrum is a very effective way of managing projects, and is used by software giants like Microsoft as well as tiny start-ups and everything in between. If nothing else, next time you’re stuck, ask yourself the simple question, “What’s standing in my way right now?” and see if that doesn’t lead to “OK, what am I going to do about it?”