On Thursday, April 11, I presented a webinar with SmartBear called Mob Programming Explained. The abstract:

Software development is complex. It’s knowledge work. How often does one developer know everything needed to solve a customer problem with code? And on that rare occasion, how beneficial is it to the business for nobody else to have been involved?

Enter Mob Programming: the whole team, together, solving one problem at a time. Come learn how it works, how it relates deeply to Agile and Lean values, and how it can address a surprising array of organizational and technical challenges. Not a programmer? Mobbing on complex problems is for you, too — and so is this presentation.

The video:

Missed it?

Invite me to present internally for your organization in the NY metro area. Or take a look at my upcoming speaking engagements and some conferences and meetups I’m considering.

Loved it?

Let’s take a free half hour and explore how my rare combination of technical coaching and impactful conversations could be useful to your organization.

Get in touch.

Posted Thu Apr 11 14:00:00 2019 Tags:

Habits can change

I have a habit I like very much: incorporating some professional training every year. Last year my needs led me to go on a coding tour.

I also have habits I don’t like very much, particularly about how I allocate my time. So when I heard Personal Kanban training was coming to New York, I needed to allocate only a small amount of time to deliberate. Sue Johnston helped, too.

20 minutes in, I could tell my learning would be in good hands with Tonianne DeMaria and Jim Benson. The ideas I was hearing were ones I knew and cared for, and they were being used in the service of people being whole people.

Emotions contain information

One such idea: a leading indicator for software quality problems is the emotional state of the developers. (For me, this connects directly to Michael D. “GeePaw” Hill’s formulation of made-making-maker.) If we’re uncomfortable with what we just delivered, that’s a signal. If we ignore our emotions and the information they contain, we’re likely to experience them again, more painfully. Or — check this out, fellow humans! — we could help each other observe and value our emotional signals.

Another such idea: in Lean manufacturing, where work is standard, variation is desirable to reduce. In Lean software development, where work is knowledge, variation is desirable to understand. Can we learn to expect where it comes from? If so, our planning will improve. (Can we differentiate “accidental” and “essential” variation? If so, we can drive down the former and our planning will further improve.)

Lean in code and class

What does the application of Lean principles to software development look like? Perhaps the best known example thus far is Mob Programming: when the whole team works on the same problem on the same computer, we get single-piece flow, a WIP limit of 1, just enough decisions made just in time, shared context, and easy predictability. I had enough to say about mobbing, it seems, to be called “the Mob Programming guy” in our class. In response to Pomodoro Technique, I also offered what I might call “Inverse Pomodoro”: when you are being pulled away, write down your next thought before you lose it. Then it’s waiting for you when you come back. When my work is programming, I do it like this.

What does the application of Lean principles to teaching look like? A couple Big Apple Scrum Days ago, Ryan Ripley and I did an entirely audience-driven talk where folks told us what they were wondering about and that’s what we talked about. Jim and Tonianne did this for two whole days, relating each idea back to previous ones, often via previous visuals. As a result, I found myself relating familiar ideas in new ways. If I hadn’t encountered most of them previously, I might well have been overwhelmed. It was plenty to take in as it was.


Hearing about Jim and Toni’s working relationship, I realized: I’d pay someone to irregularly but periodically wipe my kanban board (and absorb my reaction). I tend to habituate quickly to my board and forget I have agency to rethink everything about how it works. When it’s been cleared, I’ve been reminded. After several emptyings, I might even find myself less attached to my backlog. Might be nice.

Hearing about Personal Kanban in the service of whole people, with health explicitly non-negotiable, I was reminded of a hypothesis: a balanced life is a small-batch-size life. Mine hasn’t been so balanced lately. Returning to visualizing my work — everything I need to do to have the life I want — will help. I’m eager to get to my office, lay out a dozen stickies with fresh design considerations, and build myself a fresh board.

Previous trainings

Posted Mon Mar 11 12:47:24 2019 Tags:

On Wednesday, March 6, I attended New York City BSD User Group and presented Maintaining qmail in 2019. This one pairs nicely with my recent DevOpsDays Ignite talk about why and how to Run Your @wn Email Server! That this particular “how” could be explained in 5 minutes is remarkable, if I may say so myself. In this NYCBUG talk — my first since 2014 — I show my work. It’s a real-world, open-source tale of methodically, incrementally reducing complexity in order to afford added functionality.

My abstract:

qmail 1.03 was notoriously bothersome to deploy. Twenty years later, for common use cases, I’ve finally made it pretty easy. If you want to try it out, I’ll help! (Don’t worry, it’s even easier to uninstall.) Or just listen as I share the sequence of stepwise improvements from then to now — including pkgsrc packaging, new code, and testing on lots of platforms — as well as the reasons I keep finding this project worthwhile.

Here’s the video:

Posted Wed Mar 6 21:59:47 2019 Tags:

On Thursday, February 21, I attended New York XP & Agile and presented Strangle Your Legacy Code. As a mob, we practiced adding features to an old SMTP server without modifying its code.


Given an ancient codebase that makes refactoring risky and expensive, how do you clear a path to continued delivery? The old wisdom says the best time to plant a tree was 20 years ago, and the next best time is today. But if you already have a gnarled old source tree, preserve your software investment by planting a Strangler: a pattern for reaping continuous value from your existing system while growing new functionality alongside it.

We’ll take a quick look at a Strangler, demonstrate the basics of Mob Programming, then split into small groups to test-drive new features into the system. You’ll leave with a powerful strategy for extending the useful life of working, valuable software — especially when it’s hard to change — and with a free bonus development practice to accelerate your team’s learning. For a limited time only!

Wondering what this interactive, participatory session was like? Take a look at Derek Graham’s writeup from last summer.

Posted Thu Feb 21 21:39:40 2019 Tags:

In late January, I was at DevOpsDays NYC in midtown Manhattan to present Run Your @wn Email Server!

My abstract:

When we’re responsible for production, it can be hard to find room to learn. That’s why I run my own email server. It’s still “production” — if it stays down, that’s pretty bad — but I own all the decisions, take more risks, and have learned lots. And so can you! Come see why and how to get started.

With one command, install famously secure email software. A couple more and it’s running. A few more and it’s encrypted. Twiddle your DNS, watch the mail start coming in, and start feeling responsible for a production service in a way that web hosting can’t match.

Posted Fri Jan 25 17:53:41 2019 Tags: