agile life

Steve’s Agile Life: Work Complete

by

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

So more on my “Agile Life” experiment where I use the Agile techniques in Scrum for a more productive, less-stressful life.  This is all about getting things done – so let’s talk about something we don’t often think of, limiting how much we complete in a day or a time period.

Remember when I talked about WIP, work in progress? That’s measuring “what’s not yet done,” and reducing it usually helps productivity and reveals problems.  But I found something related you want to pay attention to.

How much work gets completed in a day and over time.

I began noticing sometimes I’d deliver regular amounts of work, sometimes huge lumps. I came to realize that monitoring how much you get done in a time period – often a day – helps you improve your agility and your work.

Here’s what it can reveal:

 

It Can Reveal Overload

I’m going Agile and it means I’m getting more done.  That makes sense; I’m clear on what to do and what’s next, I can adapt to change, and because of all this I feel less pressure.  Yet, at times, I’m feeling kind of stressed despite improvements.

I realize now that this is because I kept looking for the next thing to do.  The productivity had become habitual and addictive, and I kept trying to move more to “done” – bringing more stress back to a process that’s supposed to reduce it.

This can be worse if you have well-defined stories and tasks. You can blaze through them relatively easily. You can get them to “done” pretty quick. I had a day “off” where I got a lot of work done as I had it broken down well – and then realized “hey, I am tired.” That spike in my cumulative flow was a reminder to go play some Overwatch.

It Can Reveal Bottlenecks

Those sudden droughts and onslaughts of completed work can reveal bottlenecks in your work and your plans.  This is usually heralded by a block of Work In Progress, but isn’t always.

Let’s say you’ve had to write three articles for three websites, sending them each out to editors, each at a different time. You’re getting work done while you wait, maybe keeping your Work In Progress from getting too high – then bang, all the articles come back at once.  Turns out they’re all great, you just have to sign off, but that’s stressful.  It shows your editors may be a bottleneck and you need consistent response time.

Also that sudden onslaught of “done” can be disruptive and jarring – context switching.

It Can Reveal Poor Breakdown

You’re working on all sorts of tasks, from painting a table to writing a book, but it seems they get done in huge lumps.  This might be a sign of poor breakdown – you’re delivering enormous “chunks” of work as you’ve got it set up to be worked on in enormous chunks.  Maybe your stories can be broken down into smaller pieces of value to do.

This can happen in “Agile Life” pretty easy as we may not think of breaking down tasks we’re used to – or lump similar ones into one pile.

It Can Reveal Forgotten Work

This happened to me a great deal in my first “Month Sprint” of April 2017. I noticed some of my erratic delivery and then, when asking myself what I did that day, realizing I’d done a lot of tasks that probably should have been in my backlog. If you see erratic delivery of work, it may mean you should be capturing more work.

This was a real revelation to me – because once I started capturing this work (a mix of social events, obligations, and my cooking schedule), my stress dropped. I was more aware of my goals and time commitment and could plan better and be more agile.

 

So beyond workload and work in progress, keep an eye on how much is getting “done” each day. It may reveal some problems in your plans and give you new ways to improve.

This recalls The 8th Agile Principle the value of a good, sustainable, pace of work.

– Steve

Steve’s Agile Life: Work In Progress

by

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

Here’s the latest on my “Agile Life” experiment (where I use the Agile techniques in  Scrum).  Let’s talk Work In Progress or WIP, something my mentor wanted me to learn more about, and something that inspired my “Agile Life” experiment.

WIP is Work In Progress, a measure of how much is being worked on but is not done. It’s core to the Agile technique of Kanban and the measurement has been incorporated into other practices. WIP is “on it but not done with it” – from waiting on a test for finished software to just note done.

Why is it important? Because in general too much WIP (some would argue any more than one story) is a sign of bad things or can be bad things.  To much WIP might mean:

  • People are multitasking a lot.  Too much being done at once, nothing finished, lots of context shifting.
  • Too many blockers.  A lot is just holding people up.
  • Bad work.  Too much is held up in testing and fixing.
  • Testing problems. Maybe stuff is happening too fast and it cant be tested as fast as it’s getting done, or the testing team has problems.
  • Poor story and task design. The work as broken down is hard to finish or isn’t what people thought it was.

