Stop Starting, Start Finishing. Unfinished Work is Debt

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.

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.


  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 3 + 5 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”