I help people deal with fear when I coach people, teams, and organisations. All coaches do this. In particular, I encounter decision-makers afraid to take some of my advice, for a variety of reasons:

• There’s a lot to do, and we don’t have time. (Have you read chapter 6 of Planning Extreme Programming?)
• What you suggest sounds difficult, and I don’t think we can do it well.
• What you suggest changes everything, and I don’t know where I will stand afterwards.

I often deal with this problem with a relatively simple working session that often takes less than an hour. If you like it, then please try this at work.

I recently described this to a friend and colleague who reported trouble with a client resisting his advice regarding emergent architecture. I had suggested that he throw some keywords into Google and start reading, when he replied that he tried that, spent considerable time, found conflicting information, and didn’t know which authors to trust. He needed something that would open his client’s eyes to what’s possible. I wrote him this:

That’s the problem your interlocutor probably has: “I am unsure whom to trust.” Data will not help. In that position, your interlocutor will probably trust the people who agree with the position he already has in his head and not trust the people who don’t agree with the position he already has in his head.

As to opening his eyes to what’s possible, I doubt anything will impress him, although I’d enjoy his proving me wrong on that. I anticipate a lot of “Yes, but…” followed by a lengthy explanation of why that won’t work in his context.

I suggested saying something like this to his client:

I understand that the idea of letting architecture emerge sounds scary. I happen to think it’s just as scary to try to get it right years in advance. I can make some guesses about what scares you about this, but I’d rather you tell me. What’s one thing that scares you about trying intentional, guided emergent design…?

I play a little game with the client’s answers. I write each fear down on a card, then after he has finished telling me what worries him, I pick a card at random and ask the client: “What can I do to alleviate this fear?” I suggest things. I try to talk about concrete issues. I pull out information about his context. I learn about him, his situation, and his fear. I write my suggestions down on cards: “Try TDD”, “Get some C++ training”, “Run a Product Sashimi session with five key customers”, “Reorganise department X into feature teams”, “Run Open Space days once per month”. After an hour or so, we have a list of ideas on cards. Each of these ideas addresses one of his stated fears, concerns, anxieties. When there’s nothing more to explore, I look at the cards and group them like this:

Finally, I ask the big question. Even if you never end up doing intentional, guided emergent design, which of these cards look like things you’d like to do or think need doing?

Do those.

Further Reading:

• Dale Emery’s model of motivation, which I use frequently. Dale makes me look like a genius with this one.
• Planning Extreme Programming, which remains a classic.

*The title is a joke that comes from my days at IBM. My then manager, Tack Tong, told me that in order to have my patent applications taken seriously, I needed the title to be something like “System and Method to…” and use the term “apparatus” a lot. I miss Tack.

Click the image to enlarge it.

Maybe you’ve heard of Getting Things Done, David Allen’s system for managing and tracking work. Maybe you’re like some of my clients, who’ve bought the book (or Kindle Edition) but not yet got around to reading it. Maybe this will help.

I have distilled the core of Getting Things Done down to a four-page document that you can read and put into action today, tomorrow at the latest. Click here for the tutorial that takes only 5 minutes to read.

Don’t want to take 5 minutes right now? I understand; you’re slammed. Here’s something you can do right now: institute the Two-Minute Rule for incoming work. If you do this, then you’ll never again wonder where the day went after trying to start ahead of the curve on incoming work. Here’s how it works:

Every time someone asks you to do something, or you think of something to do, ask yourself, Can I do this in two minutes? If you answer “Yes”, then do it now; and if you answer “No”, then do not do it yet!

That’s it. If you don’t want to take 5 minutes to read this document to start taking control of your work, then start using the Two-Minute Rule now. What do you have to lose?

I’ve watched companies for the better part of a decade try to introduce agile practices into their work, with relatively little success. Most commonly, they see limited localised improvements, create much more chaos than that, and some of their best people quit out of frustration. I have seen one thing in common with these organisations: they treat “going agile” as a goal unto itself, rather than as a way to solve significant, pressing problems. They do things like measuring how “mature” their agile transition is, based on which percentage of teams are writing automated tests, which percentage of teams have daily stand-up meetings, which percentage of teams have a certified Scrum master. In short, they encourage people to “do agile things”, rather than solve real problems.

