scrum

My Agile Life: A Quick Review

by

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

(My continuing “Agile Life” column, where I use Scrum for a more balanced and productive life continues).

I’ve been using Agile to have a more productive life, and it’s been pretty great. So to help you out (and help me organize my thoughts) here’s what I currently do. I think I’ll do these roundups every few months, so you can try the latest iteration of my system, and I get better at sharing.

First out, what I’m doing is the Agile method of Scrum in my own life. If you’re not familiar with Scrum it’s basically:

  1. Have a ranked backlog of stuff to do.
  2. Choose how much you can do in a given time frame from the top – this timeframe is called a Sprint.
  3. Do it.
  4. Review how you did, revise the backlog, and start a new sprint.

That’s Scrum. Here’s how I do it – first, the lists I keep.

  1. I have an Incubator. This is my list of Neat Stuff to do, summed up. I update it monthly or so and review it monthly as well.
  2. I have a Backlog/Roadmap. This is a list of things I want to do, in order, usually on the Project level, but sometimes broken down into stories (pieces of value). It’s ranked both by importance and “guessed” chronology – a few things are tagged with critical dates. I could probably split these up but I don’t think I need it.
  3. I have a Sprint Backlog.  This is what I decide to do every sprint – which for me is a month. This isn’t ranked, but is more sorted in a project order. This is broken down by Projects, with stories, with specific tasks. I estimate effort by hours. I review this every day.
  4. I have a cumulative flow chart, which is based on Tasks (not normal process, but most of my work breaks down pretty finely). This gives me a visual idea of how I’m doing, and is good practice on using these charts.

What I do is review things every day to see what’s up and decide what to do – but after regular review, I’m usually aware of my next few days of work automatically. I’ve kept a weekly schedule but fell off of it – I’m not sure I need to, as my daily reviews keep me aware of what’s going on.

A few things on how I operate:

  • Break down work into workable components – A real challenge at times as you can treat work as big lumps, or turn it into so many tiny tasks you can’t focus.  Find some way to break things down that you can get things done without overloading yourself, but not so much you can’t keep track of the little parts.
  • Limit Work In Progress, WIP, To 2 items.  WIP keeps you from juggling too many balls. I normally prefer a WIP of one, but when you’re doing Scrum for real life you’re going to have interruptions. Usually at most I have one “in progress” item with another “free item” for all sorts of tasks like cleaning, etc. However if I have one “ball” in the air I make sure any new one is finished right away.
  • Polish that backlog. Keep revising this as you go so when you get ready to plan, you pretty much know what you’re doing next.
  • Keep a regular task backlog. This is one way I save time planning, preparing a list of regular common tasks I have to do monthly so I already know most of my schedule. I copy that into:
  • My projected “next month” backlog. I keep a draft of what I’ll “probably” do next. This helps me plan fast as, about midway through a month, I’m like 75% certain of what’s next if not more.

All of this has made me much more productive – but it may not be for the reasons you think.

Yes, there’s the value of having a tool and a plan of some kind – but you can do that a lot of ways. I’m taking an Agile approach, and that requires me to take an Agile mindset – a focus on adaption, on communication, and on efficiency. The tool reinforces the mindset.  The mindset is what matters.

And the mindset? I’m a lot more relaxed, a lot more effective, and I waste less time.

