One of the "softer" sides of development is time management. We do this on both a macro scale (project planning, estimates, what goes into the Sprint, etc.) and a micro scale (what am I going to work on today?). Most developers on most days are concerned with micro time management -- and many good project managers realize a lot of important decisions get made there as well ("it seemed like it would be a quick to fix so I went in and did it" or "Gina came over and asked me about this defect so I fixed it."). This is especially true of programmers on many projects, a few teams, and with some maintenance and support involved in their work.
The problem is: time management, even on a small scale is hard. We spend a lot of time learning how to get good at macro time management and very carefully lay out our project priorities for the release and the iteration. But that means little if day to day the developers don't have a good system to find the right balance of focus on those priorities versus just the right amount of focus on email, meetings, last-minute feature requests, needs from other projects, helping others on the team, etc.
I do not profess to have a solution -- I thought I would share three strategies that I have tried over my career (I am sure there have been others). If you want to try one of these, great! Let me know how it goes! If you have another approach, please share or email!
When I first started at Summa, I did not have a system for how to manage my time. I let tasks come in and go out -- mostly just remembering what I had promised to get done and when it was due. To help, I would star or label emails and maintain a few lists. I am organized and careful so this worked out for a while, but it did not take long for the system to start buckling with the weight of what I was asking it to do.
Within my first year, I had a 2 or 3 week period where I was helping out on three different projects -- and keeping emails straight was not going to cut it. Thankfully, approach #2 entered my life soon after...
Scrum is an agile technique for managing teams and projects. It's goal is not to be prescriptive about anything, let alone my day, but I found that it's philosophies were having a radical impact on the way I organized myself.
It's hard to explain how without a deep understanding of what being on a Scrum team feels really feels like. I don't know who you are -- maybe you've been on Scrum teams maybe not. I don't want to teach you the basics, but I do want to explain how they revolutionized my day.
One thing a Scrum team does is have a daily stand-up meeting. During this meeting, each team member announces what they did since the previous stand-up, what they will do before the next, and any impediments in their way. At first, I just went through the motions, but as I understood what it was about, it really started to change things. Here are some important points:
- I talk about what I will do before the next meeting. I was used to saying, "I will continue work on the User DAO." But my friendly compatriots would not let that slide. The stand-up is about making commitments to the team, and breaking your tasks into day-size (or smaller) chunks. Set a goal for what you will (and can) accomplish before the next meeting. Lofty endless goals do not cut it.
- It is also an exercise in focus. Because I made that commitment to the team, it is that same team I need to face if I have not achieved one of those goals. This is not scary -- they understand when it takes longer than expected or I ran into trouble. But if I got distracted by a feature someone stopped in to ask about, or a bug I found, they are there to put me back on track.
- I also now have a list of tasks -- done and to do -- and I am writing them each day in a growing OneNote list. Each time I run out, I can go back to the Sprint backlog, whether it lives in a spreadsheet or (preferably) Rally to pull out my next story.
- Scrum also gives us a win-win solution to the daily issues that come up. If a last minute defect or request comes up, I used to have to choose between fixing it now (at the expense of my current work and context) or adding it to a list and potentially forgetting it. Now, we can safely add it to the product backlog. While it is outside of the Sprint scope, the product owners know it will be there for them to prioritize at the next Sprint planning and I can continue on developing happily!
After a handful of years, the Scrum method was still leaving something to be desired. Mainly:
- I would still find myself with days where I had accomplished none or few of my committed tasks
- I would occasionally be thrown back in the Wild West -- multiple projects, multiple demands, no backlogs of any kind. Scrum method doesn't really help you out there.
I was then fortunate enough to hear a lightning talk about the Pomodoro Technique. There are many parts to the technique, but the part that most interested me was the focus on micro-micro time management. Here are some highlights:
- Break down your daily tasks into subtasks that can be performed in ~25 minutes.
- Choose a task and set your pomodoro timer (pictured at the left, looks like a tomato -- or pomodoro, in Italian) for 25 mins.
- This is an intensive period. Some pomodoros can be focused on checking email or following up with someone on a debugging problem, but otherwise you disregard all distraction from the task at hand.
- Each second the mechanical timer ticks, reminding you to focus on the task in front of you.
- At 25 mins, the timer rings, and you take a break.
When I heard about it, I was excited. It sounded fantastic. In practice, I find I can only do it in short bursts. I often find the focus amazingly helpful. But it is hard to get much done in 25 mins. Many of my tasks are "continue on from the last task." The biggest help is that every 25 mins I am reminded of my progress throughout the day, and my progress against my original plan. When I start to veer off course, I can see it early, even when I can't help it.
So currently, I use a mix of all 3. Please feel free to comment and/or share your own techniques!
* "On the bench" refers to time that us consultants spend working on the home office when not on a customer engagement.