Skip to main content

Working towards my Personal Scrum

Two weeks ago I read an article that changed how I organize my life.

I have a problem. Despite teaching people and organizations how to organize their work effectively, how to prioritize, about the evils of multi-tasking and the importance of sustainable pace, I have never been able to get my own to-dos under control. By extension, my life has never really been under control either. So I often work late into the night, almost every night, and on the weekends as well.

I have experimented with the Pomodoro (I could never get myself to stop working after 25 minutes. I want something done before I can put it down) and Personal Kanban (post-its with waiting-working-done around the screen of my notebook (the problem wan't the WIP but the length of the backlog). The results of my attempts was always the same: I worked very hard, getting things done one after the other, but my work schedule always extended into the night and over the weekend.

An experiment with timeboxing tasks/goals

Two weeks ago, a read an article on linked in, Critical Things Ridiculously Successful People Do Every Day, by Travis Bradberry. His first recommendation: "[F]ocus on minutes, not hours." Enter your program in your agenda. A light went on. If I am going to do something, the first question I must answer is when am I going to do it? Then I block the time for that activity. What happens if I don't have time for it? Either postpone it, don't do it, or cancel something else.

So I decided to try an experiment. For one week, I would schedule every major activity I needed to accomplish. From Sprint Planing for the SBC website, to quotes I needed to send customers, a talk I needed to prepare, to packing for my trip to the Scrum Gathering. Everything went into my calendar. Looking back on it today, I see that I had 30 individual items over five days. Only once did I schedule work into the evening.

What happened? The good news: Friday morning, when it came time to leave, my wife said, "it's time." I said, "OK," put my suitcase in the car, and off we went. On the way, she said to me, "I have never seen you so organized and ready for departure before a trip like this!". (And I hadn't even told her about my experiment!). I accomplished every major goal I set for myself that week (except one). And I had time to watch 4 hours of amateur Star Trek videos on you tube without feeling guilty! Wow.

The bad news. My estimates suck. It starts with the assumption that 30 minutes every morning is enough to deal with routine emails. So I had to deal with that.

Having a schedule in my calendar, and new goal starting half an hour from now, has proven to be an interesting attractor. It reminds me to focus my attention on the right thing. I can look at my calendar and see what I should be doing.

If I get to the end one time box, and the goal has not been achieved,  I have to ask myself the questions, what do I do now? Do I keep working on my current goal? Or do I schedule the remaining parts for later? Or do I cancel or postpone the next goal?

Depending on the situation, I have already done all of these. Remember, I said there was one major goal I did not accomplish? Well, I got to the time when I was supposed to start it, but I was nowhere near finished the previous goal. I evaluated the importance of the two goals and decided that it was more important to finish the goal I that I was working on. So I finished it and dropped the other one (urgent but not important). So timeboxing individual goals enables me to prioritize and ensure that the most important things get done. After a week of this, I was pretty happy with my results.

What does this have to do with Scrum? 

For me, Scrum consists of 6 essential patterns:
  1. Inspect and Adapt at regular intervals
  2. Produce something that might be valuable at least once per interval
  3. Management leads and supports, and knows when to stay out of the way.
  4. The whole team solves the problem
  5. One voice speaks for the customer/maximizes the value of the work done
  6. A coach helps everybody achieve higher performance.
How does planning my time on my calendar in this detail get me closer to doing Scrum? Let's look at how this implements the patterns:

Inspect and Adapt at regular intervals.
Produce something that might be valuable at least once per interval

First, I have stopped calling it task planning. I allocate time to achieve a goal, not perform a task. So I keep focus on the fact that my work should produce value. At the end of a time box, I hope that the goal will have been achieved. If not, that is the moment to Inspect and Adapt. I allocate time in Pomodoros (units of 30 minutes, including a 5 minute break). Nothing takes less than one Pomodoro, and I never block more than 4 consecutive pomodori for a goal. Often I achieve my goal. Sometimes I don't. That is when inspect and adapt is really helpful!

The whole team solves the problem

This one is actually pretty easy. I am the whole team. 

Management leads and supports, and knows when to stay out of the way.

I don't think this is really relevant in my context. I am basically a one person company. Not much of a management layer. :-)

One voice speaks for the customer/maximizes the value of the work done

This one is a bit tougher. Can I effectively be my own product owner? I think so, but I am going to keep an eye on this one. I started to set longer term goals by allocating time further in the future to achieve them. Aside from managing time I am not yet managing a formal backlog. 

A coach helps everybody achieve higher performance

Is it possible to be my own Scrum Master? I don't think so. An essential aspect of being a Scrum Master a Scrum Master is the independent perspective. On the one hand, I don't feel like I have systematic impediments. On the other, how do I know that I am focussing on the right goals? How do I know that I am working effectively? I think there needs to be second person involved.

Next experiments

This week, I will continue with the approach. I have also asked my wife to play the role of Scrum Master and I'd like to add a Sprint Planning/Review and maybe even a retrospective. Hmm, that means scheduling time for it...

My Personal Scrum, v0.1

How am I doing Scrum for myself?
  1. When I decide I want to achieve a particular goal, I also decide when I will work on it, and block that time in my agenda
  2. If I have no time to work on a new goal, I have to either postpone the goal, reject the goal, or reschedule or renounce another goal
  3. I strive to work on / that which  is planned at any given time
  4. I know my estimates suck, so I leave slack in my agenda and forgive myself if things don't get finished when I hoped/expected.
  5. My agenda serves me, not the other way around. So if reality is different than plan, I adjust the plan to reflect reality.
Do you have a personal Scrum? How does it work? I'd love to continue an exchange on how I as an individual can organize myself.

Comments

Peter B. said…
Hi Peter, great post!

I’ve been both scrum master and project manager over the past several years, and your post particularly resonates with me since a lot of concepts I’ve built into my own system I also took from agile and scrum practices.

My initial thought was to treat my own task backlog as a PO would use the product backlog. I prioritize tasks considering value, effort, and urgency, and always take the next task from the top of the backlog.

I find the calendar approach to be too restrictive though. Since, as you mention yourself, estimating effort is quite difficult, I think it’s better to use estimates qualitatively rather than quantitatively. That is, I can pretty accurately estimate if a task is small, medium, or large effort, but a ‘medium’ task might take anywhere from 10-30 minutes. Under such circumstances, it’s not practical to line everything up in a calendar.

Instead, I take a ‘kanban’ approach here: take a task from the top of the backlog, complete it, and when ready, take the next task. Really the only important thing is to work on the next most important thing at all times.

The article you mention (which by the way is also very interesting) compares to-do lists against calendars. I also ran into the problem of ever-growing static to-do lists and keeping them up to date to be able to choose the next important task. As I mentioned above I don’t believe calendars solve this problem however. What I did instead is introduce certain modifiers to task priorities that increase or decrease the values over time. This makes it possible for certain tasks to bubble up to the top over others eventually, based on their urgency or how long they’ve been in the queue. Others would sink to the bottom if I postponed them too many times (indicating they’re not really that important anyway).

Of course all this needs automation to be practical. It’s probably easier to show than explain, so I made a quick demo of the main elements of it: http://flowtree.wix.com/home#!demo/s989p

I'd love to hear your thoughts on this - do you see any drawbacks with taking this approach?

Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

Five Simple Questions To Determine If You Have the Agile Mindset

My company has started a top-down transition to Scrum and Kanban. Will that make us an Agile company? About 2 years ago, I attended a conference hosted by the Swiss Association for Quality on the topic of Agility. As a warm-up exercise, the participants were given the 4 values of the Agile Manifesto, then asked to arrange themselves in space. How Agile is your company? How Agile do you think it should be? Very Agile on left, very traditional on the right. There was a cluster of people standing well to the right of center. “Why are you standing on the right?” It turns out that they were all from the railway. “Our job is to run the trains on time.” They were uncertain whether this agility thing was really aligned with their purpose.
Is Agility limited to software? Steve Denning has collected the evidence and laid out the case that Agile is not limited to software, nor is it merely a process, nor is it something you can do with part of your time, nor is it something you can have your …