So give yourself the gift of sanity this Christmas, and refuse to play this game. For all the talk of agile being dead, passé, ruined, whatever, I don’t believe it. Don’t let the people writing those articles distract you from a more significant problem by telling you that “agile is over” and that you need to try the “next new thing”. Nonsense. It would suffice for you to refuse to treat the agile practices as a set of rules to follow. Instead, treat the agile practices as tools in a toolbox to use to solve real problems. Perhaps then you can do some meaningful, effective work.

Don’t treat agile practices like levels of a video game to conquer. No-one cares that you do TDD if you don’t use that practice to reduce the marginal cost of features by keeping designs simple. No-one cares whether you had a stand-up meeting this morning if you don’t use it as an opportunity to better understand where your bottlenecks lie. No-one cares that you demonstrate software to internal customer proxies if you don’t use the resulting feedback to deliver a smaller, more value-rich product sooner.

Instead, go to the people who insist that you “go agile” and ask them questions like these.

1. Which problems do you expect agile practices to solve?
2. What results do you hope to see from these agile practices?
3. Why these agile practices now?
4. How will you know that we’re making progress?

You won’t necessarily enjoy the resulting conversations, but if you take them seriously, then they will stop you from wasting a colossal amount of energy pretending to improve.

You need me to be more responsive, but when I’m deep in a long-running task juggling a lot of little things in my head, it’s hard for me to surface for air, evaluate whether I need to respond to your request right now, then drop what I’m doing to help you. That’s why I’ve started training myself to take more frequent breaks. It encourages me to get stuff out of my head from time to time. As I practise this and improve at it, I’ll be able to get everything out of my head in less than a minute when you really need me. I’ll be able to focus on what you need to me do while I’m doing that without worrying that I’ve lost crucial information to get back to what I’m doing now. So if you bear with me while I’m practising taking breaks, then I’ll be more responsive to you when you need me, I’ll focus better on the work you need me to do at that time, and I won’t need long to get back into the work I was doing when you interrupted me. We all win.

Before you read this, keep in mind that I’ve spent about 12 years practising, teaching, advocating for and defending the ideas of agile software development and, in some cases, the people who espouse them. I hope my track record speaks for itself. Nevertheless, I think we still have a long way to go, and so I offer these as points of discussion and disagreement.

For all the good things that the agile software development movement has done for me, for my colleagues, for my clients, and for the industry at large, over the last ten years, I believe that it has failed to…

• Capture the attention of executives
• Move people beyond roles and rules
• Focus people on value
• Ingrain simplicity as a core value
• Communicate the vital need for discipline
• Obtain buy in from executives and management
• Keep the manifesto in the front of the common consciousness

I also believe that it has, perhaps unwittingly, triggered…

• obsession with ultra-precise cost estimates for small batches of work
• a cottage industry around certification
• a cottage industry around tools
• a culture war between Agile/Lean/XP/Kanban
• obsession with compliance over results
• excusing chaos
• a false expectation that order emerges spontaneously
• “Trophy Agile” and “Badge Collectors”
• insular behavior for teams (“We’re agile; leave us alone”)
• accusations of elitism within the community of practice

Now, let me be clear: the agile software development movement has helped me tremendously. I might not have retired just before my 35th birthday without knowing what the agile software development movement’s leaders taught me. Please don’t label this “bleak” or “dire” or “hopeless”; please simply bear these things in mind as you practise and teach others.

Get stuff out of your head

I didn’t think it mattered that much. When I first read Getting Things Done (kindle), I didn’t really grasp the power of closing open loops and how free that left me to not only focus on my current task, but also forget things – temporarily, of course – that would otherwise worry me night and day. (I’m the type to worry, so generic advice to “let things go” never really worked for me.) When I started getting things out of my head onto paper, into spreadsheets, wherever… I felt much more relaxed, sped through tasks at full focus, and that generally made everything feel better.

You don’t need to do much to start feeling the benefit of getting things out of your head. Try this.

During your next task, put some paper and a pen next to you. While working on your current task, whenever something pops into your head not directly related to the task at hand, write that down quickly, then get back to your task.

This will feel strange at first.

