Read more about the event at http://agilecoachcampcanada.wordpress.com and register today!

Problems start when we turn any learning method into a ritual. Learning stops, then dogma, arrogance and intolerance begin.

— Stephen Parry (@LeanVoices) May 7, 2013

Very true. I've watch dozens of organisations adopt practices in order to have new rules to follow, but these organisations have tended not to make any lasting change nor realise significant improvements. At the risk of oversimplifying the situation, we all know from direct personal experience that merely following rules leads merely to accurately-projectable mediocrity. We see it in poor customer service and mediocre product quality. "The system won't let me do that" or "That goes against our policy" reflect this follow-the-rules approach. Sadly, many people interpret my emphasis on strict, diligent, fundamental practice as a new set of rules to follow blindly and forever. In the best case, they merely see me as a hypocrite and ignore me, but in the worst case, they follow my advice and it leads them mostly nowhere. I think they simply forget to use the rules most effectively: to learn.

I encourage you to treat all practices this way. Don't adopt a practice until you've treated it as an étude. This means choosing a timebox during which to practise. It means taking time to reflect on what happened when you practised. It means talking to other people about what you've experienced when you practised. It means documenting what you've learned. It means focusing on the technique while keeping an open mind about the results. It means using what you've learned from the practice to inform other aspects of your work. I think you'd do will to treat any practice this way, whether from Scrum, XP, FDD, DSDM, Kanban, or whatever method. Mostly importantly, it means focusing on what you can learn from a practice, rather than expecting it to function as a foolproof set of rules to follow indefinitely and inattentively. While I don't believe for a second that this guarantees continuous growth and improvement, not doing this will absolutely guarantee a ceiling on your results, no matter which well-meaning rules you choose to follow. Even the ones I promote!

So, if you plan to adopt practices as new rules to follow, rather than as techniques from which to learn, then save yourself some energy and just keep following the rules you already have. You probably won't notice the difference.

You deserve the World’s Best Intro to Test-Driven Development, and here it is.

This demonstration video chronicles delivering the first feature of a point of sale terminal using real-life technologies include Heroku and a UPC (price code) barcode reader. Unfortunately, I couldn’t figure out how to connect the application to a portable LCD, so I had to settle on the browser as my display.

In this one-hour-long video I deliver a single feature from end to end using Presenter-First Design with Mock Objects in Java. (No integrated tests here!) If you’d like to download this video, you can do so directly from Vimeo.

J.B. Rainsberger from devtraining.ee on Vimeo.

If you liked this demonstration, then you’ll just love the new project I have in the works. I’ve delivered the World’s Best Intro to TDD as live training to hundreds of programmers across North America and Europe. I’ve had a lot of fun traveling the world, but it really limits the number of people I can help. I’d love to help people whose employers can’t justify training for the whole company. I’d love to help companies that can’t afford to have their key programmers absorbed in training for five straight days. I think I’ve found a way to help.

I’ve started developing an online edition of my world-class training that combines self-paced study and real-time pairing with me. You get all the benefits of live on-site training and you don’t have to leave your home or office. Individuals will love the unparalleled personal attention, while companies can train their employees without having them disappear for a week, and without having to give thousands of dollars to airlines, hotels, restaurants and taxi companies.

While this program remains in development, I need adventurous people willing to experiment. I have already started negotiating with a few companies to be the first to participate in this training, but I’m happy to talk to one or two more particularly eager groups. In exchange for your willingness to experiment, I offer you maximum flexibility and responsiveness, pay-for-what-you-use pricing and priority (even exclusive!) scheduling.

Intrigued? Fantastic! Fill in this form and as soon as I can find a spot for you, I will let you know.

Some of you know about Jerry Weinberg’s “fieldstones” approach to writing. You build a system for easily capturing thoughts of various lengths: a phrase, an idea, a paragraph, whatever. Periodically you review these fieldstones, look for themes, then collect them into a larger piece, fit for publication. This sounds a lot like “Getting Things Written”. It occurs to me that you can use this technique to develop training material. It occurs to me that that’s exactly how I did it, myself.

Let me back up a little.

