personal agile

Work And Effort: Not Always By The Numbers

by

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

Latley I was feeling overloaded but couldn’t figure out how much. Turns out it was mostly in my own head.

Now I’ve been through a move, changes at work, and more. So the last two months my own workload estimates have been a tad off, all things considered. Now that I’m back at it, I decided it was time to get a handle on my work and my life. This included:

  • Making sure I tracked other time-consuming activities, like me workouts.
  • Getting back to my projects.
  • Recovering from the move.

So, I looked at my plans for March . . . and felt overloaded. Why was that, because in my head it made sense. Not much changed. Hell, I wasn’t moving at least.

Something didn’t feel right. You know that feeling of Really Not Right, and I couldn’t place it. Nothing came to mind, so I began to play with my schedule, looking at time taken, past work. Suddenly, something became very clear – an error you may have made in your own personal plans.

What I found was that I had overestimated the amount of work ahead of me, and that made me feel overloaded.

Normally, I’m for a little overestimation, just to be safe. But past a certain point, overestimation becomes not a buffer, but a source of confusion. Your gut, your mind, and your estimates can’t figure out how long things take or where time is going. That’s where I was.

  • I wanted to track more of my regular activities, making sure I accounted for them and didn’t get overloaded. I made sure to pad them a bit – which may matter little on one or two tasks. But when you’re talking things like cooking or working out that you do a lot, then padding adds up pretty fast.
  • I wanted to get back to my projects. Which of course I now was cautious about, so I overestimated a few of those. Which wouldn’t be as bad except I always juggle 2-4 projects.
  • Finally, I wanted to “catch up” on anything that got behind from my move, and of course, overloaded myself on top of some over-estimation.

Yes, in my effort to be Thinking Ahead and Develop A Good Backlog, I ended up overestimating so much out of caution I confused myself. So, uh don’t do that.

I also found I had to modify one of my estimating techniques. Check this out, it may help you.

Fibonacci Revised

As I mentioend in my Personal Agile, I estimate the time things take in hours using Fibonacci numbers – 1,2,3,5,8,13. This is common in abstract estimating as people are bad at determining small differences in large things – it’s easy to know if something is 2 or 3 hours, harder to know if it’s 4 or 5 hours, and real hard to tell if something is 25 or 26 hours. So Fibonacci estimating uses numbers with increasingly large gaps to force you to A) use certain numbers to avoid fiddling in the middle, with the side effect of B) By the time you’re tackling something so large maybe you should break it the hell down.

Now on the high level (beyond 3 hours) this helped me. But, I had lost control of detail on the lower end.

I didn’t differentiate between a 30 minute task an an hour. Or a 90 minute task and 2 hours. As I break stuff down pretty finely, I had overestimated work in many cases – and as noted as I also track many repetitive tasks, this balooned my estimated workload.

So now my “Modified Fibbonachi sequence” is .5, 1, 1.5, 2,3,5,8, 13. I give myself a bit of leeway on the low end.

I’ve wondered if in time I’ll learn enough I won’t need any kind of sequence as a crutch. I suppose I’ll find out – and share it with you.

Takeaways

So some takeaway lessons:

  • If your sense of what you can do and the time you’ll think it’ll take don’t “feel” right that’s a good warning.
  • Be careful on overestimation and adding too much buffer time to things you’re trying to get done. That causes confusion – and may squeeze out work you can do.
  • In estimating how long it takes to do things, tools like Fibonacci numbers may help on the high end, but give yourself leeway on smaller estimates.

– Steve

My Personal Agile: End Of Sprint

by

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

The sprint is done. The Retrospective is done. So now what?

You start over again.  Your sprint ended but another one begins right after.  You apply what you learned and move forward.  Agile is about moving forward; its a vehicle not a destination.

Here’s what I do in my Personal Agile when a sprint ends:

  • Look at the Incubator. Add or subtract things as you need.  Re-order them to fit the priorities you have – which probably changed.  I actually do this during the Sprint now, having gotten better at incorporating my lessons.
  • With the Incubator re-ordered, I then look at the Backlog and see what I should add to it from the Incubator, subtract (and maybe even move back to the Incubator), or re-prioritize.  I may also see ways to break down the work in there as well.  Much like the Incubator, in time I’ve come to modify it during the Sprint as I learn.
  • I put any undone work back into the Backlog, and rerank it. A surprising amount of time you’ll find undone work isn’t the highest priority. Sometimes you even decide not to do it and just drop it.
  • I review the Regular Tasks list to see if I need to change it. In time you’ll probably not need to do it because you’ll change it during the sprint and in the Retrospective.
  • I plan a new Sprint – Copying the Regular Tasks and then adding as much of the Backlog as I can do for a month.
  • I start the sprint.

