All About Agile | Agile Development Made Easy


Stop Starting, Start Finishing. Unfinished Work is Debt

by Kelly Waters, 12 June 2013 | Agile Teams

I’ve worked with so many development teams now that I’ve lost count.  And I’ve lost count of how many of them have this problem.  The problem of being quick to start things, and not being quite so quick to finish them.

Lean methods seek to address this problem by enforcing WIP (Work In Progress) limits.  Whether or not you use WIP limits, teams really need to focus much more energy (and resources) on finishing what they’ve started, and less on starting the next new thing.

The trouble with having too much work in progress is that it ALL takes longer to complete.  It’s common in teams that have this bad habit to have things linger on, being “nearly finished” for a disproportionate amount of time.  At the end of a Sprint, or a month, or whatever cadence you prefer, lots of things are nearly done, but nothing is actually done.

Another key principle of Lean is Eliminate Waste.  Work In Progress is a form of waste.  To use a manufacturing analogy, we’re building up piles of unsold inventory.  Another way of thinking about unfinished work is that it’s debt.  It’s debt because we’ve incurred costs and spent money building this stuff, but it’s delivered no value yet, i.e. it hasn’t even started being paid back.  Like debt, too much unfinished work, or unfinished work that has been in progress for a long time, is too much debt and needs to be tackled.

In the finance world, there is a known technique that is the quickest way to clear debt.  It’s called snowballing.  The basic idea is this: You make the minimum payment on all debts other than the smallest (i.e. the quickest to clear).  You put any additional money or effort into paying back that.  When it is clear, you keep your total payment for all debts the same, and the amount you used to pay on the debt you’ve just cleared is put towards the next smallest debt.  When that is cleared, you do the same again.  For many people, clearing debts would be a long term thing, and the first one takes ages to clear if you can’t put much extra money towards it.  But the interesting thing about snowballing is that it accelerates.  And over time it accelerates exponentially quickly.

Now let’s think about the same concept for clearing the team’s debt of unfinished work.  What if we were to do the bare minimum on everything other than the thing that is quickest to finish, and apply all our efforts to that.  When that is done, do the same on the next quickest thing.  Keep doing that, pooling the team’s efforts onto the quickest thing to finish, until the team has a smaller, more focused number of things on its plate.  Maybe one thing.  Maybe a few if it’s not possible for the whole team to contribute to the same thing.  But not many things.  And not 1 project per team member!  While doing this, of course, you have to stop starting new things, unless of course they are absolutely critical.

Take a look at your team’s workload and all the unfinished work.  How much is in progress at once?  How long has it been in progress?  If it smells like debt, it probably is.  Take control of it now and start snowballing to get it back under control.  Your delivery will be better for it.  The value to your business will be better for it.  And your team’s morale and reputation will be better for it too.

Home



5 Responses to “Stop Starting, Start Finishing. Unfinished Work is Debt”

  1. It might be worth asking why does the team have so many work items in progress at once?

    Is it because a task is only interesting until it’s a risk?
    It could happen that the team is formed of visionary people. People who see risk as an opportunity for changing the world. Such people are invaluable to a differentiator product. They are the ones who make impossible possible. But they are the ones who become extremely bored with tasks that do not challenge their intellect. Some people get more motivation from finishing stuff and polishing them to be perfect. The solution in this case might not only lie in snowballing. Mixing these different types of people could have a more positive effect.

    Are the requirements so vague that nobody knows when the job is finished?
    In this case, there might be no debt on the code level at all, and it might be easier to find a solution upstream to the team.

    Understanding of the value stream also helps at least in preventing future debt creep. There is an element to agile that many organisations neglect: transparency. If you understand where you are, it’s easier to navigate.

    I had a habit of not opening my post. I couldn’t be bothered. Even if it drove me into debt with several service providers, I failed to care. And debt came and I went into reactive mode. I paid large amounts in one batch instead of small chunks over time. For the past months I became more vigilant and begun to set up direct debits with every company I am in contact with, so this problem would cease to exist.

    When it comes to software, I see a similar pattern. Teams usually know that there is a little problem here, a little problem there, some ugly code right there in the auth module and a bit of a hack around recommendations, but nothing serious. And this information stays in the drawer as my bills did.

    We must stop covering up the truth. We can only pay the debts back if we know about them. That knowledge could come in the form of caring, or in the form of suffering when they stab us in the back. I’ve tried the latter many times with bills and with code too. The former seems to be less painful.

  2. Excellent article! I too am seeing this “technical debt” at the company I work for. They show investors that they have no financial debt on the books but we have a slew of projects that are just sitting there wasting away as management decides what to do with them.

    I find that these projects are not just created by eager developers who are ready to jump in and then not finish, but business people who have a near sighted idea that they went fleshed out with a project only to wake up the next morning and realize they were in some drunken state the day before. In the meantime they go on their next drunken stooper idea and leave the others there to languish in oblivion.

    Hopefully the business minded people, who might not exactly be developers, get a chance to read this too. It can help all sorts of people.

    Thanks!

  3. Infernoz says:

    The “Snowball” approach described, could be slower and more expensive for a real compound interest financial debt, which delayed tasks could manifest as e.g. via delayed income for wages paid. If you can, a better strategy is get a new lower average compound interest rate on as much of the debt as possible, with priority given to the higher interest rate debt, this would be combined with a strategy to pay the minimum on all but the debt with the highest interest rate; that way you ensure that you pay off /all/ the debt as fast as possible, for the least amount.

    The real question is, why are the tasks not prioritized, their progress tracked, and the priority adjusted accordingly?
    Software tools already exist to help manage this; I’m amazed managers still try to manage this in disconnected software and their heads, and make it a pain for us developers to use what software they do have to track our time, so it doesn’t get timely updates!

  4. PM Hut says:

    I think the problem is not the development teams – but rather the business. It’s a huge problem when you have people at the business who want nothing less than perfection. These people are mostly inexperienced and they cause months (if not years) of delay to the project.

    I remember working on a project that was finished in a month (just a month) and then the business started asking for changes and eventually the project was released 2 years later – it was already antiquated then.

  5. Mirco says:

    In my experience (IT internal to a group) project goes long often due to product owner that don’t have enoght clear what he need. He starts with some ideas and along way theese changes. So the development became a kind of prototyping, with so many layers of code and knowledge.
    And time run out.

Leave a Reply

What is 10 + 6 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)