my agile life

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: Only Me

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).

The Blame Game is the bane of good organization, good companies, good productivity, and happiness. Yet, how many times do we blame others for problems automatically? How many times have we been blamed for problems automatically?  How many great projects have failed because people fling blame at each other?

OK we know the answer; a lot.

When I began doing my Agile Life, I had a most interesting experience; I had only myself to blame for anything.  I was the only responsible one when most anything went wrong.

Something was late? My fault. Something not done well? My fault. Very, very few cases of things that wreren’t due to me. To blame anyone else would have required a Herculean effort of self-delusion that I just don’t have the energy or lack of morals for.

This was awesome.

Because I am the major or only cause of failure, I am aware of why things go wrong.

Because I am the major or only cause of failure, I know what to improve.

Because I am the major or only cause of failure, I must acknowledge my flaws.

Because I am the major or only cause of failure, I am the major source of success.

Agile is about a mixture of heavy personal responsibility and team responsibility teaches you a lot about dealing with failure.  This personal Agile experience is an excellent compliment to group Agile because it teaches you that responsibility very, very fast.

I’ve also become much, much more aware of my own flaws and mistakes – what I do wrong, what I do write, and how I screw up. I’m a much better person for doing personal Agile.

Of course it’s also painful. I have work habits that are a bit bizarre seen from the outside (mixing casual, obsessive, distractable, and focused). My Scrum Master abilities focus a bit too much on the rituals with the idea they’ll help fix things “eventually.” My “Product Owner” side can forget my “Scrum Master side’s” recommendations on unfamiliar work and forge ahead on spewing ideas to my “Team Member” side.

But at least I have all these insights. I can’t blame anyone else.

Which is great.  Are you ready to try Agile in your life and learn your flaws?

– Steve

Steve’s Agile Life

by

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

You’re going to want to read this; yes it’s on time management, and yes it’s worth it.  I’m going to talk about management but in a non-boring way.

Remember how I moved to Agile techniques and started those weekly reports?  Here’s what happened.

In March I felt my time management could be better; I felt overworked, fell into multitasking, and knew I could do more.  Sound familiar?

I had organized myself by a mix of Getting Things Done (GTG) and Scrum/Agile, but it was casual.  Since I’m a a pro Project Manager and Scrum Master moving towards coaching and process improvement, I know a lot of techniques and processes and coaching tools.  So I coached myself towards more productivity and less stress.

It makes sense; my life is more like a business with my books, and so on.  So what I did was use the Agile practice of Scrum, combined with some GTG (which if you want to really argue, is kind of Kanban, but let’s hold off on that).

To help, here’s a quick refresher about Agile/Scrum – and trust me, you’ll also want to read this.

Agile is a management philosophy that evolved from software development.  To sum it up it’s “A focus on delivering results regularly by working directly with others and responding to change.”  Here’s the 4 parts of the manifesto and 12 principles that will give you an idea.  You really want to read this stuff.

Agile is a MINDSET with a focus on delivery and adaption.  It’s important to keep this in mind – literally.

Scrum is the most well-known Agile Method.  Take a priority-ranked backlog of what you want to do, figure out how much stuff on the top you can do in a given timeframe (called a sprint, usually 2 weeks).  Do the stuff, deliver, evaluate how you did, then do it all again.  The goal is to get something done and learn – that something could be bad or not ready for prime-time, but it’s done.

Make sense?  As I like to put it (sarcastically) if you deliver value often and re-evaluate, you get benefits fast, but also there’s only so much you can screw up in short bursts.

