Agile frameworks and approaches put a high degree of attention on getting things done quickly and efficiently. The end goal being to get software into production as efficiently as possible with a level of quality that makes the customer happy and provides a good return on investment. You will often hear people talking about agile (and lean for that matter) also talking about waste and using “inspect and adapt” to minimize wasted effort.
One of the things I see teams doing regularly is taking a day to day approach to development that completely ignores personal time management. A team may estimate a task to take, say 8 hours, and generally it will get done in or around that timeframe (it is an estimate after all), but if you actually watch how people approach completing that task it soon becomes apparent that the 8 hours spent on that task isn’t really 8 hours of good solid effort at all.
The task may have had 8 hours elapse between when it was started and when it was finished – but the actual time spent on the task is typically somewhere between 4 and 6. Where did the other 2 to 4 hours of time go? Sure there’s toilet breaks, coffee runs and helping out others on the team out, but that’s not 2 to 4 hours each and every day is it?
This lost time is what teams typically refer to in planning meetings as their “focus factor”. Some teams have a focus factor of 50%, other teams a focus factor of 75%, whatever. Either way, teams are looking a potential performance improvement of between 33% and 100% right in the face and doing absolutely nothing about it! In fact, they are institutionalising low productivity and calling it good planning. Really, all they are doing is admitting that change is hard and giving up before they even try and improve things.
This is where a team doing retrospectives and wanting to improve can really make a big gain.
As an example of this lost time, let’s have a look at just two things that tend to suck up those non-development hours.
Email is the Great Evil of Our Time!
Maybe that’s going a little too far :-) However the next time you get an email from someone, see how long it takes to put your response together. If you write a response that has more than one or two lines in it then I’m going to guess that it will take you a LOT longer to write that response than it would have if you had just talked to the person in person or over the phone.
In fact if you really want to scare yourself, go grab a copy of ManicTime and use it see just how much time you spend in your email client of choice. In fact, do it anyway. Download it, install it and run it just for one day and look at the results. You might just find that your focus factor of 75% was too high! Maybe that explains the difficulty you’re having getting sprints completed well.
Oh, if you’re in one of those organisations where email is used as the ass-covering tool of choice, don’t forgo conversations and revert to email just to cover your butt. Use email as a confirmation tool and note down bullet points from your conversation – during the conversation – to later send through a “just confirming what we talked about in our phone call” email instead. It’s much quicker.
Multitasking and Self Induced ADD
Multi Tasking is the other great way to slow yourself down. The cost of task switching for humans is nasty – our brains just aren’t wired up the right way to be able to swap in and out of context quickly. We may convince ourselves that we can, and we may try to lie to ourselves about how the tech generation are all skilled multi taskers, but really, it’s all bubcus and an excuse for being unable to concentrate for more than 2 minutes at a time.
In fact all we really do when we have multitasking as our modus operandi is become really good at starting things and become really terrible at finishing them. Why? Because constant task switching trains our brains to have short attention spans. Short attention spans mean that we have a problem whenever a squirrel shows up. We’ll get distracted and go chasing after it and to get back on track we have to sniff around what we were doing before and try and piece back all the various things we had in our head before the distraction showed up in the first place.
Short attention spans create an illusion of being productive through the act of being busy. We generate lots of movement and energy when we’re busy, but in reality all that movement just creates a big dust cloud that masks just how little progress we make.
For us humans, the best way to finish tasks as quickly as possible is to do them sequentially. This costs us a single context switch between tasks instead of a context switch each time we change from one task to another. For us developers locking in on a single task also gives us the opportunity we need to get us into the zone – that magical place where high quality code just seems to fly out of our fingers, where we flow from one thing to the next with ease, and where we get stuff done ten times faster than we would have normally.
Sure it sounds great, but development has so many chances for distraction. Not sure how to do something? Google it, see something else interesting and go investigate that instead. The task we’re doing is boring? Let’s take a little break and play solitaire for a few minutes. This compile is taking more than 5 seconds? Maybe we’ll just check email while we wait. it’s all self induced ADD and we need to learn to stop.
So What’s The Answer?
It comes to this: Personal time management, discipline and focus. How do you, yourself, personally, manage your time as an individual? How do you maintain focus? How long do you maintain it for? When do you take a breather since all that concentrating can be tiring? How tired are you right now?
First up, let’s deal with some simple distractions. Have a look around you right now at all the possible distractions you have – twitter, facebook, rss feeds, email, news sites, instant messenger, a side conversation you could join in on, that delicious smell coming from the kitchen, txting, flash games, the list goes on. Things like twitter, outlook and IM in particular can be really nasty because of their interrupting “new message” toaster notifications and beeps. Turn those notifications off. Do it. Go into settings and turn them off. Right now. It’s OK to leave those apps running, just delay checking for new tweets, emails and messages until until you finish what you’re doing.
What if you’re waiting for that compile or CI build to complete, what do you do? Press Alt+Tab and go read a blog entry or 5 for the next few minutes? It’s easy for that few minutes to turn into 10 or 20. And yet the compile itself only took 3 minutes to complete. That’s a lot of wasted time and a definite mental context switch you have to deal with. Yet watching a compile is mind numbingly dull. So why don’t you think about some refactoring you could apply, or the next test that you could write, or the design for the next task that you’ll get started on next. There’s plenty of non-keyboard activities you can do that keep you focused on the task at hand and not chasing squirrels.
This is also where techniques such as the Pomodoro Technique and pair programming can help.
Pairing provides a focus boost simply because you have someone next to you who is also focused on the same goal as you. The two of you keep each other on track. I’m not going to delve to much into pairing here, however if you consider what it does for our focus factor you can see how teams that use pairing can easily get a return on the supposed cost of putting two people onto a single task, simply because they won’t get as easily distracted and can thus complete their tasks faster.
For individuals not in a pairing situation, the Pomodoro Technique is a simple process they can follow and works like this:
1. Choose a task to be accomplished
2. Set the Pomodoro to 25 minutes (the Pomodoro is the timer)
3. Work on the task until the Pomodoro rings, then put a check on your sheet of paper
4. Take a short break (5 minutes is OK)
5. Every 4 Pomodoros take a longer break
Quite simply it says focus on just one task until either the task is complete or 25 minutes is up. When that happens, give yourself a mental break. It’s effectively a series of short, sharp personal sprints.
When you’re working on your 25 minute pomodoro you don’t open email, you don’t look at twitter, you don’t check news sites, you don’t get a coffee or anything else. You just work on the task. All those other things are for filling those 5 minute breaks you have. And if you’re in an organisation with a plethora of email – then one of your pomodoros should probably be spent dealing with that email!
Oh, don’t worry if you don’t have a clock that looks like a tomato either. Just grab yourself one of the many pomodoro timer apps, such as FocusBooster, and use it instead.
You may find this hard at first, but once you do it a few times, you’ll find it becomes easier and easier to do. You’ll find that without any changes to technology, skills, work hours, or otherwise that doing this will result in an increase in team productivity and velocity – and all you’ve had to do is be a little more disciplined and a little more focused on the task at hand.
Let’s work smarter, not harder, right?
P.S. The irony that a long post like this isn’t likely to be read all the way through by people with short attention spans isn’t lost on me! ;-)