Stay with it. Keep doing it for the entire time that you want to focus on your task. When you finish your task, place the paper in your inbox. If you don’t have a physical inbox in your work area, it takes 10 seconds to create one: find a tray, a box, a file folder, anything that stores paper, then label it “INBOX”.

If you noticed that you need to do something on this newly-created list today, then scratch it off your list and do it today – now, perhaps. Otherwise, let the page sit in your inbox until tomorrow. Forget it the best you can. (You won’t do a good job of this yet. Go easy on yourself; you’re learning.) Practise this for two weeks. Use a tracking tool like http://mercuryapp.com to track how stressed you feel about the stuff you’ve put in your inbox.

Each day, before you do any other work, spend 2 minutes looking through your inbox for anything that you need to do today, then scratch it off the page and do it today – now, perhaps.

Specific advice for programmers

Kent Beck taught me about “test lists” and I use them every time I program. Before I write my first test I make a list of the tests I think I’ll need. Once I get those out of my head, I choose a test and start programming. As I work, if I think of a way to refactor the code, I write that down on my test list, then get back to the task at hand. If I think of more tests to write, I wrote them down on my test list, then get back to the task at hand. This helps me focus and avoids a lot of stress.

Specific advice for pair programmers

When you’re not typing, you get to think about where the design appears to want to go. You have ideas about what to do next. You must, however, let your partner – the one typing – focus on the current line of code. When an idea pops into you head, write it down. You can do this without disturbing your pair partner, and you won’t forget anything. Let your pair partner focus!

Unexpected benefit

When I try to write down an idea that has leapt to my head, if I have trouble writing it down succinctly, then I probably don’t understand it very well, in which case I can safely forget it. This lets my subconscious mind work on it, and when it comes back to my conscious mind, it usually comes back in a form I find much easier to write down succinctly. I find that helps me avoid trying to do ill-define things with no real goals.

Another unexpected benefit

I love crossing things of my list, whether because I have completed them, or because I’ve decided not to do them. Both acts helps me feel freer; perhaps they’ll do the same for you.

Time and again I see clients struggling to complete work because they struggle to find enough contiguous time to complete a meaningful piece of work. I empathise, since I experienced this for the first time when I began to establish myself as a technical leader at IBM. As more people sought my advice, my time became more fragmented, and within months I found it difficult to focus on any task. Interruptions became the norm, rather than the exception, and I never felt comfortable about that. How I wish I’d known more about bottleneck theory then!

If you find yourself in this situation, then you likely already know that in order to get more work done, you need to reach levels of focus that you no longer find easy to reach. You used to achieve high focus by taking several hours to work on a single task, but when you look at your calendar, you don’t see more than a 30-minute window available any time in the next two weeks. You simply don’t feel like you can get anything done in that time. (As Paul Reiser once noted, everything in the world takes four hours. Minimum.) You need four hours; you have 15 minutes; what to do?

Some people, even me, suggest splitting your tasks into smaller pieces, but that takes time and effort to learn and to apply, and completing smaller tasks probably wouldn’t satisfy you right now. You need another technique that you can try right now.

Of course I have one, otherwise I wouldn’t write this article. First, I digress.

In the early years of XP, among all the ideas that interested me, one spoke to me even more loudly than the others: stop thinking, “I don’t have enough time”, and instead start thinking, “I have too much to do”. Transpose the problem, as you would a matrix, and consider what new possibilities it gives you. It worked for me. I propose using this transposing technique to deal with the problem of “I can’t get anything done in 30 minutes”. Instead of “my tasks are too big”, think “I need to work better in short bursts”. Transpose the problem and work with what you have. You have maybe four 15-minute slots available; how can you get more work done in that period of time? You probably need to overcome the inertia that comes from believing that you can’t get anything truly useful done in 15 minutes.

Try this

At the beginning of the day tomorrow, decide which task you want to work on during your tiny slivers of time. Spend 5 minutes, which you can squeeze out of anywhere if you have to, writing down any information relevant to completing that task. Just jot down notes: facts you’ve been carrying around in your memory, references you need, people you have to talk to, that kind of thing. Put it all on a sheet of paper or a stack of index cards.

