Yesterday I hosted a workshop at the Agile & Beyond 2019 conference, entitled Come Test Drive With Me (even if you can’t drive yet). I’d love to give a big thanks to everyone who attended, participated, and even tweeted about it.

This session was similar in many ways to the one Amitai and I gave earlier this month, in that it involved attendees mobbing to work on example code. The big difference is that this session specifically targeted non-programmers. Instead of a home-grown SMTP proxy in Python, we used a very simple word-counting program which I adapted from a kata the excellent exercism.io.

Because Agile & Beyond doesn’t have a standard conference mechanism for posting slides and content, I’ll put mine here for any attendees—or anyone at all—to access:

• Slides – including bits that we added live
• Code – at the point we left it after the workshop

For this session, I don’t have as detailed a retrospective as the last. I will definitely say that it benefitted from lessons we learned then: I opted out of using a microphone, and succeeded in getting the whole audience to sit within earshot of the mob. The one thing I would like to change for sure: make the code base a bit bigger. In some early runs of this workshop I had used a fully-functioning web app, but that proved to be just too complicated for programming beginners to deal with in the short time-box of a workshop. I decided at the last minute to start over and rewrite a fresh code base, and now I know I made it a bit too simple. I plan to correct that before the next time I deliver it.

As a side-note, I’ll add that I had a great time at Agile & Beyond. For a conference with the word “Agile” in its name, there were a refreshing number of developers among both attendees and speakers, and a robust set of technical talks in every slot. I recommend this conference to others, and plan to come back in future years.

The Deliver:Agile2019 conference is a wrap. Particularly fresh on my mind: the session which Amitai Schleier and I co-hosted this morning, which was entitled Strangle Your Legacy Code. It was fairly well-attended, particularly given its position in the second-to-last time slot of the entire conference.

I want to give huge thanks to the four intrepid volunteers who staffed the learning mob: Jessica Kerr, Eswaran Balakrishnan, Mihai Popescu, and Llewelyn Falco. You were such an engaged and capable cohort that we did a lot less guiding from the podium than usual.

I have not yet checked on the feedback forms from the conference, but we got a number of very positive reviews on Twitter and in person. Thank you, thank you, thank you to all who provided those. It feels great to know we provided a valuable experience for others. I call out particular thanks to Ted M. Young, who grabbed lunch with me immediately after our session and suggested a number of improvements. Hearing we did well is gratifying. Hearing how we can make it even better: moreso—even the parts that hurt. From one perfectionist to another: thank you, Ted!

Between all the conversations, below is my summary of things we might change to make it even better for the attendees, and why. I definitely plan to do some of these when I do a similar session a few weeks from now at Agile & Beyond. I hope to see some of you there!

If you’re not into bouts of self-reflection, you can stop now. Thanks for reading this far!

Provide Diagrams

At one point during the exercise, Amitai drew a picture on a flip chart of how our strangler app interacted with the underlying SMTP server. This would be a useful thing to pre-draw and to project as part of the presentation bits, possibly as an interaction diagram.

Also: a diagram showing the strangler pattern graphically could make the whole sessions flow more cleanly from the start.

Actually Strangle Something

An audience member called out that none of our demonstrated new features actually replaced existing functions of the System Under Strangulation. Probably good to make it so one of them does, or at least talk explicitly about how a strangler can add value even without actually reducing functions of the old system.

Clearly State the Intent of Each Feature

After completing each test, our highly-motivated mobbers quickly and unceremoniously uncommented the next test and dove into figuring out what functionality it specified. In the interest of keeping the whole audience engaged, we facilitators could have hit the Pause button and then given a brief English explaination of the next desired feature to implement.

Reduce “Background Mob Noise”

This one needs a little explaining: the session’s primary learning goal is to bring about conversation and impart knowledge about factors around using a Strangler to incrementally replace a legacy system: the costs and benefits; the whys and why-nots; etc. The workshop device we use to get this across is a mob—as in mob programming. Instead of just hearing a lecture or watching a live coding session, members of the audience get to actually write and work with a code base, and learn by doing. Pretty sweet, at least in theory. It also means that the session gets a secondary learning topic: we give a quick lesson on the basics of mobbing when we get the volunteers into place.

The trick is that for some members of the audience who aren’t part of the mob, the mob can be hard to follow. They discuss options, try different things, take some wrong turns, and eventually complete the steps which lead to the main learning.

All of this was likely worsened by the high motivation of our volunteer mobbers. They figured a lot out amongst themselves and required very little direction from our microphoned positions. Since they didn’t have microphones, their chatter was hard to hear from the back of the room. Some suggested solutions to try:

Mic the Mob

A microphone could at least mitigate the issue of people not hearing what the mob members say.

Navigate Every Step From the Podium

Even when the mob doesn’t need step-by-step direction, it might be worth offering anyway it for the sake of everyone else in the room.

Narrate the Mob’s Step-By-Step Activity

This one really intrigues me as an option: whenever we let the mob do its own figuring out, provide a sort of play-by-play, explaining each decision and action they take, but for all to hear.

Pre-Seed an Experienced Mob

An of-the-audience mob spends a notable chunk of its time fumbling through the specific platform, language, and toolchain that we happened to choose for our example. Given that mobbing is not our session’s primary learning objective, this effectively becomes noise for much of the crowd. What if we instead provide a pre-seeded set of mobbers who already know those tools? Then the rest of the audience could focus on the ins and outs of the Strangler.

Ditch the Mob For a Regular Live Coding Show

It follows from the above that if we choose to de-emphasize the mobbing in order to focus on the primary learning goal, and we consider having a “hired mob” as part of the show, then perhaps we may as well not even have a mob—just do is as a more traditional live-coding session. I admit, though, that the mobbing feels to me like an important element of the experience we’re trying to provide.

Other Ideas?

Did you attend this session, or a different instance of Strangle Your Legacy Code which Amitai has done over the last year? Do you like or dislike one of the above suggestions, or have some of your own to offer? Tweet at us, or add a comment here.