Agile

My Agile Life: That Glorious Flow

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’m using Scrum to help order my own life. It’s going pretty well, and one of the things that helps is ease of communication, because most of my communication is with me. That’s the Agile ideal of regular, personal communications among team members made easier by me being pretty much the team.  Communication is easy when its in your own head.

This made me think about Scrum and Agile methods when multiple people are involved, from developers to customers. The clarity of my own Scrum-At-Home made me realize how many projects are held up by poor communication, even supposedly Agile ones.

How often is communication delayed on a project? An hour delay in communication can mean days of delay in a project.

How often is communication withheld to avoid conflict or trouble? A lack of information ultimately has to be made up for.

How often is communication handled by some people that aren’t doing, testing, or otherwise involved in the work? Someone abstract from the results will be abstract in their communication.

How often is communication the result of endless layers of people? It becomes a game of telephone operator, of checking and re-checking.

A lot of projects go wrong because of communication.  This is why communication matters, and why the Agile manifesto is almost entirely about communication:

  • Individuals and interactions over processes and tools – TALK directly to people.
  • Working software over comprehensive documentation – RESULTS over documenting them.
  • Customer collaboration over contract negotiation – WORK with people over messing around with fiddly pits.
  • Responding to change over following a plan – CHANGE in response to information.

Running a “Scrum of One” gives you an idea of what near-perfect communication is since you’re the only one involved. That feeling of flow, of productivity, is what you should be feeling in Agile projects at work. When you don’t feel that, something’s wrong.

My guess is you’re used to feeling something is wrong in your projects.

This is one of the many reasons I reccomend personal Agile to people. Done right, you know what real productivity feels like, real communication. Done right, you learn lessons you can apply.

(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: Agile Relaxation Your Relaxation

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 put a lot of time here discussing agile techniques and mindsets for productivity.  But, let’s discuss relaxing and how it applies to an Agile Life.

Relaxing?  Having fun?  Yes, these are part of your life, so you’re going to have to figure how to handle them.  If you don’t, then you’ll either be less productive than you expect, or burn yourself out not relaxing or relaxing too hard.

First, relaxing and having fun can take time, obviously.  So how do you account for them in your taking an Agile approach to life?  I find two approaches work:

  1. One approach is to make sure you pick a workload that gives you time to relax.  If you’re good at making that call you should be fine – by the way, I’m not.
  2. A second approach is to capture social time as part of your plan – actual tasks/stories.  That way you get whole blocks of time to relax and it reminds you to relax.  This is probably good if you’re a bit of a workaholic – they act as roadblocks to that tendancy.
  3. A third approach, which I use, is to combine the above.  I capture major social events, and try to balance things out otherwise.  This mostly works for me.  I actually think if I did #2 I’d way overplan my own relaxing.

Now, once you find a way to make sure you have time to relax, I’ve found you have to approach it with the right mindset.  This is important – and believe it or not I’ve actually learned to relax better with Agile.

RESPECT YOUR WIP: I’ve discussed WIP, Work In Progress, the amount of items you want to work on at one time so you’re not distracted (I set my limit to 2).  Relaxing should be part of your WIP – if you do something big (like a con or a party) it should not violate your WIP limit.  If your WIP limit is one item at a time, you should have your plate of work cleared so you can focus and enjoy.

FOCUS ON YOUR FUN: Much as you want to avoid multitasking when working on something, you should avoid the same thing when relaxing, at least on big things (like a party, a really good video game, or so on). Give yourself a chance to have fun, don’t suddenly switch to work in the middle of it, don’t try to fuse “serious” relaxing with actual tasks.   Just as you should focus on a task, you should clear your mind for fun.

So there you go.  Some Agile insights on fun.  That’s why I do these things.

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