Now forget it and start dealing with the craziness of your day. When you have your next 15-minute time slice, set a timer for 12 minutes, start it, grab your sheet of paper, and start working. Don’t worry if you can’t think of a concrete intermediate goal that you can achieve in the next 12 minutes; just work.

Now for the really hard part. (I’m not kidding about that.) When the alarm goes off, stop. Breathe. Grab your sheet of paper. Write down everything you’ve juggled in your head while you worked. Keep writing until nothing else comes out. I hope that only took 3 minutes, because your next meeting has already started.

Now forget about that stuff and continue dealing with the craziness of your day.

Repeat.

This technique helps you develop the ability to accomplish tasks in short slices of time. It has at least two beneficial side effects: you become more comfortable working in short bursts, and your subconscious starts looking for more concrete, achievable, intermediate goals that you can actually achieve in 12 minutes. You don’t have to work at it consciously just yet; practising this technique will suffice.

I hope you’ve noticed the key part of the technique: spend the last 20% of your time slice (3 minutes out of 15; 6 minutes out of 30) getting information out of your working memory so that you don’t waste energy worrying about that stuff the rest of the day. I can’t stress this enough: developing the discipline to get information out of your working memory matters much more than the amount of work you achieve during the first 80% of the time slice. You need time to adapt to this way of working, so focus on the parts that differ from what you’d normally do.

If you practise this for two weeks, then I believe you’ll notice a difference. It works for me. Ask questions or offer your own suggestions in the comments.

Read the full article here.

In a previous article I defined “project” and “goal” in ways that make it easier for me to use a Getting Things Done system. I used an example, “build our own house”, that one of my course attendees asked about. Another attendee asked about an example he found a little more confusing: “learn Clojure“. This sounds like a project and a goal, so what should I consider “the goal” and what should I record in my Getting Things Done system?

I recommend applying the tests I described in the other article. How would I know that I had finished learning Clojure? Can I “finish” learning Clojure? I don’t think I can, so right away I wouldn’t consider “learn Clojure” as a project. I need to record something with a definite end and to which I could apply a clear test to determine whether I’d finished it. (Conditions of satisfaction or acceptance criteria, if you prefer.) I do eventually want to learn Clojure, and so I’d likely record a project like “Learn enough Clojure to demonstrate my Point of Sale example comfortably.” I refer here to the standard example I use in my programming training courses. While the phrase “comfortably” doesn’t exactly give rise to air-tight objective acceptance criteria, I think the average audience paying money to learn Clojure from me could agree whether I demonstrated Point of Sale in Clojure comfortably, although I could strive for more lax standards by targeting conference session attendees. Perhaps I should record the project as “Learn enough Clojure to demonstrate my Point of Sale example adequately for an XP2012 tutorial”. That makes it more concrete, defines an end, and session feedback will tell me whether I succeeded. So if I don’t classify “learn Clojure” as a project, then do I classify it as a goal?

One might learn Clojure for its own sake, in which case that person would consider learning Clojure a goal unto itself. If learning Clojure does not represent pure art for you, then ask “Why?” in some of the many ways that I described last time until you find your goal. I might choose the goal “Avoid becoming technically obsolete by learning Clojure”, or perhaps, “Develop my programming skills by learning Clojure”, or perhaps, “Understand better why everyone seems so obsessed by functional programming by learning Clojure”. As you can tell, goals vary wildly by person, by situation, and change over time. If I happen to win the lottery this weekend—you never know—then “Avoid becoming technically obsolete” suddenly becomes less urgent a goal.

So if you find yourself with a “to do” item that sounds vaguely like a goal and like a project, then try this:

1. Ask yourself, “How would I know I’d achieved this goal?” Your answer will help you better define the item as a project.
2. Ask yourself, “Why should I do this?” You answer will help you better define the goal behind the project.
3. Don’t be surprised if the original item disappears entirely, replaced by a better-defined project and a clearer goal.

Isn’t this all just semantics, J. B.? Not to me. When I help my clients establish clear goals, many of their problems just start to disappear. When I help my clients gain better control over their projects, similarly many of their problems just start to disappear. I think that the clearer they understand their goals and define their projects, the more easily they can handle their work. Perhaps it will work for you.

Do you have any “to do” items that you have trouble writing down as projects or understanding as goals? I’ll help as much as I can.