When people find out that I retired at 34, they ask me how. The conversation steers itself after a while to how I got started working independently. Looking back, building my training skill and experience helped me a lot. People buy training, in part because they want someone to tell them what to do next. You can probably remember a few instances of this yourself, when you needed to figure something out and lamented not having someone to just show you what to do. People also buy training because they understand how to buy training. Some people’s job consists of buying training! This gives you an established way in: your market knows how to buy your services, and they want your services. Now you need at least two ingredients: a training course to sell them, and for them to learn your name and banking information.

You’re a trainer, but you don’t know it!

Isn’t that supposed to rhyme? Anyway.

You probably have some useful information that you convey to others, either by talking face-to-face, through blog posts, or possibly even through a self-published book. If you offered training, then companies will buy it, if they know you and like you. This article focuses on developing the material; we can talk about getting people to like you another time.

Before I delivered my first training course, I had absolutely no idea how to develop course material. None. I had all this information, I regularly answered questions on mailing lists, but I didn’t know how to package it into a class. Then I started working for a technology training company, where I learned not only how to write course material, but how to teach. Or perhaps, I learned how not to do both of those things. If you want to find a job with a training company, then go for it. I didn’t love the experience, but I value what I learned from it. I can think of another path.

Fieldstones.

Don’t feel like you have enough content for a 3-day course? How about 2 hours? Do you think that you have enough information to keep a group of technicians (programmers, testers, business analysts, whoever you want to train) busy for 2 hours and give them the vague feeling that they’ve learned something? Great! You can start there. Do you have a 1-hour presentation in which you describe how to do something specific (as opposed to ranting about varied things)? Great! You can start there, too. Add a 1-hour exercise to a 1-hour presentation and you have a 2-hour training mini-course.

Now ask every user group that could possibly be interested to let you present your mini-course to their audience. The first few times you do this, you will probably suck. Don’t lose hope; but rather, get those experiences out of the way, so that you can start kicking ass, or at least not sucking. You’ll get better with practice. Not only will you improve your teaching technique, but you will adjust your course content based on your audience’s feedback.

Is your audience falling asleep during your presentation, but engaged during the exercise? Less talking, more doing.

Is your audience asking you really tough questions? Great! More fieldstones! These questions become future “modules” in your training course. If you listen to your audience, they’ll tell you what to teach next.

After you teach a handful of these fieldstone mini-courses, you’ll almost certainly have a common theme that you can turn into a 3-day course. Just stitch the fieldstones together, just the way Jerry teaches to stitch fieldstones into articles, or chapters, or books.

From Fieldstones to Cash Money

I developed my World’s Best Introduction to Test-Driven Development training course this way, and now I’m looking into offering it as remote training. (If you or your company is adventurous enough to experiment with remote TDD training, then click here and let’s talk about it. This is still in the early stages, and the early birds tend to get the biggest discounts.) Every training course I offer started out as a handful of 30-minute talks and 2-hour mini-courses. This stuff really works!

After you’ve run your fieldstone courses at user groups and people get to know and trust you, submit them to conferences to run either as workshops during the main conference or as pre-conference tutorials. Many conferences offer tutorials for an extra fee and will split the revenue with you. This gives you some of the best feedback of all: will people pay for this? When you see that people love your mini-courses, then you know which fieldstones to flesh out into full-fledged courses. You can stitch 2 or 3 fieldstone mini-courses together, add a few more exercises, and sell it as 3 days of world class training… and people will buy it. (I mean that in the good way, not in the “sucker born every minute” way.)

So there you have it: the Fieldstones method for developing training material and taking a giant step towards becoming a consulting megastar. It just works.

It’s Your Turn

To start, take 5 minutes right now and write down every idea you have for a training session, big or small. Pick the ones for which you feel the most energy right now. (Thank you, Diana Larsen, for teaching me to follow my energy and not necessarily what I think other people expect me to do.) Now pick one and write down which user groups might be interested in letting you present on that topic. Schedule it. Great! Now you have no choice but to follow through.

Remember that thing about getting people to like you? Don’t worry about that. Your enthusiasm for the topic you’ve just selected will carry you through. Just get yourself in front of an audience and they’ll love you.

If you get stuck, just come back here and ask your questions, or if you’d rather ask me in private, click here and ask away. I’ll see what I can do to help.

Go get ‘em!

