Agile

My Agile Life: The Line Isn’t So Dead

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

Right now I’m doing Agile methods in my own life, specifically Scrum.  This has been very successful, both in terms of becoming productive, but also in truly understanding good process and productivity.  However, I often felt (and feel) odd bits of discomfort, concerns over things being late, and so on even though I had a great grasp of how things were going.

Why am I worrying despite having such visibility into my own work?  I literally know my plans for a month, I can adjust on the fly, I have a backlog/roadmap fusion?  Why am I worrying?

This article on Kanban made it clear –  http://www.personalkanban.com/pk/primers/how-to-limit-your-work-in-progress-1calm-down-and-finish/.  I was still focused on deadlines.  Wait, deadlines as bad?  Sometimes.

Think of it this way.  Agile methods are about adaptability and doing things right – a lot of good productivity methods are the same way.  The thing is if you focus on the deadline, you often forget about doing things right – and you stress yourself out.

For example, my fiction book.  I have a “deadline” for this that’s set purely in my head for very little good reason.  This deadline has smaller deadlines.  When I stepped back I realized that these deadlines were arbitrary and affected my productivity and work breakdown.  Getting back into the swing of fiction was a bit of a challenge, and arbitrary constraints kept me from focusing on my craftsmanship.

Instead I had to ask not just when things had to be done, but what’s the most productive way to approach my work – all work.  Not just a book, or cleaning the bathroom, or anything else.  What’s the most important things to do and how do I do them effectively was more important than a given deadline in most cases.

Sure the deadline mattered, but unless the deadline was truly more important than doing it right, it wasn’t a worry.  By the way, the book may also be about a month later than I predicted.  You can guess why.

This is a subtle part of Agile methods, and one I missed.  Scrum may have it’s timeboxed sprints, but is always re-prioritizing.  Kanban focuses on Work In progress with priority in the background. Most agile methods are not compatible with our old ways of thinking where the deadline has to rule everything.

Sounds weird.  Ask yourself this – what if you had a choice to do a good job but it’d be late or done in parts, or delivering something bad on time?

As an example, let’s say something has to get done at the end of the month.  You of course rush this and do it early – but is it the best thing to do earlier that month?  Could it delay other work that backs up on you?  Could it be you need to do it in stages to get feedback to get it right?  What if making it a week late made it far better?  What if you did part of it and got feedback and did the second half the first week of the next month?

Also the focus on the deadline may make you miss doing things right.  Consider this – if you focus on doing something well, won’t you get it done quicker, especially over time?  Won’t it last longer?  Won’t focusing on quality and work first, ironically, mean you’ve got a better chance of hitting the deadline (or at least being more on time later)?

Now back to my writing.  I had gotten so focused on my deadline I hadn’t thought about the best way to do things – and as I improve/polish my fiction writing, I need a bit of “space.”  So I set aside a block of time a month to work on the novel, each task takes some of that allocated time.  I can adapt to tasks and needs of this highly chaotic effort. Now when I decide what task to do then I focus on quality and careful sizing, but I’m not overplanning around a deadline.

(Eventually, as I improve/polish/shake the rust off I probably can be more scheduled).

In all Agile methods, to one extent or another (less in Scrum, more in Kanban), you focus on the best ways to be productive first.  Letting old ways of thinking about when things are due or deadlines can, ironically, interfere with results.

I’m not going to knock deadlines.  They have their place.  But when they interfere with doing good work, you have to ask just how much value they have . . .

(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: By The Numbers

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

Let’s talk estimating how much work something takes. This may sound boring, it will get abstract, but stick with me here – it’s pretty interesting.

I’m using the Agile method of Scrum in my own life, which involves sizing work to know how “big” it is. If you’re not familiar with Agile practices, just know this is an area where pros argue a lot, so if you think we’ve got it figured out, you’re wrong.

I size my personal work in terms of hours to complete because I’m self-aware enough to get those estimates reasonably right. It’s not perfect, and I wanted to get better. I think I found a solution while reading The Elements Of Scrum as a refresher, because the authors explained the challenges of sizing work better than I’ve ever seen.

Again hold on here, because we got some backstory.

In Scrum (and related methods) work is often sized in abstract points – the smallest piece is a one point, something twice the size is a two, and so on. Then people figure out how many “points” of work they can do in a given time – and this often works very well (I’ve seen new teams get it 80% right out of the gate).

Why does this work? Because people are great at relative sizing (this is twice the size of that thing) but not so much at doing specific time estimates. Leverage this ability and people get an idea of how big (or small) work is, and they can then do a decent job of figuring what can be done in a given time. Sort of zooming from general to specifics.

Sounds simple? It is, but many Scrum practitioners require points to be in the Fibbonacci sequence – 1,2,3,5,8, and so on. So something twice the size of “1” is a “2” – but if something is twice the size of a “2” you have to call it as more likely to be a “3” or a “5.” Sound weird? There’s a reason.

The author explained it simply that drove this point home:

  1. People are good at comparing the sizes of small things but have trouble with larger things. This applies to time take to sizes of physical objects and more.
  2. #1 gets worse the larger the things being compared are.
  3. You use the Fibbonachi sequence as the range between “allowed” sizes gets larger and larger, forcing you to make a judgement call and giving you a bit of buffer.

Where does this come into my time estimates? Well my time estimates weren’t bad, but they weren’t great. I also didn’t want to use points as some of my “life stuff” was far better measured in hours. So I started using Fibbonaci sequencing to estimate hours of work because this simple explanation made me realize I’d falsely thought I could estimate large stories as easy as small.

So right now the smallest piece of work is one hour – but I can’t say something is six hours, I have to ask if it’s more likely to be 5 or 8. Sure there’s probably over and under-estimation but it evens out.

I started doing this late June and in full this July – and it was an eye opener:

  • In larger pieces of work, had I used Fibbonachi numbers on big things, those would have been more accurate. Yes, some of my estimates were worse when I tried to be specific instead of using some constraint like “is it closer to 5 hours or 8”
  • Some of my fiddly little estimates (45 minutes, 90 minutes) were less accurate than their Fibbonachi counterparts.
  • My best estimates happened on things that were 2 to 3 hours long – fortunately the majority of my work. However there was enough “mis-estimation” in large and small items to probably throw off my monthly estimates by around 10-20 hours.
  • Items that were 8 hours or more were a warning sign to break things down – those were often woefully inaccurate and hard to work with.
  • Items that I did break down usually surprised me – there was often more work than I thought.  Breakdowns (again, using Fibonacci) were more accurate.

I’m going to be sticking with Fibonacci hours for now – maybe you want to try this in your own life, even if you’re not using Scrum or Agile techniques.

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