The Pomodoro Technique is about focus and maintaining that focus. In a sentence, it is about focusing on a single task for 25 minutes straight, no interruptions. Can you do it? For a lot of people, it is pretty hard. Email, twitter, facebook, SMS, and IM all compete for your attention and distract you from your work. People also like to procrastinate. When faced with a difficult task, you’d much rather do something easy and fun. It is common to leave essays and reports to the last minute.

In recent years, I’ve got better at focusing on tasks. Unfortunately, I had swung to the other extreme and I often went “dark”. I would turn everything off and lock myself away. I would quit email and ignore the phone. I also stopped taking breaks. I would eat food at my desk or skip lunch entirely. I would keep working late into the night. I wouldn’t stop until I was done.

Now I use the Pomodoro Technique and it has been a real boon for me. Not in terms of focusing; I can do that. Rather, it helped me to work sustainably. The simple idea of working solidly for 25 minutes and then taking a break works a treat. Having forced breaks at regular intervals keeps me fresh and allows me to keep working and performing at my best. My old style of working continuously without a break would quickly left me feeling tired. My productivity would drop and I would start making mistakes. My enthusiasm would also wane as I soldiered on valiantly, hour after hour. Instead, by breaking down my work into pomodoros (25 minute blocks of focused time), I find I’m actually more focused and more productive.

I use Focus Booster on the Mac to time my pomodoros. It is an Air app that is simple yet effective. Click the button and it starts counting down. It rings when your time is up and then starts your 5 minute break. When I’m at work I keep it on the screen for the benefit of my colleagues so they can see that I’m in a pomodoro. The epitome of its effectiveness was when my boss came over to interrupt me and my pairing partner. He saw the pomodoro, stopped, then said he’d come back in 15 (when the pomodoro had finished). Excellent!

There’s plenty of resources about the Pomodoro Technique. You can really get right into it, however, all you really need to know is this: focus on a single task for 25 minutes without interruptions or getting distracted then take a 5 minute break. You can change the length of a pomodoro if you wish but go with the 25/5 for starters. If you drink water during your pomodoro you’ll end up needing to go to the toilet every half an hour anyway.

Respect the pomodoro!

Resources:

• The Pomodoro Technique Online Book
• The Pomodoro Technique Cheat Sheet
• Pomodoro Technique Illustrated: The Easy Way to Do More in Less Time
• Agile Pomodoro Development (video presentation)

The in-tray method worked like this: whenever someone came to give me new work I’d ask them to leave it in my in-tray. Then I would completely ignore it. I would only deal with it if they came back for it. Most of the time they didn’t. Using this technique I could easily figure out what were the real priorities and simply forget the rest.

This worked because of the environment I found myself in. It was very reactive and the organisation lacked clear direction. We were trying to do too many things all at once and everything was a top priority. There was no one pushing back and saying no.

I happened upon this method by accident. Naturally, I was conscientious and I wanted to do a good job but things were hectic. By the time I finally got to the items in my in-tray I discovered that no one cared anymore. No one had followed up on them, they weren’t beating down my door or hounding me to get them done. These tasks obviously weren’t important so why should I waste my time on them!

Guaranteed, for the times when a task really did matter, people were very quick to follow up with a “have you finished [that task] yet?”. I would then quickly dig it out of my in-tray and get onto it straight away.

This technique worked well for me but I wouldn’t recommend it. Why? Because if you find yourself having to use it, then you are probably in a reactive and stressful workplace, fighting fires or spinning your wheels but never actually doing something concrete and useful. Doing lots of small and unimportant tasks is simply a waste of time. Your work should be organised and valuable. Your daily, weekly and monthly goals should be known in advance. Each day you should be working towards and contributing to the overall business plan and goals.

Of course there’ll always be unplanned tasks but these should be the exception, not the rule, and they should be critical to the business (emergencies like getting the phones working again in a call centre or re-enabling credit card processing in your online store). Everything else that can wait, should. You can be responsive without being reactive.

Now, I’ve talked about in-trays but of course you can substitute email inboxes here instead. It’s the same thing. Are you already practising this technique, perhaps unwittingly? Look in your inbox. Is it full of work requests that you haven’t responded to yet?

Finally, don’t confuse this with the in-tray assessment. It’s a similar thing but my technique was to ignore all incoming tasks unless someone chased them up. The in-tray assessment is apparently a technique used by recruiters to gauge your ability to prioritise, handle interruptions and stressful situations. I say, if the job is like that, then I don’t want it. I believe it is much more efficient to focus on single tasks at a time that contribute to a clear goal. I’d rather do one task well than ten tasks poorly.

I often wonder what the heck people are writing on their notepads in meetings: where to go for lunch, their shopping lists, ideas for a new startup, new nicknames for the boss?