In my “craft of software development” course, I’ve noticed two competing philosophies. Several of my students believe that efficiency is the most important aspect of code, where as, I believe that code readability is the most important aspect of code.

I find similar reactions when I work with programmers. I usually respond with one of those annoying consultant phrases: it depends on the context. I wouldn’t do my job as a consultant if I didn’t also provide a more concrete answer, so I’d like to start that here. Your comments will help me refine this answer as time goes on, so please challenge me!

I don’t believe that “the most important” aspect of code can exist. No matter which important aspect of code you choose to label “most important”, we could easily spend 5 minutes imagining a context where some other aspect matters more than that one. For example, I can think of situations in which correctness matters surprisingly little, or speed matters surprisingly little, or maintainability matters surprisingly little. I don’t just mean trivial contexts, either, but ones drawn from the real experiences of real people.

Thus, as consultants often do, my answer consists of an exercise: which aspect of code do you think is most important? Now, let’s imagine a situation in which we’d generally consider a different aspect of code even more important than this “most important” one. Repeat until bored (or convinced, or both).

Michael Feathers has suggested that “readability is the best default [most-important aspect] for nearly all code”. This seems quite reasonable, but Michael included the word “nearly” for a reason. True: in the context where people time costs more than machine time, then readability matters much more. I worry that we’ve lived in that context for so long, that we forget that we’ve made a tradeoff. Jerry Weinberg tells stories about IBM renting him free of charge to clients who buy a computer. In that context, where machine time costs so much more than people time, then shaving milliseconds probably matters more.

Don’t get me wrong: absent other information, I tend towards optimising for a balance between low cost to understand and low cost to change. (These two relate, but I can understand code that I nevertheless feel afraid to change because of high coupling to some difficult-to-understand system). If I don’t know my audience well, then I tend to tip the balance—not much, but a little—in favor of low cost to change, so that they can more readily make the code easier for them to understand.

As usual in these cases, knowing the forces matters more than choosing a sensible context-free default option.

Front

Back

Do you need help with user stories, but can’t afford thousands of dollars to hire a consultant for an on-site visit? You need My Agile Tutor. You’d be amazed what you can accomplish in only 90 minutes with me. Visit http://www.myagiletutor.com to get started today!

Post Script

I remember the phrase “token for a conversation”, but Ron wants to edit it, possibly retroactively.

I’m in. “Ticket for a conversation” sounds good, too.

The tools of ignorance

I have recently started “taking seriously” making coffee. By that, I mean that I have spent a considerable amount of money, time, and effort, learning to brew espresso at home. Rather than bore you with the history, suffice it to say that this has become my latest expensive hobby. I wanted a challenge outside the realm of building software, and I’ve found it.

My current setup includes a Baratza Virtuoso grinder, beans both from Kicking Horse and from Speakeasy Coffee, and the centerpiece, a Rancilio Silvia Pro V3 espresso machine. This machine has the reputation of being a teacher, and I can see why. I have at best a love/hate relationship with Silvia to this point.

Over the winter holidays 2011-2012, Sarah and I stayed with her parents, and so I bought Silvia and shipped it there with the goal of brewing better espresso during our month of down time. I knew I wanted to step up from the department-store brand espresso machine I’d used for a few years, and Silvia seemed a popular and strong choice. I unboxed the machine, pulled a few shots—that’s the lingo, you see—and did not care for the results. The espresso tasted considerably inferior to what I’d managed to brew using my $200 machine. This simply couldn’t happen, and so I did the simplest thing: I read a few dozen articles on the web about taming Silvia.

Talk about complicated! So many variables… beans, grind, tamp, humidity, water temperature, water quality… I didn’t know where to start, so I did the only thing I could: I muddled through until mid-January, boxed Silvia up, went back on tour, and waited until I couuld unite Silvia with the Virtuoso grinder at home. I couldn’t run a real test, after all, until I used the machine in a proper environment, with a high-quality grinder, high-quality beans, and even time and patience to experiment.

Fast forward to the last few days. I have set up my beautiful grinder along side the temperamental Silvia. I feed this system the best water I have, the best beans I have, and I start pulling shots. Dreck. Bitter. I’m pulling shots anywhere from 10 to 18 seconds. Water is channeling through the coffee at breakneck speed, spurting bitter fluid everywhere. Each shot creates a unique, almost artistic mess to clean up. I literally can’t swallow the results. With Sarah waiting for her morning cappuccino, I resign myself to take the best two out of 6-8 mediocre shots, and hope that cinnamon and microfoam milk mask the flavor enough. I don’t feel good about the coffee I make, but Sarah goes along with it kindly enough.

I’m not enjoying this. After reading a few dozen more articles, like this one, I see that in order to get the results I expected, I need to learn a lot more about making coffee than I already had done, and I thought I’d learned a lot already! I’d read The Joy of Coffee over ten years ago. I seemed to know more than most people around me about making good coffee. I owned an Aeropress! Surely, I knew what I was doing. Apparently not. It seems that, no matter how much I think I know about brewing beautiful espresso, there remains entire worlds I haven’t explored yet. I wanted to enjoy this, but it had become a battle, and I don’t know whether I want to learn all this arcane technical stuff just to make good espresso. The results from my $200 machine seemed like an acceptable compromise by this point.

I know—so far, this has nothing to do with software development.

Gil Broza decided to have a little fun at my expense.

This entire experience reminded me of the battles we face working in legacy code. We don’t know precisely what the system does, though we have a rough working knowledge of how it works and what it’s supposed to do. We only have one form of reliable feedback: the end result. We might have the chance to check a few intermediate steps in the process—I can roughly check the temperature of the water, the color and shape of the flowing coffee, the time to pour 2.5 ounces of espresso, and how much splatters out from my naked portafilter—but that feedback is inexact, like how wet or dry the puck of grounds feels after pulling the shot, or how much crema I find on top of the espresso. These forms of feedback tell me when I’ve got it all wrong, but don’t help me know when I’ve got it right. I can pull a 23-second shot of 2.5 ounces with a nice dark color and a healthy crema on top, then taste unrepentant bitterness in the shot. Unusable—but everything looked right! What the hell am I doing wrong?!

I really have only two choices: give up, or learn more. In my case, giving up means walking down to Samuel’s coffee house and paying $3-4 per cappuccino. This usually gives me the quality results I want, but at a premium, and comes with one considerable downside: I have to put on pants and go outside. When working with legacy code, giving up means neither replacing nor rescuing the legacy code, but simply living with it, learning to adjust my expectations to its quirky behavior, figuring out how to get it mostly out of my way, but with one considerable downside: when push comes to shove, I can’t change it, so I have to waste time and effort working around it, rather than making it better. Legacy code has a way of creating a vortex of mediocrity around it, sucking in otherwise good code and diligent programmers. We bear both visible and invisible costs, and they seem unbounded. It never ends, and we can do nothing to stop it.

A little dramatic, perhaps, but I think you’d agree, not entirely unrealistic.

For my part, I won’t give up the search for a great espresso. I won’t let Silvia beat me. I will do the research, put in the practice, and figure out how to get consistent, delicious results. I have done it before, and I will do it again. I will have to read a lot of articles, try a bunch of strange-sounding techniques, run through a lot of beans that deserve better treatment than I’m likely to give them, and drink an unfortunate number of mediocre cappuccinos before I get there, but I shall get there. It will happen, because I believe I can learn to do it, I believe I will to learn to do it, and dammit, I want great cappuccino at home.

Individuals can rarely justify spending the money it costs to bring a coach to them, so they either work with their coach remotely or, in some cases, combine work with vacation and travel to their coach. People have approached me for coaching for two broad reasons: either they want quick help related to something very specific, or they want a mentor to help guide them through some difficult or uncertain decisions. I have found that I can deal with even sensitive interpersonal issues effectively over the phone or Skype.

Most often, the client schedules remote working sessions with me, which we conduct over the internet using basic tools like Skype, chat, email, screen sharing or virtual whiteboards. I have helped people prepare clients for job interviews, reviewed clients’ code, programmed with clients in real time, mapped products and stories with clients, and advised clients working themselves as team leaders on performing that role more effectively. This situation works best when the client and I establish trust very quickly, either by having met before, or by completing a single working session before discussing a longer-term arrangement. On rare occasions, technology has got in the way of the work, but the interruptions have been minor and overcome by using backup, technology like the phone. In a typical one-on-one engagement working remotely like this, we tend to keep the schedule quite flexible, and so the occasional rescheduled appointment causes relatively little trouble.