Note the first issue – Multitasking. Even if you’re not blocked by anything else, starting but not finishing things distracts you. You have to context shift. You have to keep track of many things. WIP’s problem can sometimes be its mere existence.

Very quickly as I worked to get more Scrum-like in life, I could see how easy it was to have too much WIP. This was especially bad with domestic chores, things I could “do any time” or “complete whenever.” For my first sprint, it certainly shaped up my housekeeping.

This also made me aware of the issue of tracking completion of Tasks versus Stories. Stories may deliver value so you want to get them out – but individual tasks can also get stuck in never-being done. Tracking those specific “in progress” tasks can be helpful. Makes me wonder if a cumulative flow of both Stories AND tasks would help me or other teams – after all if you’ve got 5 stories not complete due to 5 different tasks or one story not complete due to 5 different tasks, that tells you something.

Some Agile practitioners and practices limit Work In Progress (and people fight over this). The idea is that there’s a limit for a person, team, group, etc. on how much can be up in the air. Past a certain point, it’s either finish it, unblock it, or go do something else not in the Backlog until the stars align. This limits multitasking.

Frankly, I can see why people do it. One Agile Coach I know said in a class that a team at its WIP limit should do nothing until stuff gets done, even if other people spend time to go to training or something. Yes, I watched a highly experienced expert outright state – with conviction – that if a team has too much WIP and one guy has nothing to do, he ought to go read a book instead of start something else. His time would be better spent not complicating everyone’s lives by starting something else.

My guess is you can sympathize.

What do I consider ideal WIP? I’d say for an individual 2 stories and 2 tasks at most, and I’m starting to see why people often make it one story, at least in business.

A final note on WIP. Having lots of small stories you can bang out easy may sound great – but may also tempt you to do them when there’s a big pile of WIP. Even if you can finish something quickly, maybe you ought to finish something from that big pile first.

(By the way, there’s no guarantee reduced WIP is going to have benefits, there’s other variables. But it’s a worthy goal. And yes, people fight over this.)

– Steve

Steve’s Agile Life: Writing Time

by

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

As I write about my “Agile Life” experiment (where I use the Agile techniques in  Scrum) I hope to get others to think about time management.  Looks like my friend Serdar over at Genji press got himself a thinking about time management.

He gets into his own blogging, how he has to carve out time, and how his cadence for projects differs based on the kind of said projects.  It’s a great insight into what he as a blogger does – but also he talks about his way of blocking out work.

As a great deal of his work is writing, he blocks out a time to write each day, setting a minimum time.  If he’s not up for one thing, he’s up for another.  That’s a smart writing technique, and I wanted to note where something like this can fit into the Agile mindset.

  • First of all, he notes that he sets aside time to write, but doesn’t necessarily choose what he writes until he sits down.  This is a great idea on two counts – he has a block of time, and can make the call as to what’s needed at the time.
  • Secondly, if you use this technique, why not consider breaking your writing work down into hour increments and tasks?  That way if you set aside an hour, you can use it to measure progress on projects.  Also, great practice for work breakdowns.
  • Third, this gets you into the habit of practice.  With writing and certain other creative skills, many people respond well to regularity to both accomplish work and hone skills.  Why not make that Agile, with regular writing, broken down so you can slot it into your writing time?
  • Fourth, this removes roadblocks, which is a big part of why we use Agile techniques (as I heard it put once, the prime focus of any Agile method is to find what’s blocking you).  By having this general time you can go around other writing blockages – but by having a set time to write you keep up the regular work you need.

What’s funny for me is I’ve tried both techniques and tend to lean towards not writing each day.  I tend to like task-based writing, to accomplish “x” goal, be it 30 minutes or 2 hours of writing.  But it’s all about finding what works for you.

(Then there’s people asking if they need a definition of “Ready.  Let’s not get into that.)

– Steve