Agile

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

 

A Writer’s Life: Space

by

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

This month I’m trying to write at least 24,000 words, preferably 30,000.  This isn’t due to any NaNoWriMo thing, it’s a personal challenge to up my productivity.  In setting this goal, I ran into a problem.

I’d set aside time to write, but it felt constrained.  A punishment, a forced duty.

Yet when I’d get writing, I’d often enjoy it.  I find that even when you don’t want to write, doing it for five minutes usually unblocks you.  Besides, even if you hate it, you’re going to edit it later, so might as well enjoy half-baked crap as you make it.

At this point I knew my “ugh, time to write” reaction was irrational.  So I set about thinking of how I could “re-imagine” that writing time to make me see it in a positive light.  Not so much tricking myself, but more how to take a better attitude.

At the same time, I was also discussing the concept of “Pull” in Kanban, and Agile methodology.  So you can guess this is another one of my Agile/Writing posts.

Anyway, the idea in Kanban is you only work on something when you have space to do it – then you “Pull.”  It’s the opposite of “Pushing” work.  If you’re blocked up, you don’t Pull in new work, you focus on getting things moving.  If you can’t get anything moving because of other people, go do something else like take a class or get a coffee once you’re done yelling at them

It sounds weird, but then you realize that Kanban gives you “space” to work.  “Space” to take tasks on when you’re ready.  It’s very much like my earlier thoughts on the subject.

That’s when I realized that setting aside writing time was not making myself write – it was setting aside Space to write.  That 30 minutes or 60 minutes where I’m clear to write.

This changed my mindset (for the most part).  It felt less constrained, less forced, less trapped.  Sometimes it even felt amazing – “a whole hour to write, wow!”  Oh sure I still get those moments of feeling I’m forcing myself, but they’re diminished – and I can rethink that time as “space” and reduce the feelings.

Let’s see if this gets even better over time, but it’s certainly helped already.

– Steve

My Agile Life: More Talking Less Meeting

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!

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