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.