My Personal Agile: Work Breakdown

(This column is posted at www.StevenSavage.com and Steve’s Tumblr)

And back again with my attempt to describe my “Personal Agile” productivity methods.

One of the challenges of getting things done is to figure out how to get it done. What do you have to do? What order? How do things work together?

To figure this out part of most any Agile practice is breaking down work to find out what to do, how to do it – and maybe if it even needs to be done (by finding the value as mentioned earlier).

So here’s how I break down work – this is the last stop before we get on to the real hands-on work.

Please note, these are my own definitions, tweaked for personal productivity. They may not fit various other Agile methods or ideas.

Projects

At the top of this all are Projects.  Projects are major, often large, initiatives. These are usally the big things you want to do like cleaning the garage, launching a new website, or writing a book. It may even be a thing you do regularly like cooking twice a week.

How do you define a Project? Here’s a quick guide to what a Project is in my book:

  • Distinct. Projects stand on their own and have their own identity that is (mostly) not dependent on anything else.
  • Has one of two lifespans:
    • It is distinct and will complete and be done, such as finishing a book or a program. Note that something like a software program may then spawn new projects like “maintenance.”
    • It is a distinct effort that is continuing, like a software maintenance program or an exercise routine. I call these Regular or BAU (Business As Usual) Projects. The effort is distinct enough that you could decide to end this Project in the future as a discreet act
  • Usually large. Most Projects will be of some size. However I argue that the Distinction and the Lifespan together define a Project more than size. And since this is my method, I’ sticking with it.

Project Value:
How do you determine if a Project is worth doing – in short, it’s value? There’s formal methods used in business, but on Personal Agile I find that there’s two ways to express – and measure – it’s value.

  • The binary. “I want X so y.” It could be as simple as taking a vacation so you relax or getting a certification as it’s standard career progression.  This is a lot like a User Story (below) just jacked up a level.
  • The measure. This is when you can tie the value to a measure and thus by measuring, determine if something was done and worth it. If you got a certification to try and get a raise then you can measure if that goal was reached – and it can fail as you may get the certification but not the raise. If you want to make X amount of profit with a book in a year, you can evaluate it – after a year.

Because Project success can be defined in many ways, I always look for “congruence,” that gut-level feel that the Project and any measures connect to my life goals. If that gut-level feel isn’t there, you might be wasting your time – or doing this under duress.

By the way if neither work, you can try describing it like a Story.  In fact, those are next.

Stories

Projects consist of Stories. Stories are where we get down to real work and hands-on value. Stories are also where a lot of work and breakdown and arguing goes on. So get ready for some opinionated stuff that might get me into a fight with other Agile practitioners.

A Story is the smallest unit of work you can do in a Project that still delivers value and helps complete the Project. It may be of limited value. It may be to a limited audience. It may not be that helpful without other Stories. But it has value that wouldn’t exist if you took it apart any further.

Ideally a Story should, when completed, be valuable if all other work stopped. It might not be much, but it’s something. Note this is an ideal but it doesn’t always happen.

The best way to get to breaking down Stories is to try it.  So let’s try . .  .

EXERCISE: Look at a Project you want to do.  Now write down everything you’d need to do for it to get done.  Don’t get over-detailed, just give yourself about five minutes.  We’ll talk how to make good Stories in a moment, but I want you thinking breakdown.

Interesting isn’t it?  Determining stories is definitely an art.  I also bet that the Story breakdown you have just brainstorming isn’t quite clear or satisfying.

So if you’re thinking “These Stories seem both really defined and kind of fuzzy” you’re right. Agile is both knowing what to do but not overdoing and overanalyzing. Fortunately there’s a tool to clear them up – and it’s a core part of Agile and one of it’s big contributions to management thought period.

Story Value
Stories in Agile are sometimes called User Stories (the terms get thrown around interchangeably). This is because they are, bluntly, focused on delivering something (value) to someone (a user) – and that forms a Story. The formula is a key to quickly determining what a Story is and what it delivers is to title the Story thus:

As (person) I want (thing) because (reason)

Sound simple, right? But this tells you three things – why you’re doing something for whom. If you can’t figure out any of these three parts, you either need to break it down more, do research – or realize it has no value.

When you define your Stories this way, you get:

  • The Person- Tells you who you do it for, who to ask for questions, and who approves of the result. Vital for good feedback, communications. Though in Personal Agile this is probably you a lot.
  • The Thing – Tells you what to do. The better defined it is the better idea you have what to do but don’t overdo it.
  • The Reason – Tells you why. Why is a great guidance for evaluating what you do, determining if you’re delivering, and motivating you. Reason is also one of the major places where you discover “hey, this is kinda worthless.”

If you’ve ever done something and wondered “why am I doing this?” imagine how knowing these three things would have helped.

As you can see, the Story method is pretty powerful. Sure you might need more details, you may have to find them, but this is a great way to know enough to get doing things. It also helps prevent over-designing things.

By the way, if you need more details, let me refer you to the classic Kipling poem’s opening line:

“I KEEP six honest serving-men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who.”

You got Who, What, Why. If you need more details see if any of their friends should go in: When, How, and Where.

By the way, when in doubt, yu can use this formula everywhere. To evaluate an action, to quantify a Project. So be it the biggest Project or the simplest task, when confused, ask “why an I doing this thing and for who?”

A few notes:

  • In Personal Agile you may not need to do formally described stories, but it does help. When in doubt, use them – they’re wonderfully clarifying, even if later you go back to more simple terms. If you’re new to this, definitely use them.
  • Some Projects are so big that they have “big stories” or “bundles” of stories called Features, Epics, Legends, etc. These let you organize stories into groups.  I don’t use them in my Personal Agile.

Tasks

Tasks are the final part of good Agile planning and breaking down work. This is when you figure out what you do hands on.

Remember how you broke down Projects into Stories, the smallest bits of value?  Tasks are when you break down a Story to figure what you have to do to get that value.  Every Story has at least one Task, and each Task contributes to completion of that Story.

Figuring out Tasks is also a bit of an art, but is usually more hard-nosed than, say, Stories. You can pretty much look at a Story and figure out what has to be done.  Remember you may find more Tasks are needed, but you can usually get a good start.

There’s no real way to describe Tasks, but I’d describe them as clearly as possible for the sake of clarity.  The value of them is also pretty apparent as they’re directed to a goal.

EXERCISE: Look at one Story for the above exercise.  Describe the Tasks necessary to do it, and try to make them of reasonable size.

Interesting exercise isn’t it?  You can define Tasks but how do you get your hands around how much work they take?  That’s what’s next.

Tasks and size
Tasks are also where sizing takes place. Sure, sometimes people size Stories and even Projects in various ways (I don’t always in my Personal Agile so I won’t cover it). However, no matter what, how you size a task affects real work – so we need to discuss that.

There is a lot of discussion in Agile about how to do this. In turn thereare a lot of great ideas. In turn, a lot of people actually ignore these half the time. The other half they argue.

Me, I use hours of work. If I were planning a larger Project with more people I might use other methods, but in this case I have a pretty good grip on how fast I work.  This also lets me figure out how long I can spend on things and may let me track odd things that just require a block of time (if, say, I want to spend X hours studying)

However I do have an additional rule I call Fibonacci Hours.

I size tasks in how long I think they’ll take. But I have a few rules:

  • Tasks should be sized so in theory I can do them all in one go – even if it may take setting some time aside (usually 5 hours or less).
  • Tasks are sized in hours – minimum one hour.
  • Tasks hour-sizing must fall in the Fibonacci sequence – 1,2,3,5,8,13, etc. Basically each number is the sum of the ones before it. If something is “between” the two I have to make the call if it’s more likely the lesser or the greater.

In using these Fibonacci hours I’ve been amazed how accurate they are – usually more accurate than my attempts to figure the “exact” time. This is because in our ability to estimate, we’re not always good making fine distinctions, especially with larger numbers. This just enforces a pattern that, as a story gets larger, you have to think in a wider range between sizes.

By the way, I try to break things down to never be more than 3 hours, 5 at the most, unless it’s for something odd (like setting aside time to write).

By the way if you use Agile, you’ve seen this used for “points” and other methods of work. I just found they worked for hours.

A Few Tips On Tasks

  • In an ideal situation each Story would have only one task because you were able to break down value so specifically.  This can happen a lot in Personal Agile, but not as much on larger Projects.  It’s something to aim for, but remember it may not be achievable for certain efforts.
  • It’s best to describe tasks well, but in Personal Agile usually you’re the one doing them so don’t waste time.  Just make sure you can remember what you described.
  • A few times above I noted sometimes a task is just spend-so-much-hours on something.  Don’t be afraid to do that – in Personal Agile it really helps.

Onward To Action

OK you know to think about value. You have an idea of how to break down work. Now we’re gonna get started.

By the way, even if you never use any of my other Personal Agile methods, thinking about work like this will help you.

– Steve

 

My Agile Life: More Talking Less Meeting

(This column is posted at www.StevenSavage.com, Steve’s LinkedIn, and Steve’s Tumblr)

More on my use of “Agile” and Scrum in my life!

As I’ve noted, doing personal Agile (in my case Scrum) makes you more aware of ways Agile goes wrong on the job or in your friend’s jobs. It’s contrast, because you can get your life running smoothly with Agile, so breakdowns elsewhere become more apparent.

An important part of Agile is that people communicate, often several times a day, perhaps even unscheduled. This asynchronous communication lets them meet and talk as needed, making the team open and adaptable. It turns development into a dialogue and is about meeting as needed, not meetings.  Communication is meaningful.

Sure there’s the classic Scrum standup (often done in non-scrum processes) but that’s the bare minimum. Good Agile is about good communications, and that doesn’t mean endlessly sitting in conference rooms. That means dialogue when you need it.

Even solo Agile requires communications that can be spontaneous – maybe even moreso when, say, you need to ask someone if they know what it is you found while cleaning the garage.

I’m guessing that if you’re doing Agile at work – and perhaps at home – you’ve got a lot of items blocked because you can’t get ahold of people. Hell, even if you’re not doing Agile I’m going to guess that you need a lot of signoffs to get things moving.  Those signoffs are probably not happening.

My guess is things aren’t moving. You can’t get people to respond. No one is talking but everyone is busy.

What do we do when we need people? We schedule a meeting. Then we have more meetings . . . and it’s harder to reach people.

Remember my theory that we can’t reduce meetings due to meetings? Yeah, this sounds familiar. We also have so many meetings we can’t talk to people.

We’re now so busy talking, because we didn’t talk, that we can’t talk.

So let me make a further radical proposal in Agile – if you have to schedule meetings to take care of five or ten minute touchbases, maybe you’ve got too damn many meetings as it is. OK, my guess is you always think you have too many meetings, but if you’re endlessly blocked because you can’t talk to someone, then it’s out of hand. I’ll also bet most people are blocked because of . . . meetings.

Let’s fix this.

Imagine if you worked on decreasing meetings, but increased the ability for communicating. Dream a dream like this:

  1. Start cutting out meetings, period. Encourage people to read reports, signoff, and look at information radiators. Verify don’t brief, use tacit signoff.
  2. Encourage spontaneous communication when possible. Sure, you’d have to set up some rules so people weren’t bombarded, but it’d help. Besides, when people practice open communication they also learn when not to interrupt others.
  3. Encourage people to block time on calendars where they cant’t be bothered. I do this at home and at work – when I have to focus, I get me some me time. A big calendar block of “DON’T BUG ME” does wonders.
  4. If you have problems, schedule Open Hours for important folks, where people know they’re available. Think of it as a middle ground between spontaneous communication and regular meetings.

There’s my radical thought of the day. If you start reducing meetings, maybe people will actually communicate.

(By the way I do plenty of books for coaching people to improve in various areas, which may also help you out!)

– Steve

 

My Agile Life: Pull

(This column is posted at www.StevenSavage.com, Steve’s LinkedIn, and Steve’s Tumblr)

More on my use of “Agile” and Scrum in my life!

Let’s talk Pull, Agile, and personal productivity. Unfortunately this requires some backstory so I’ll try to keep it short.

  1. I use Scrum as my Agile method to keep life in order. That’s basically “have an ordered list of stuff to do, choose what to do in a timeframe from the top priority, do it, revise, repeat.”
  2. One of the foundational methods of Agile is Kanban. Kanban is simpler – have a workflow, and move work along the various states (like analyzing, doing, testing) while limiting work in progress. Often you only have one item in every state if that. Keeps you from multitasking and a big part is “pull” – something only moves along when nothing is ahead of it, ideally.
  3. Alot of Scrum uses Kanban elements including Work In Progress and Pull.

In this case, I’m big on Work In Progress and Pull. I’ve written about WIP before, so let’s talk Pull. This is a near-forgotten part of good productivity or personal productivity. There’s also a heavy psychological component that, when you acquire it, you’ll find your productivity soaring.

The basic idea of “Pull” is:

  1. You have certain states of work. Usually this is “backlog”, “definining”, “doing”, “testing”, and of course “done.”
  2. “Backlog” and “Done” have no limits, obviously.
  3. our backlog is in order of priority.
  4. hen one state is empty (no work in progress) then you can move an item into it. That’s pull. I like to think of it as a vacuum – when a state is “empty” it can “pull” something that’s ready to move on into it.

Catch the subtlety there? You can only move an item along your workflow when there’s a “void” that pulls it in. If it’s not ready, it doesn’t move (like a column not being ready for an editor who has free time). If there’s something ahead of it (like the editor is editing another column of yours, so your latest has to sit) it doesn’t move. You start thinking not in “pushing things ahead” but making space for things to move along.

I can’t tell you what a revelation this was to me, and it took me awhile to realize just how much I learned. It really started when I had a vacation weekend where no one was around and I wasn’t sure what to do. I had “space” so I not only relaxed, but I just “banged out” a lot of work and chores and the like. i would say “that’s done, I have space, what’s next” and I felt that pull and that workflow.

Later I saw it at work, where one of my teams uses Kanban. I could see flows both work and get jammed up and suddenly saw the importance of thinking in pull. Thinking in pull means keeping your workflow clear of blockages, of constantly focusing on making space and moving things along so other things can move.

This “Pull” idea is also a lot more relaxing than the endless emphasis of “pushing” things along. Pushing things along eventually creates a pileup and a wreck. Thinking in “Pull” means making things run smoothly – and getting more done in the end.

So try this, whether you use the same techniques as me, different ones, or are just trying to be more productive. Focus on “pull,” on keeping your workflow clear of blockages. Move along the thing closest to done first, limit what you have in progress, and see what happens when you open up space for yourself.

(By the way I do plenty of books for coaching people to improve in various areas, which may also help you out!)

– Steve