(originally posted on the code computerlove blog. At the now unreachable link: https://lean.codecomputerlove.com/a-retrosperiment/)

Experimenting with a "new" retro format

For our team's most recent retro we decided to try a new format to see how it affected our discussion. We thought we'd share it here in case it has value for other teams.

What is it?

A retrospective is a practice from XP described on the c2.wiki as

A practice which has an XP team asking itself, at the end of each iteration : What went well ? What could be improved ? What could we experiment with ?

We've recently had several discussions trying to focus on the real and perceived progress of our work and thought it would be beneficial to run the retro with a focus on the impact of our team's principles and practices. Specifically how they relate to delivery of value and speed of delivery.

A few years ago while waiting for a user group to start at the Manchester ThoughtWorks office I bothered a couple of the devs there about their board. That conversation, after a bit of fangling, led to my convincing the team I was on at the time to use a radar board to represent our backlog.

It allowed us to combine a fluid representation of the business's priorities with a physical representation of the cost of reorganising those priorities. But also, in a way you don't get with a columnar board, gave an immediate feedback mechanism when too much work had been proposed or accepted.

Apologies to the two ThoughtWorks devs if I misrepresent any of their good ideas as mine or my bad ideas as theirs.

During Kevin Rutherford's guided discussion on clean code at Agile Manchester 2017 we talked briefly about whether there was a difference between 'cleaning code' and 'clean code'.

I suggested that I might expect to have to make code dirtier on the road to making it cleaner. Being of the opinion that sometimes you need to add duplication in order to see your way to removing it.

As I am a creature of bad habit I jumped immediately into tortuous metaphor.

I've spent a great first day at Agile Manchester 2017. One of the slides at a talk from Anna Dick was the stand-out point of the day for me.

"Find a common language, don't rely on agile jargon"

AMP or Accelerated Mobile Pages is a Google-backed project that allows you to use restricted HTML to delivery static content quickly. Since AMP HTML is restricted it isn't a fit for every site.

Since this blog is published as static HTML articles it is a good candidate for publishing an AMP version. An open source AMP jekyll plugin was amended to add AMP versions of pages.

The major discovery was that the validation tooling around AMP is awesome. Compare that to Facebook Instant Articles where there is almost no validation tooling (that I could discover at least)…

This didn't feel like a topic that justified several posts so to avoid taking too long this is a bit of a whistle-stop tour of adding AMP pages to this blog.

One of the benefits of generating a site as a static artefact (here using Jekyll but there are a gazillion tools) is that the finished product is a known quantity. Anything that's a known quantity can be tested!

Yarn is a new JS package manager that promises to be fast, secure, and reliable. My initial experience is that it is fast. I'm excited about making time to use it for real at work. Kudos to the developers!

Structured Data is a way of adding context to files served on the web so that computers (primarily but not only search engines) can respond to what your content means.

Google, for example, will alter and improve how your site appears in search results based on the context you give your data. And if your site is considered authoritative can use the data to build the knowledge cards it sits alongside other search results.

This blog is only authoritative for being unread but I've not worked with structured data and thought I'd investigate.

<aside class=""mb-2 ml-4 border-l-2 border-l-sky-700 pl-1""> <h1 class="text-base">This post is part of a series on improving this blog #recursion</h1> <div class="flex flex-row"> <div class="flex-grow"></div> <div class="flex-grow content-end"> Next Post </div> </div> </aside>

I recently had a conversation where I said that I couldn't build an AMP version of my blog because I use Github Pages to build and serve it. Github don't allow any Jekyll plugins to run.

Later that day my subconscious prompted me to realise that, since Github pages will serve static HTML quite happily, I could use Travis CI to build a Github repository that held the source for the blog and push the static output to a second repository that Github would publish as is.

Today I had super-fun spotting the opportunity for a refactoring and figuring out how to apply it. I wanted to think it through while it was fresh in my mind to try to cement any learning opportunity

The refactoring in question is "Replace Conditional Dispatcher with Command".

Quoting that source the opportunity for this refactoring is when:

Conditional logic is used to dispatch requests and execute actions.

And the solution is:

Create a Command for each action. Store the Commands in a collection and replace the conditional logic with code to fetch and execute Commands.

It's one of those subtle changes that has real power to tidy up and add to the expressiveness of your code.

If (pun intended) you aren't familiar with it I'd definitely recommend trying it on for size by looking for an opportunity to apply it in your systems.