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:
- Define goals for the next three months. What do I want to achieve within this time period? The aim is to make these measurable (so it’s easy to say “yes I’ve done that”) but I’m not going to get hung up on that too much. An example might be to read three of the (many) books I have waiting, or to publish one piece of open-source software written in a specific language I’ve not used before. This list should be prioritised, and not too long.
- Break out the next steps to move me towards those goals. This might be reading three chapters in a specific book or, in the case of the goal of releasing something open-source in a new language, getting my dev environment set up for that and having something small compiling and running.
- Commit to two-week sprints. Given the tasks defined above, which can I realistically commit to achieving within the time I have available over next two weeks? As I have a full-time job, an hour-each-way commute, and an awesome baby boy, time is very limited, so I’m currently planning on fitting in 10 hours every two weeks. We’ll see how that goes.
- Perform a retrospective at the end of each sprint. Did I get everything done that I said I would? If not, why not? Did something unexpected come up which meant I didn’t get as much time as I thought I would? Did I end up doing way more on one task and not get around to another? Why is that, and does it affect my priorities for the next sprint?
- Review goals and next steps, given the knowledge and experience that I’ve gained from the last two weeks. Has a new book come out that I’d like to bump to the front of the queue? Are my priorities still the same as they were at the beginning of the sprint? Has something taken my fancy, or did I just plain not enjoy something? I’m not a masochist: I’m doing this for fun and interest as much as self-improvement.
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.