So time to adopt an Agile mindset, and Scrum was the best method to do it.  Here’s what I did.

  1. I made an Agile Backlog (from my GTG Incubator).  This is basically a list of things I want to do ranked in order of value.  I re-evaluate this regularly – this is not a random repository of ideas (I have separate documents for that).
  2. I have a Project List (a GTG artifact) of active initiatives.  This is basically the top of the backlog for what I focus on, and have some plans or outlines.  I’m probably going to merge this into the Backlog.
  3. I have a flight plan (a separate artifact) that lists my general goals per quarter and month for up to two years.  I revise this as I change plans.  This is a quick way to look ahead and look for any schedule collisions. It’s not quite a roadmap, more a projection.
  4. I do monthly sprints, and the above help me decide what to do.  The Projects get priority, the Backlog feeds new projects or smaller initiatives.  The Flight plan lets me evaluate my goals and look for bottlenecks.  Yeah, this could be the classic 2 week sprint, but my life seems to have a monthly cadence.
  5. Work gets broken into stories that provide actual value, like a completed essay or a clean bathroom.  Learning to describe stories and figure value is part of the learning process, and an area of intense discussion in Scrum/Agile.  Short form is think of your target audience what they want and why – “As X I want Y so Z.”
  6. I break stories into distinct tasks used to get the story done.  A good rule is a task is something you can do in a day or less (and if you’re really good, 1-2 hours).  A story may be so distinct and so simple it has only one task – “As a gamer I want a Playstation so I can play Persona 5” doesn’t need any more breakdown unless you REALLY want to block out the drive there, the purchase, the drive back, etc.
  7. I estimate tasks in terms of person-hours so I can look at my workload.  There’s endless discussion in Agile and practices like Scrum on how to “size” tasks, but I find in the end hours always win because eventually whatever you do is going to affect, be measured in, or be communicated in time.

There.  I got a Sprint Backlog of work to do.  how did I use it?

  1. I review my backlog daily to see what I want to do.  I also do a weekly overview of my schedule, work, etc. to get an idea of what’s up.
  2. When I take a task I focus on getting it complete (ready to validate) if not done.  In a few cases complete is done: “Hey, the kitchen floor is no longer disgusting”
  3. If something is not immediately done, in that it continues or needs testing, I get it done in a short time.
  4. If things have to change – so be it.  I know what I’m adding and what I’m taking out.  A lack of change should be due to good foresight – resisting change isn’t inherently a virtue.
  5. I chart my tasks in the categories of Backlog (not started), In Progress, Testing (making sure it’s done), and Done (complete, finished, off my hands).  I do what’s called a Cumulative flow, charting it by task hours in the categories (more on that in the future).
  6. At the end of month do a retrospective- review how things went, decide what to improve.
  7. Plan the next sprint (month).
  8. I might keep my quarterly review (which is part of GTG and other techniques), but am honestly debating how necessary it is.  Probably good to keep it though as I’ve got a lot going on.

This worked great for April – a busy month, yet I got a lot done. It also lets me seriously crawl inside of Scrum and Agile because I’m doing the work, managing myself (Scrum Master), figuring the product (Product Owner), and more.

I’ll be sharing other findings in separate posts, but a few here:

  • You won’t see a lot of “do X by Y.” There’s some obviously, but in general I leave it open – because my daily and weekly reviews let me figure out the best time to do things.
  • I measured completion with Tasks not Stories – which I consider improper as stories deliver value. I did this originally because many of my “life” stories were one task, but it didn’t measure completion of my few multitask stories, which really did affect my time management and sense of completion.  I’m moving to stories next sprint.
  • I’m already keeping a “next sprint” list as I get ideas of what I want to do next; I realized I can easily apply lessons to the next month.  This is a good example of iterative improvement and time-saving – and “backlog polishing.”
  • I keep a “regular” tasks list I can now copy over from sprint to sprint as some tasks for my “Agile Life” keep repeating.
  • This may sound like a radical restructuring – it sort of was and wasn’t.  If you try something like this you don’t have to do it all at once, but add things iteratively, over time.  I’ve got more to add myself.
  • I’m going to be making changes to how I manage the backlog and projects.  To not overwhelm you with technique, I’ll probably post that later after I share some other insights.

Look for more posts on this – a lot more.

– Steve