When teams and companies look for coaching, they rarely consider alternative coaching models, and I think they overpay enormously for convenience, possibly even for less effectiveness. (Refer back to Naresh’s article.) I can think of a few reasons for this.

• The client and coach do not know each other well enough to establish a level of trust that makes part-time or remote coaching work well.
• The client’s company has no experience with these alternative coaching models, and simply doesn’t trust them.
• Someone in the approval chain has had a bad experience with a consultant (who hasn’t?) and wants to keep the coach close by, in order to monitor the work.
• Someone in the approval chain equates face time with value.
• In some cases, such an alternative coaching engagement doesn’t fit into the detailed system of departmental budgets and project codes that has evolved over time to track the cost of working with consultants.
• Obtaining the budget for a large block of work with a consultant requires less effort and involves less bureaucracy than a more incremental approach.

Before I continue, let me be clear: I don’t ridicule these constraints. I feel bad about them, but I understand how these policies evolve, and I don’t want to make things worse by complaining to the client before they agree to the first engagement! I’d rather focus on our shared interests in part-time coaching:

• Your team will have to stand on its own feet long before I leave “for good”. We can avoid the ongoing anxiety of what happens after he leaves?
• Your team will have a chance to digest and use the first batch of suggestions before I try to give them more.
• You can commit less money to working with me to start, and I can commit less time to working with you to start. If the relationship breaks down, and sometimes it just doesn’t work, then it’s much less likely for us to succumb to the impulse to involve lawyers.

When working with a team full-time, I feel happy when my clients use 20% of what I teach them, given the sheer number of things I can share with them. When working with a team part-time over a longer period, my clients have had time to test and refine my suggestions. They don’t try to do too much at once, reducing frustration and giving the chances a much better chance of sticking. This gives me a chance to learn more about them and give them more effective advice. This becomes a virtuous cycle that generates much more value for the cost.

So, do I still value full-time coaching? Yes. I think that teams need leaders of the type that Gil Broza describes in his upcoming book, The Human Side of Agile. I think that companies need help cultivating those leaders, and that at a result, full-time coaching needs to include an explicit mandate to coach would-be leaders. When I coach a team for a few months, I expect to show them some tricks, give them feedback about their behavior, point them towards useful resources (like books, articles, training), and inspire at least one person to act in the role of servant leader. Most clients do not talk to me about this last point, and I see it as a mistake every time.

When I agree to coach a team for any significant length of time, I expect to work with the client to develop a strategy to deal with this issue. Not doing so wastes money, time, and effort, and given what we coaches typically charge, I want my clients to get the most out of their time with me. Just because I show your people 50 tricks doesn’t mean that they can use 50 tricks after I leave. We have to do much more than that to make any coaching engagement a success.

This might leave you with one last question: when should I hire a full-time coach? I think that, if you need someone to do the work of an agile team leader because you have a gaping void in that area, then you could consider hiring a full-time coach for 3-6 months. If you hired me for that, I’d start by leading the team, while learning as much as I can about the team and how it fits within the company. If you had someone in mind to take over as coach after I leave, then I’d teach that person what I know and share what I’ve learned. If you needed me to help you find that person, I’d do that, too. I’d split the engagement roughly into thirds: first leading the team, then pair-leading the team, then coaching your employee-coach as she leads the team. By the end of the scheduled time, your employee-coach would feel comfortable to lead the team, but might still need some part-time help, and I’m happy to do that. Even if I leave this person with 10 books to read, she’ll still need someone to lean on for advice, and remote working sessions fit that need perfectly.

This style of engagement contrasts sharply with stories that friends, colleagues, and clients have told me. They have shared stories of consultants who come in, lead the team, become the bottleneck, create (intentionally or not) a situation where the client depends on the coach for too much, then disappear abruptly when boredom sets in. It happens too often; don’t let it happen to you. A long-term, part-time relationship with a strong coach delivers tremendous value long after a full-time coach has left the building.

UPDATE: I just ran across George Dinwiddie’s short article (click here), which I offer here as a companion piece.

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.