(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: Fix A Few Things

by

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

(My continuing “Agile Life” column, where I use Scrum for a more balanced and productive life continues).

Many Agile methods use some kind of retrospective to review and improve. I adore them but find they can drag for two reasons: sometimes people hate them and sometimes people go overboard.  It can become a venting session or it can become a case of people shutting down.

Personal retrospectives can be a drag as well for the same reasons, though I find it tends towards the “overboard.”

I find that the “overboard” and the “underboard” are part of the same problem – that retrospectives can be overwhelming.  If you want to discuss what went wrong on a sprint or on a project, you can probably easily find tend or even hundreds of things.  This can lead to people endlessly listing off problems – and people trying to ignore then because there’s so many (and their egos feel threatened).

A retrospective needs you to both focus and not be afraid.

What I’ve learned both as an Agilist and in my own life (where I can’t escape any of this) is that you need to limit what you try to improve. When you focus on one or two or a few things to get right, you can get them done – focus on every problem and you’ll never start, or you just won’t try and review your work.

Besides, as you focus on a limited amount of improvements you can also reinforce the issue that many of the problems that came up were already taken care of.  All those hundreds of problems got taken care of by reasonably mature people or a reasonably mature person and it’s probably not worth going over.  Focus on what needs to be improved.

On top of that, the focus on a limited number of issues can take your ego out of it.  You ignore the vast amount of things you can complain about to focus on things you can and want to fix.  It tones down the fear you may feel of going over the many things that did go wrong, dealt with or not.

I’ve found the “power of Few” to be very helpful in that I can focus on getting better in specific ways – ways that have real value.  Plus it doesn’t’ trigger any insecurities

As an addendum, you should always seek to improve outside of reviews and goals. Good opportunities to get better abound all the time, and seizing on them is a big part of an Agile Mindset. It also helps you get used to facing and fixing problems on the fly – so they don’t gum up your retrospectives (and your self-esteem).

(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: Failure

by

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

I’m talking my “Agile Life” experiment where I use the Agile techniques in Scrum in my everyday life.  Well, it doesn’t always work, so let’s talk failure – specifically something that went bad this Sprint of May.

As you know one of my goals for the May Sprint was to plot a new novel and write chapter 1. That has partially failed – which is a great time to examine what I did wrong and talk failure.

Agile methods are all about learning as opposed to shame.  We all make mistakes, we all have discoveries of what we didn’t know, so the goal is to learn and adapt.

So first, let’s see what happened:

  • I was going to start a new novel, “A Bridge To The Quiet Planet,” an SF/Fantasy mix.
  • I was going to use a lot of the techniques I’d used before to write it – heavy setting detail, iterative plotting. Just on a larger scale.
  • I found things not feeling “right.” The plot was stale, parts came and went, I didn’t feel I had a grasp on the story – I had about 60% of it but something felt off.
  • After analysis I realized I didn’t have a good a grasp as I thought, it wasn’t quite “alive.” There were good parts – there were *great* parts. But it felt half-made.

So now the questions come in – “Why.”

There’s a great technique called “The Five Whys” that I learned – basically to solve a problem, ask why – and when you get an answer, ask why again. Soon you’ll get to the cause, part of the cause, or one of the causes.

  • WHY did it feel wrong? Because it was. It was patchwork.
  • WHY did it feel patchwork? Because some parts were far more fleshed-out than others and they conflicted due to that.
  • WHY are they half fleshed-out? Because my designing was erratic.
  • WHY was my designing erratic? Because I dived in and didn’t think of what I needed to do as a specific set of tasks.
  • WHY did I do that? Because I didn’t think I’d need it, I’d just dive in as I’ve done this before.

I came to realize I got a bit arrogant. I’ve written and built worlds for 40 years. I’ve published books. I should be able to dive into this right because I’ve done so many similar things?

Yep, I should – if I had thought ahead. But I didn’t think about what was needed, didn’t look at my techniques, didn’t break down the work. If this had been a programming project, it’d be the Product Owner and an Engineer saying “hey, we know how to do this easy, so let’s just block out some time” without the Scrum Master saying “why do you think this doesn’t need the usual level of analysis?”

What I should have done is use all my techniques and experience to design a better plan – how long it’d take for this tasks, what tasks were needed, and so on.  It would have made me think, made me more aware of the work needed, and how that work tied together.

Lesson learned – in writing, like anything else, a good work breakdown is needed.  Just because you might be able to do it “from the gut” is no reason not to think it over – especially when you’re getting back in the swing of things.  Had this not been a novel but a shorter work I might not have caught this mistake.

Now of course after finding this the goal is to get back on track. How am I doing that?

  1. I will focus this month on plotting – any time meant for Chapter 1 now moves to plotting.  That helps me get a timeframe.  It’s still adding work to my sprint, so I may move out other plans – since getting this done is important, and spreading it out too much may mean it loses coherence.
  2. Writing is moving out by one month at least – maybe two.  But I’ll try to do Chapter One next month and then slowly ramp up.
  3. To plot the book I am breaking it down into tasks required to get a full plot outline that I can write from.  It’s really more of a product design process or a research task.  I may write up more on that depending how it goes.

The story quality is already looking much better, and I learned something about my own creativity. Also the story may have a slightly off kilter Technomancer riding a motorcycle on top of a moving train, so there’s that.

A good lesson on many grounds.

– Steve