A few weeks ago, I returned to work. A friend and fellow technical coach graciously invited me to his client to pair-coach for a week and solo for another. Since Bekki and Taavi were able to travel with me on this occasion, it was easy to accept.

Taavi's first Residence Inn (since being born)

I would strongly recommend that anyone, given the option, return to work in this particular way. I feel very lucky to have been given the option. My friend designed the guest-coaching environment at his client for my time to be meaningful to them — and, therefore, to me. It was an honor to be there. And it’s more wonderful than ever to be home again.

Meaningful for others

Clients typically invite me in because they want technical coaching.

I’m happy to accept. I enjoy programming with programmers, testing with testers, and managing with managers. I join in the work, observe where we’re going, and offer techniques and habits intended to help us get there. Along the way, we talk.

My recent two-week engagement has clarified for me once again that my impact typically stems from (most to least):

  1. One-on-one conversations
  2. Group conversations
  3. Anything involving computers

There’s a big gap between (3) and (2). Whereas techniques and habits are hard to change and slow to pay off, conversations can quickly strengthen human connections, bring instant insight, and improve conditions for further improvements.

Given I’m just visiting
When I’ve done my job
Then the folks involved feel more effective doing theirs

Clients are typically happy to have had me as a technical coach. It gets me close enough to have meaningful conversations.

Meaningful for me

Taavi falling asleep in the car

My son is eight months old. It’s been very special having so much time with him. I’m motivated to keep it this way.

I’m 39 today, and feeling reflective.

Today, I’m pleased to announce that I’ve gone independent.

Meaningful for you

You can engage me directly for consulting, coaching, or training in the New York metro area (and very occasionally elsewhere). We’ll design an environment for our time together to be impactful and valuable.

To learn more about what I can do for you, take a quick look at my one-page résumé and my coaching bio. Or a quick listen to my three-minute podcast.

Or just get in touch and let’s talk:

Posted February 9, 2018 at 06:47:48 AM EST Tags:
Photo by Steve Moubray
I peek at one group's BDD scenarios

At the Agile Coaching DC meetup tonight, about 50 people participated in my “Behavior-Driven Development for Everyone” exercise. The abstract:

Problems are better solved when you’re better involved. That’s how you make your living, and that’s what BDD is all about. We’ll work together to solve a problem in a way we can all understand and trust, expressing what we want in plain English and automating our tests with a tool called Cucumber. Don’t worry, you won’t be put on the spot at the keyboard — I’ll handle all the coding!

What we did

My goal was to illustrate two things:

  1. Cucumber the tool: side-by-side-by-side, how the three ingredients — the human-readable Gherkin spec, the programmer-readable step definitions that animate the spec, and the code being developed to meet the spec — are connected, or might fail to be, and how they must evolve together.
  2. BDD the practice: side-by-side-by-side, how the Three Amigos — Product Owners, Testers, and Developers — are connected, or might fail to be, and how they can collaborate via shared language (and optionally a tool like Cucumber).

To that end, after reviewing a few slides, I live-coded the first few bits of Gherkin, step definitions, and application code, using Cucumber in Perl. Then we split into a few groups to slice and sequence the remaining scenarios that add up to a properly scored game of bowling, and got back together at the end to compare results. Our findings are in the slides.

Here’s video of the first half:

And here are organizer Steve Moubray’s photos of the second half.

Read more

In addition to the references in the slides, here’s a story of my own about seeking greater effectiveness through BDD, from my series about the human value of TDD.

Learn more

What would BDD look like in your context? Need help getting started? Get in touch! I’d love to work with you (especially in the New York metro area or remotely) or refer you to an expert hands-on instructor near you.

Posted January 18, 2018 at 06:30:00 PM EST Tags:

Etymologically, “fluency” is about flow. Practically, it’s about language: from one angle, it’s how well you understand and speak under stress or pressure. My teammates playing the Agile Fluency Game in Hamburg a couple weeks ago had no discernible difficulty speaking English, but it must have been effortful for them, because when we felt the clock ticking, they returned to German. Communicating more efficiently within the team — including me, since I could mostly understand them — bought us time and brainpower to improve our outcome considerably.

