scrum

My Personal Agile: Value

by

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

I’ve been talking to a few people about my personal use of Agile (specifically Scrum) to be productive.  So let’s get to the next step: thinking about work.

It may seem strange to say your first step is thinking different – it sounds kinda fuzzy doesn’t it? But it’s it’s a core part of Agile methods, and a core part of doing better. How you think about work affects how you do it – or if you do it. Agile is not just some techniques or some airy philosophy – it’s a mindset.

First up is learning to think about value.

Value

Value is something talked about in Agile a lot. The first Agile Principle is:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Substitute software for, well, anything. Substitute customer for whoever your target audience is – including yourself. Your goal in doing anything is to do something of value for someone.

If there’s no value, well the eight Agile Principle states

Simplicity–the art of maximizing the amount of work not done–is essential.

So if something isn’t worth it why do it? Exactly – don’t.

If there’s no one to do it for, don’t do it.

But, that means you have to learn to think about the value of work you do.  I’ll cover more of that in the next section when we look at breaking down work.

EXERCISE: List the top five things you want to get done in ife. Write down in order which is the most important to the least – and no item can be of equal importance to any other (this is force-ranking). What do you learn doing this?

EXERCISE 2: What was the last thing in life that you did that really didn’t need to be done. Why did you do it? How much time would you have saved not doing it?

Value And My Personal Agile

So why is value so . . . valuable? I mean you can guess, but let’s peek behind the curtain.

  • Thinking about value tells you why something should be done – and you can figure out if it’s worth doing.
  • Thinking about value tells you how important something is – and how you should prioritize it. Good productivity – and Agile especially – requires you to know what’s important to do. That helps you organize.
  • Thinking about value tells you who wants it – and that’s the person you want to talk to for guidance and feedback.

The first part of work is knowing why you’re doing it – or why you shouldn’t.

I hope that helps you think about work better. Because next step we’re going to talk about how you break work down – and find its value.

– Steve

 

My Personal Agile: Introduction

by

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

All right people, money where my mouth is time.  I’ve been talking to several friends and my girlfriend about my use of Agile methods (Scrum specifically) at home.  They’re curious, but they noted it’d be easier if I wrote this up.  Realizing I’m a writer I felt kind of dumb because, you know . . . I should have thought of it.

So guess what you’re going to see for the next few weeks?  That’s right – a detailed (but light) guide to my own Personal Agile system readable by normal humans.

Now let’s talk Agile, but first . . .

If You’ve Used Agile:

Don’t worry this isn’t fanatic or preachy stuff.  I come from an engineering and science background, bits and bytes and blood and guts.  I’m interested in results.

However I am big on learning and making good productivity part of everyday behavior.  That might get annoying.

You can probably skip the next section.

If You Haven’t Used Agile:

So what’s this Agile stuff?  Let’s go to a basic outline that is hopelessly minimizing everything but still useful.

  1. Formally or informally a lot of management and productivity has been top-town – orders, schedules, hierarchy, etc.  You get the idea – build a plan and follow it.  These days this is often called “Waterfall” but the basic idea’s been around for most of human history, and “Waterfall” as a concept is a comparatively recent invention.
  2. For a few decades at least (and informally throughout human history) people also have known this whole plan-it-then-try-it method doesn’t work.  Methods of alternate management and workflow have been developed.  Many are older than people realize, but were in specialized markets.  Look up the history of Kanban sometime.
  3. Software really seems to have blown the lid off of a need to find new ways to organize.  Software jacks all the problems of doing any task up to 11: it’s fast, it’s variable, it’s evolving.  A lot of methods to make software management and productivity work better evolved, and people started calling these collectively “Agile.”
  4. In 2001 a whole bunch of Agile people met at a resort to discuss this and produced the Agile Manifesto and the 12 principles, which are seriously worth reading.  This really consolidated and kicked off Agile practices – Agile had a Philosophy, and there was feedback between Philosophy and Methods.
  5. Since this time, people have been adapting various forms of Agile all over.

So that’s it.  People knew traditional management didn’t always work, software really revealed that and drove people to fix it, and from that emerged a more coherent philosophy that sent things into overdrive.

EXERCISE: Go to the Agile Manifesto and read it.  How do you apply (even if accidentally) the four core elements of it?

EXERCISE 2: Read the 12 Agile Principles.  Which make sense to you and which don’t.  Why?

Why Is Agile Different From Other Methods?

(Hey those of you who have used Agile?  You can keep reading now).

Here’s how I see Agile differing from other methods of getting organized that aren’t, well, Agile?

  1. Agile focuses near-obsessively on value and why you’re doing something.  As you may guess, Agile also helps you realize when something is stupid.
  2. Agile focuses on adaptability and responding to – even embracing – change.  This helps you get the most out of change, even when unwelcome.
  3. Agile is heavy on feedback and adjustment and review.  Improvement is baked in.
  4. Agile is about everyone involved practicing it.  This is why I think the Agile Manifesto is so important, it was a basis for people not just doing Agile but becoming Agile.

Cool, So What’s This Scrum Thing?

Scrum is one of the Agile Methodologies or Practices (I see people use the terms interchangeably).  It was my first encounter with Agile, and frankly I consider it and the older practice of Kanban (which I use parts of) to be the best stuff I’ve seen.  Yes, I’m biased.

At a high level, Scrum works like this:

  1. You keep a list of things you want to do in priority order.  That’s the Backlog.
  2. You set aside a block of time to do work, called a sprint.  This is often two weeks in software, but I use a month for myself since my life has a monthly cadence.
  3. Every sprint you look at your Backlog and take all the things you can do from the top down.  You do not skip an item unless it turns out something is more important.  Basically you take the most important things that you can do in that timeframe – that becomes your Sprint Backlog.
  4. You do the work and adjust and adapt.  Sometimes you find that there are issues, sometimes you find old work.  Sometimes you even find you have more time and grab more to do – off the top of the backlog.
  5. At the end of the sprint you figure out how you did, look over the backlog, and do it all again.

Scrum hits a sweet spot of “free-form” and “organized” for many.  You can predict work done more or less.  You know priorities.  If anything goes wrong you review every sprint and can navigate.  You also know what’s expected of you (or from yourself) in a timeframe.

You can probably see how this helps out.  When I implemented my own Personal Agile, which is mostly Scrum, I actually got everything done within the first 3/4 of the month.  I had a gain of 25% productivity – and I was already pretty productive using the Agile-sih “Getting Things Done” method (which is well worth reading up on).

EXERCISE: If you were more efficient – without overloading yourself – how much more do you think you’d get done?  Can you put a percent of gain you think you’d experience.

So What’s Coming Up?

Fine, you got the backstory.  Let’s get to the methods – next up we talk why things matter.

– Steve

 

My Agile Life: Pull

by

(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