An agile approach to self-improvement

If there’s one thing I’ve learned during a career in software development it’s that both requirements and priorities change. Regularly.

Picture the scene: you’ve spent weeks gathering requirements for the upcoming Big Project™. You’ve figured everything out down to the tiniest detail, pulling together Gantt charts, resource plans (eugh, they’re people, not resources) and the perfect choice of technology stack. You’re the planning king.

But then things start going wrong. A key member of your team leaves and you have to replace both their physical presence and the knowledge they’ve accumulated. A new regulation comes in and half your remaining team is now pulled on to dealing with the work required to meet the changes. It turns out that you’d missed some of those “tiny” details, including the fact that a key piece of infrastructure just plain doesn’t work the way that trustworthy engineer told you it did. The timeline stretches on and, before you’re even halfway through, the whole project is cancelled because the business’ focus has changed.

It’s exactly experiences like these that have pushed more and more companies to using more agile software development practices, be it Scrum, kanban, lean, XP, or one of myriad other versions. These process tools all have one common aim: delivering working, relevant software as soon as possible. Project timescales are reduced from months or years down to considering what do we need right now, and what’s the smallest step we can make to move us in the right direction?

So the question I have for myself is: how can I apply agile principles to my process of self improvement? I’m not talking about something abstract like writing my own version of the Agile Manifesto. Instead, I’m wondering if it’s possible to take the core agile (lower-case “a”) principle of rapid, focussed delivery, and make it applicable to my aim for self-improvement.

My current plan is as follows:

Now this might not work, but given my penchant for procrastination when I’ve got nothing but a stack of books and a list of potential technologies to “look in to,” starting to break things down into actionable chunks has got to be worth a try.


Now read this

Tales of the unexpected

Sometimes things go wrong. The results of the “something” going wrong are usually fairly obvious — searches not returning, systems not starting, payments not processing — but working out why that “something” stopped working (or started... Continue →