The Agile Fluency Game is intended to help understand and speak about the Agile Fluency Model. As Diana Larsen explained it, the model suggests thinking of Agile as something like zones in a municipal transit system. From the city center, it costs more to get to the outer zones, but not because they’re objectively superior places. They’re just further away from where we are. If it’s worth it to pay the fare and take the time, we can get there.

Since the model offers four zones with benefits and relative costs, I might also liken it to the number of courses in a meal: Agile-striving organizations can order just enough to sate their investment appetite.

So what?

For me, the usefulness of the Agile Fluency Model centers on offering an alternative to some false dichotomies:

  • doing Agile vs. being Agile
  • being Agile vs. not

Perhaps these dichotomies are rhetorically useful. I certainly find them useful as motivation to reframe. As a student of behavior, I don’t see a clear separation between doing and being; as a student of Agile, I don’t see a clear reason (or basis) to judge ourselves in or out. If the Agile Fluency Model helps us refocus on making adaptive choices in and about our own environments, then it’s a useful frame.

In this sense, it’s also an Agile Congruency Model. If we can more precisely identify our organizational and individual needs, we can more explicitly meet them, and expend much less effort bridging or apologizing for a significant gap between our espoused values and our values-in-action. Maybe the two sets of values can be congruent.

Playing the game

We played twice.

The first time through, we spent a big percentage of our time and brainpower getting oriented in the game — some up front and some as we went along — kind of like when we were brand new to Agile. There were cards about features (of which we must deliver at least one per quarter, to make money) and about practices (which might be, I dunno, really helpful for delivering features). My intuition said that if the design of this game was based on real-world experience anything like mine, we should be willing to defer most other goals in exchange for practicing Test-Driven Development and Refactoring as early as possible. My teammates had other ideas, so my intuition was tested. Indeed, it got harder and harder to deliver a feature in time, until finally we couldn’t, and lost.

TDD and refactoring conspire to remove costs and risks that otherwise remain hidden. It’s precisely when the current state is hard to see that the proposed benefit is hard to imagine. Words often fail. Distilled from the experience and wisdom of James Shore and Arlo Belshee, the Agile Fluency Game offers a way for people who haven’t yet tried these disciplined development practices to get a meaningful, cause-and-effect feeling for their costs and benefits.

The second time through, we graphed the practices and their dependencies, avoided delivering more than one feature per quarter, and spent the rest of our resources acquiring practices prioritized by in-game benefits (such as reduced carrying cost of existing code). This turned out to be a very good strategy. We got into flow, played more than our individual roles, helped each other hold attention to our strategy, racked up increments of success and momentum, rolled up our sleeves because we were getting warm, and won an outcome beyond what we assumed possible. Afterward, Anja said “Can we do a real project together?”


After sharing that feeling, I was disappointed at not being able to take away a copy of the Agile Fluency Game. It’s understandable: since the game’s design is intentionally complicated, learning from the game in a reasonable timeframe benefits from — indeed, might require — intentional facilitation. Even so, it was disappointing. Even so so, I may consider enrolling in the training required to get it, because I’d love to have the option to share the game with my clients.

Why is having this option important to me? Because what I did take away is a reinforced belief that we humans are far more apt to learn new behaviors from experiences than from words. (Don’t get me wrong. I love words. And they’re a great way to become aware of behaviors we might like to try.) As a coach, I can tell when I’m at my best: it’s when I’m doing less explaining and more creating shared experiences. So I’m glad to have played the Agile Fluency Game, and I hope many more people get to play it.

Posted December 29, 2017 at 06:59:19 AM EST Tags:

Taavi had such an easy time on the plane to and from Germany, and such a swell time with loved ones there, that we’ve booked his next flight to loved ones in Chicago. Meanwhile, we’re enjoying our frequent quality time with loved ones 10 minutes from home.