That’s it. It’s back to the beginning. You’re done and you restart.

Now a few bits of advice:

  • A lot of the review at the start and end of sprint will eventually work into your regular work. You’ll just get ideas or discover re-prioritizing you need to do as you go.  It’s possible you will need less retrospective and planning time – but don’t change those times until you seriously review them.
  • You’ll get better at review and planning over time. It’s a real skillset you can develop – that may be useful in life in general.
  • Don’t try to get review and planning perfect. Agile is about adaptability, you do your best and keep getting better.
  • Don’t overload yourself. Its very very easy to do that, especially on the second or third sprint when you really get going.

So there you go, my personal Agile. I hope that’s going to help you out.  I’m going to try to bundle this advice up into a free ebook at some point.

– Steve

 

My Personal Agile: The End-Of-Sprint Retrospective

by

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

So your sprint is done. Congrats. Now it’s time for the Retrospective!

The Retrospective is a big part of Scrum, and there are variants of it in a variety of Agile practices. It’s simply sitting down and asking yourself “how did it go,” finding things to improve, and improving them.

It sounds simple, and it is. That’s the point. It’s an obvious, common sense thing to do is regularly review and improve. It’s just not common enough in practice.

Think of it this way, it’s great to stop now and then and decide how to get better. You just gotta make room to review and improve, and Scrum – and my personal-life implementation of it – make it explicit.

So here’s what you do.

The Retrospective

First, set aside time for the Retrospective.  It should always be timeboxed, and I use an hour.  If it doesn’t take an hour, fine – if it does, well you stop anyway.

Here’s how I review in a Retrospective:

  • First, ask yourself what worked. What kept you moving forward, getting things done, and what did you do right? It’s good to focus on the positive here, because if you do enough stuff right you’ll do less wrong.
  • Secondly, ask yourself what went wrong. Focus on specific things that went wrong that are improvable. There will be stuff, trust me.
  • Third, ask yourself what work you couldn’t get done and why. Note that’s not necessarily a wrong – maybe something wasn’t needed. But it let’s you figure out specifics.
  • Fourth, ask yourself what work you discovered you had to do that you didn’t realize. Always good to keep yourself aware of surprises.

You probably have a lot of stuff. But now you gotta make it actionable. What I usually do is list down all the items above, prioritize them, and work in addressing what I learned (good and bad) in actionable items.  Don’t just “not” do something, focus on doing better.  Take a good thing and find ways to repeat it.

As you come up with actionable items, there’s a few ways to record them so they get done:

  • New tasks in the Regular Tasks list. Often undiscovered work in my Personal Agile is something that reguarly occupies time at specific intervals.
  • New things in your backlog or incubator – say if you want to edit better, set aside a few hours to read up on it.
  • Habits you need to improve. I keep a list of what to improve and review it every few days.

Sounds overwhelming? It can be. So focus on the important things that you know you can address.  Don’t overload yourself.

You’ll catch it next time.

Velocity

Velocity is a measure of how much work you got done in a Sprint.  As you examine Velocity over time, you learn how much work you can take – maybe.  There’s a few arguments about how to apply Velocity in Agile, so I’m going to give you my opinions.

Here’s how to get and use Velocity:

  • Measure how much work you got done in that sprint. As noted I use hours of work.
  • Keep a record of these hours per sprint (month). I keep a list in the same spreadsheet as my tracking lists. This lets me compare month to month and make notes.
  • This gives you a rough idea over time of how much work you can get done at a given time.
  • * As you plan sprints, look at your past Velocities to help you decide how much work you can do. This keeps you from overloading – or underloading – yourself.
  • It helps you keep a reasonable amount of work, creating smooth, regular productivity.  Note that’s helps because . . .

Here’s the thing, you can’t be sure the numbers are always perfect.  Velocity is a guide, but each month is different, from holidays to illness to vacation.  Each task is different, and sometimes things that take the same time can be mentally taxing or better done in different situations.

So I use Velocity as a a check, a suggestion, and a way to catch me overloading myself.  But each sprint I also do a gut-check if I can really handle the workload I want to do, for those given tasks.  Velocity is just one tool – but a good one.

What’s Next?

What’s next? Your retrospective is done. Time to end the sprint and start a new one!

– Steve