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.

In a Free Your Mind to Do Great Work session, a participant asked me whether an item on his “to do” list was both a project and a goal. His example: “build our own house”. He wanted to know whether to consider that a project, a goal, or both. I wanted to share the answer with you.

I classify “build our own house” as a project, primarily because it is something to do, and we can quite objectively evaluate whether we’ve completed it. I consider something a project, then, when it is something to do, it has a definite end, and most people could agree by observing me whether I’d done it. By contrast, a goal could be open-ended and difficult to define. I would put “live a happy life” into that category.

You can ask the question “Why?” to find the goal behind a project. Consider a project, such as “build our own house”. Why do you want to do this? (I don’t know, because it’s his example, and not mine, and he’s not here to answer.) The answer to this question might be your goal, and if it doesn’t seem like your goal, then ask “Why?” again. No doubt you know this technique of repeatedly asking “Why?” until you feel something about the answer that makes it different from the preceding answers. I would guess that that different-feeling answer is the underlying goal.

Of course, you can ask a few different kinds of “Why?”

• What’s the good business reason to do this? (One of my favorites.
• Why should I do this specifically today?
• What would be the consequence of not doing this?

What different ways do you ask “Why?” when doing the “n whys” exercise?

I interpret a legacy system as a sign of success. If the system didn’t provide value, then we would have scrapped it by now. We depend heavily on it because it does what we need. Truly useless systems don’t become entrenched in the way that these legacy systems do.

We have legacy code because we need to deliver features sooner than we currently do, and having a backlog of work generally fights unemployment better than not having a backlog of work.

The legacy system design probably can’t get much worse, so you probably can’t hurt it. Feel free to experiment, but remember to retain the current system behavior, because you never know who depends on which parts. (Thanks to Lance Purple for reminding me about this.)

Legacy systems tend to have somewhat randomly-distributed cruft, so it probably doesn’t matter where you start trying to rescue it. You probably can’t find the so-called “best place” to start.

Given all this, what worries you so much about your legacy systems? Really. Practise with us at http://www.legacycoderetreat.com.

Whenever I hear someone make an absolute statement, rather than look for counterexamples or dismiss it out of hand, I will simply substitute a relative one in my head, and look for a way to make the information truly useful.

I must admit to having a serious stickler streak, and I’ve decided to work on that over the past few years. I have chosen to change this about myself because I found that people interpreted my practical desire for precision as insulting pedantry. Recently, I’ve noticed a big uptick in my intolerance of absolute statements, preferring instead to carefully label opinion as opinion. Unfortunately, while I felt I was making “carefully” the operative word in that last sentence, it turns out that most people mostly noticed the intolerance. I plan to do something about this, and I wanted to share that with you, in case you found it useful, too.

Now I can sense what you’re thinking…

Recently, I saw Robert Lustig’s talk Sugar: the Bitter Truth. In it, he claims that fructose poisons the human body just the way ethanol does. He calls fructose “alcohol without the buzz”. Now this matches my experience, because I have lost 60 pounds twice in my life, both times by drastically reducing sugar and starch in my diet. Each time, when I reintroduced sugar into my diet, I gained all the weight back, and with a vengeance. But when I started to tweet about it, people began to tweet opposite points of view at me. (I like that: if you want to test an idea, tweet it.) This made me question what I’d just seen, even though it matched my experience. I didn’t relish the thought of wading through all the nasty commentary on the web, trying to pick out which “facts” I could trust and which opinions I ought to believe. After all, I had just decided only a few weeks ago to reduce sugar in my daily diet, and felt good about the change. Did I really have to completely rethink this?

And then it hit me: we don’t need to demand a single solution here.

I have some reasonable observational evidence that sugar makes me fat. I can’t do a clinical study on myself, so I have to make this evidence work. Now we know that observational evidence only shows linkages, not causation, so I can only conclude that something I do while drastically reducing sugar from my diet helps me lose weight. I don’t know what, although I don’t think exercise explains it, because I don’t exercise much in general, low-sugar diet or not. (Lustig’s statement about conclusions from observation evidence will likely provide the most value to me from his talk.) How can I make use of this information?

I plan to continue to eat in the Four-Hour Body style with very limited sugar intake six days per week and unlimited sugar intake on the seventh day. I will monitor my weight and my feelings about eating using mercuryapp. I doubt that reducing sugar intake will hurt me, so I feel comfortable experiment for another six weeks and looking at the data then. From this informal auto-observational study, I plan to decide whether reducing sugar intake has somehow helped. I then plan to reintroduce whole fruit into my diet for one month to observe its influence. I then plan to reintroduce potatoes and root vegetables into my diet to observe its influence. Finally, I plan to reintroduce bread and rice into my diet to observe its influence. At the end of six months, I ought to have some idea what sugar does to me.

Will I know definitively that fructose is a toxin? No. I don’t need to make the kind of far-reaching absolute claim that Lustig has chosen to make. I only need to know whether I can use the information in his talk to improve my health. I’ll try that, and if that fails, then I’ll go back to the drawing board. Rather than having wasted energy learning the absolute truth—as if it existed—I’ll have turned a contentious absolute statement into information I can use for my own benefit, and all that without leaving frustrated comments on Lustig’s video, his web site, or trying to change his mind. I imagine I’ll see better results that way.

You might, too. Have you tried this yourself? What did you learn? Do you want to try this? Why? Do you think I’ve lost my mind? I’d like to know that, too. Please share your thoughts in the comments section.

(PS: did you see what I did there, with the title of this article?)