One legitimate reason is to record the action items assigned to you. That sounds fair enough but how many action items can you possible have? You should only have 3 or 4 action items arising from a meeting and you ought to be able to remember that many items in your head. If you end up with more than a few action items then you’ve obviously been lumbered with all the work or the meeting discussed far too many things because it went on too long or they don’t happen often enough. Perhaps your meetings are simply the wrong forum for discussing and deciding on work.

People place too much emphasis on notetaking in meetings. The fact is, most people simply write down the agenda items and then never look at them again. Their notepad is disconnected from their to-do lists, work requests system or project tasks app. Chances are they’ll write down the same action items in the next meeting because they forgot after the first meeting.

A meeting should be for discussion not for managers to dictate work. If it’s a planning session or a “bigger” meeting then it should be minuted, so there’s no need for attendees to bother with scribbling down the same information as everyone else in the meeting. Relax, stop writing and start listening. Try to be engaged and to contribute. Ask questions, even if it might make you look dumb. It probably isn’t a dumb question and other people were probably thinking it too. Make meetings productive for you. If they’re not, don’t go!

So, be bold. Go into your next meeting without a pen and paper. Send the message that you are there to listen and talk, not just to write verbatim.

[Addendum: of course, for some people the act of writing helps them to think and to remember, and a lot depends on the types of meetings you have. But just try leaving your notepad behind and see what difference it makes. I've found it liberating not having a notepad full of "work" which is disconnected from our standard channels for recording and monitoring work tasks.]

[Extra addendum: in reality, I just lost my pen one day and needed to justify turning up to a meeting empty handed!]

NO!

Good. That was easy. Let’s try a real example…

Sorry for the late notice but can you drop everything and implement this new whizz-bang feature by the end of the day?

YES!

What?! That’s not the right answer and you know it, so why do you keep making this mistake? Why do you throw common sense out the window when your boss asks the impossible or the unreasonable, or short circuits your (and their own) processes and procedures? They hired you to be the expert in your field, not the yes man. If they expect you to be the yes man then get another job. How often do you think you can say yes when you really want to say no before you start becoming a disgruntled employee. You’ll end up bitching about your manager, complaining, not caring about the quality of your work, and eventually you’ll leave anyway.

So, be honest and true to yourself. Push back and say no.

Sometimes, executives make unreasonable demands because everyone says yes to them so they end up with unrealistic expectations. Take a look at your typical project milestones – they’re usually badly underestimated. Why? Because when an executive asks “how long will it take to implement that?” before you’ve had a chance to really scope out a project, you end up giving them an answer you think they’ll find acceptable. You end up trying to guess how long they would like the project to take. So instead of saying 12 months you say 6 and you end up hoping that it’ll all work out in the end. It doesn’t. Be realistic. Tell it straight. If they don’t like it, fine. It’s better they hear it upfront than you having to explain why the project has missed its deadline 6 months later. Fail fast!

Let’s try another…

There’s a board meeting tomorrow and they want to see a demo of the software, can you stay back tonight and get that ready for tomorrow? NO!

Be flexible with your work. Help out when you can but draw a line. You can’t and shouldn’t shoulder the burden of other people’s slackness or ineptitude. Unfortunately, if you help out too many times, people may take advantage. Say no and teach them how to fish.

If you are a manager, it is even more important that you learn to say no. This word should be in your vocabulary. It is more important than yes. When you say yes to something you are effectively saying no to something else. Use no more often. Your team relies on you to say no at the right times. If you are a yes man, your team will suffer, whinging goes up and morale goes down. It’ll be fine for a little while as you live off the goodwill of your team but if you keep saying yes, eventually your team will say no, with their mouths or their feet.

As a team, you only have the capacity to do so much. Once you are committed, you have to say no to starting anything new until you have the capacity to take it on. Otherwise, you’ll end up overworking your team and setting unrealistic client expectations.

As a team, you should have your work planned out for the short-term. Say no to anything that attempts to scuttle your plans. It’s too disruptive and often the new pieces of work are knee-jerk reaction tasks that supposedly need to be done asap without proper planning or thought. They undermine your methodologies, your processes and your focus. They often leave you without the opportunity to provide input. They are often a fait accompli, quick and dirty solutions upstairs just wants you to implement straight away irrespective of the obvious problems you can see. Push back, say no!

If you continually end each day failing to achieve the number one task you originally set out to do, then you need to learn to say no. No to others who wanted to interrupt and divert your day. Also say no to yourself. Stop checking email looking for something to distract you from your number 1 job. Saying no is in your best interest and it’s also in the best interest of the business. You need to focus on the most important task, the task that you were hired to do that utilises your skill and talent.

I favour agile methodologies for software development. But being “agile” is not about changing everything at the drop of a hat or a CEO’s whim. Saying yes all the time is simply being reactionary and it leads to chaos, failed projects, dsyfunctional teams, poor work-life balance, poor health, and grey hairs at an early age.

So, push back. Demand the respect that you deserve. Say no!

See also:

• Start with No (37 signals)
• Just Say “No”! (Practical Agility)

I believe software testing is essential. Behaviour Driven Development (BDD) is something that I’m learning and incorporating into my development lifecycle. I use Cucumber and RSpec with my Rails projects to implement new features and to verify their behaviour.

Aside from driving your design, validating your code, and giving you and your stakeholders confidence in your app, testing saves you money. That’s the bottom line. You might not think so. You might be able to get away with zero testing if you are extremely lucky or if you are a super coder who writes perfect software. Ultimately, the time you invest in writing tests for your code will save you time and money.

I recently made a small change to my SciNews web application without writing a test. Why? Because it was just a small change and I was in a rush. I had opened the app in my browser and tried it out and everything was fine and dandy – deploy!

A month went by without any problems. Admin users of the system weren’t experiencing any issues but when a client user tried to use the service – WHAM! BAM! ERROR!! So there I was, just before midnight, on the receiving end of a support call from the client trying to figure out what just went wrong.

I tried to fix it on the spot but I didn’t understand the cause. The only change I made was a minor one about a month ago and admins had been using the system fine during that time. But this was the first client access since then. Aha! But unfortunately, after 15 minutes on the phone with the client, I was unable to solve the problem. As I later discovered, the bug affected client roles, not admins. When I tested it in the browser, I had done so using my admin account. I never tried it as a client.

In the end I had to manually perform the service for the client on their behalf. But the system had failed them and worse, it was their first use of the online service. In order to save face, compensate them for their wasted time and frustration, and to keep them as clients, the service was provided gratis. My small little insignificant change had ended up costing my business $600 and for a small, fledging business, that’s a lot of money that we can’t afford to lose. For $600, I should’ve written a test! Add in time spent on the phone with the client, the embarrassment, and the potential damage to the service’s reputation, I should’ve definitely written a test.

Will this client come back and try our service again? I hope so, otherwise my little error may well end up costing heaps more in lost revenue. This client may have become a repeat customer, so we’re talking a loss of $600/mth. And what about word of mouth? They might have referred two new clients. Now we’re talking some serious lost revenue here all because of one small minor change. Hopefully I’ve done enough with that client for them to give the service a second chance. Whether they do or not, I’ve learnt my lesson – TATFT!

So what’s the answer? How can you rescue a doomed project?

Here’s an example of the things I kept hearing from the project leaders:

“It’s a hard deadline, we can’t miss it.”

“All these features are mandatory and it’s all been signed off.”

“We can’t afford to hire any more people. The budget is already allocated.”

“We haven’t got the time to spare to add that [improvement]. There’s no room for that work in the project schedule.”

Based on what the project managers of these doomed projects felt they couldn’t do, here’s my recommended list of remedies for these project maladies!

1. Extend the deadline. Too many projects seem to have an arbitrary deadline eg end of the calendar year, start of the financial year, before the boss’s performance appraisal. In most cases the deadline is chosen first and the project planned to deliver to that deadline without much consideration for how long such a project requires. Often, because no one pushes back and says no to the boss or client, projects end up trying to deliver too much in too little time. So, when a project starts to look likely to miss its deadline, the easiest thing to do is to change the deadline and I’d always start with this option first. Unfortunately, it may be a genuine hard deadline, there may be flow on dependencies, contract overrun costs, the marketing may already be done, and the business may have already publicly committed itself – pushing back the deadline may be a major embarassment. That may be the case but I bet that a failed project is going to be even more embarrassing and professionally damaging than coming in a month or two late.
2. Reduce the scope. If the project looks like it won’t be able to deliver its commitments before the deadline then simply deliver less by reducing the scope. Focus on the most important features, prioritise and put “nice to have” features on hold. Look at all the outstanding tasks and determine what you can do without. Perhaps the project doesn’t need to have a spiffy graphic design – go with something basic and functional. Perhaps 10 features will allow users to perform 80% of what they need rather than trying to do the original set of 20 features. Perhaps you can get by with less user research, user testing, a more simple architecture, forget about getting 100% redundancy or 100% automation. Analyse the pros and cons of doing and not doing something. Delivering something is more likely better than not delivering anything at all.
3. Increase resources. Hire more staff, more coders, more testers, more business analysts. Often this is a step that an ailing project will try first but it takes time to find, hire and train new staff. No one hits the ground running. Just think about the effort involved in getting someone on board and up to speed with the project as an efficient member of the team. Bringing in a new person at the last minute with the big deadline looming is only going to cause more disruption and lost time than it’s worth. This option only really works if you have identified early on that you won’t make the deadline with your current resources.
4. Improve processes. This one is the hardest of the lot. If you can’t do any of the previous three items, then this is all you are left with. It basically means looking at your existing processes and removing waste and duplication, making your team more efficient so that you end up doing more with less. This takes an investment of time though, time that could be spent working on the project directly or even hiring new staff. You need to analyse your processes, you need to know where improvements can be made. Then you need to actually implement the changes. Again, the return on investment is greater when you focus on process improvement early on in a project. And what do you do when you are already pretty efficient? Go back to step 1!