My current programming project is developing several small programs to extend my favorite SMTP server. They’re written in C mainly because the C codebase they extend provides many useful abstractions, but also because I’m enjoying extending my C learning to Unix-specific facilities and idioms. I’ve been working on this code for months (in tiny, mostly unpredictable increments) and am relieved to finally be on the home stretch. Knowing I won’t have any more patience after the code’s finished, I recently took a brief detour to write the Unix manual pages first.

The final program is a kind of SMTP proxy. I tried writing it in C from the get-go, but found myself spinning my wheels needing to learn too many things at the same time. With the goal of getting to the finish line sooner, I stopped and did a spike in a language I already know pretty well (Perl) that happens to offer easy string manipulation and Unix system call bindings. In my spike, I learned first how to become an invisible filter between a client and a server, faithfully relaying all input and output without interference (using the system calls pipe(), select(), read(), and write()). Then I made sure of my understanding by refactoring to small functions with intention-revealing names and dependency-revealing signatures. Then I tried intercepting certain client requests and modifying certain server responses, as the real proxy will need to do. Now that I know how, I’m translating to C, one small intention at a time.

Can’t wait to ship it, maybe even this week. It’ll feel very, very good to be done, and it’ll free up my brain to refocus on much-much-much needed regular physical activity.

Looking further ahead, I’m in discussions with a potential employer. It’s a remarkable workplace and the gig would be right up my alley, so if we can find a mutually agreeable arrangement, I’ll probably accept that in a few months I’ll be leaving the nest with some regularity. Right now it’s still hard to imagine choosing to spend much time away from my wife and son. But it’s possibly slightly harder to imagine how I’d manage to never work again. Gotta do something, sometime, someplace. This here could turn into an excellent option. I’m hopeful.

Posted September 19, 2017 at 02:08:40 PM EDT Tags:

In mid-August, the week after the big Agile conference, I led a “Behavior-Driven Development for Everyone” webinar for the Toronto Agile Community.

Problems are better solved when you’re better involved. That’s how you make your living, and that’s what BDD is all about. We’ll work together to solve a problem in a way we can all understand and trust, expressing what we want in plain English and automating our tests with a tool called Cucumber. Don’t worry, you won’t be put on the spot at the keyboard — I’ll handle all the coding!

What we did

There were several dozen people watching online as I programmed out loud with Cucumber in Perl, taking questions along the way. Of course, it wasn’t nearly as collaborative as a group of two or five could be. We tried to mitigate the unidirectionality by stopping regularly for question breaks, and to elucidate the differences between my unilateral onscreen actions and BDD as it is meaningfully and collaboratively practiced.

The video:

What I learned

In the webinar, side-by-side-by-side, I live-coded the human-readable Gherkin spec, the programmer-readable step definitions that bring the spec to life, and the code being developed to meet the spec.

In doing this, my intention was to illustrate how these three pieces are connected (or might fail to be) and how they must evolve together — in other words, to give concrete impressions of the cost of maintaining Cucumber tests and of the value they might provide in return.

We didn’t get to retrospect together, but I suspect a couple things worked somewhat well for the group:

  • Choosing a notoriously difficult-to-read language of implementation, to drive home the point that it’s not necessary to understand the code to understand the state of the product
  • Demonstrating what a developer’s work looks like when Cucumber is involved

I think I could have delivered more on my intention to illustrate Cucumber’s cost and value as a BDD-supporting tool if I’d spent less time typing. Next time I present this material, if we can’t do it collaboratively (as I did for AgileIndy last year), I’ll use a technique I’ve used before and simply forgot about:

  1. Develop the demo code in advance, committing at each interesting change
  2. With the audience, move through the changes at leisure using Magnus Stahre’s git-crawl.

Read more

In addition to the references in the slides, here’s a story of my own about seeking greater effectiveness through BDD, from my series about the human value of TDD.

Learn more

What would BDD look like in your context? Need help getting started? Get in touch! If you’re in the New York metro area or willing to try a remote consultant, I’d love to work with you. Otherwise, I’m happy to refer you to an expert hands-on instructor in your area.

Posted August 17, 2017 at 01:00:00 PM EDT Tags: