About Max Johns

Content strategist and web writer.

When someone asks a simple question about “agile”, and you try not to write a book in response

From: Wife (work)
To: Me (personal)
Subject: What’s your opinion on Agile?

[Blank email]

From: Me (trying to not open multiple boxes of Pandora, clean multiple Aegean stables, or attempt solutions to multiple enigmas wrapped in mysteries)
To: Wife (work, which by the way is nothing to do with software or web or anything like that)
Subject: Re: What’s your opinion on Agile?

As a way to make software? I’m very much in favour.

From: Wife (just asking questions that probably seem totally normal)
To: Me (personal)
Subject: Re: What’s your opinion on Agile?

What about the process being used in different contexts?

From: Me (doing my best to not obsess over the way ‘agile’ is not a process)
To: Wife (work, possibly while googling ‘Agile’ for the first time)
Subject: Re: What’s your opinion on Agile?


I’m going to try to not get too detailed here, because this could turn into something book-length.

1. Manifestos

Agile software dev began as a manifesto – a set of principles. This can work anywhere, and I like it. There are a bunch of other disciplines that have copied the idea of explicitly stating “we value X more than Y, A more than B, and C more than D”. It’s a good way of thinking through what you do, why you do it, and who you do it for (without thinking too much about how you do it).

This is something eminently adaptable to different contexts.

2. Processes

One or two layers down, you get to “how we do things”. This is where Agile splits into a bunch of different religions with the same god.

Some people believe that “it’s not agile unless you’re doing a 10-minute scrum every morning” or “it’s not agile unless all your tasks are written up on a shared board”. This focus on process is wrong (see the manifesto: it doesn’t give a crap how often you meet or where you write your to-dos).

Usually when people want to do agile, they’ve seen a set of processes that they want to adapt. Depending on the processes, this is where context matters. Agile software development usually needs you to break big pieces of work into lots of little pieces – ideally pieces that don’t have to be done any set order. For software that’s fine, but there’s a lot of things that you can’t do that with. You can’t write a novel by doing all of Character A’s story, then doing all of Character B’s story.

My opinion on agile at the process level is that there are a lot of really useful practices that can be adapted to all sorts of uses in all sorts of contexts, but there’s (a) no set of processes that combine to become ‘the way Agile ought be done’; and (b) there’s no complete set of processes that can be usefully picked up and carried from one context to another. At [former employer] – the best agile house I’ve seen in action – different teams would use different processes. They were all agile, and they were all good, but even the slight context switch from [building one sort of thing] to [building something very similar] meant that a different set worked better. SO…pick and choose carefully, trial things, see what works and keep doing it; see what doesn’t work and stop doing it.


Another layer down. Slack, Trello, sticky notes on a whiteboard, JIRA…whatever tool you use to track your work and let people see where you’re up to – that tool is not an “agile tool”. It’s a thing that you’re using in an agile way (if you’re using it right). It’s very easy to use these things in non-agile ways. I’ve seen teams think they’re agile because “we have Trello now”. No. Just no.

But such tools are incredibly adaptable and can work pretty much anywhere.

4. So.

Working out loud, doing one thing at a time, demoing your work publicly, organising things into sprints and having sprint routines (e.g. demo sessions, post-sprint retros), sizing tasks collectively, letting teams choose their own work from a backlog they don’t directly manage…these are all adaptable things that I reckon you could pick up and work with almost anywhere.

Ok, I have a drop-in session to go and run. If this makes sense, then awesome. Otherwise, let’s talk.

Content Strategy, Simplified, is dead. Long live simplified content strategy.

I’m interrupting an extended period of not blogging to quickly write about Content Strategy, Simplified. That’s the name of a little consultancy I set up last year. I kind of hoped at the time that it would one day become a medium-sized consultancy. It didn’t, but that’s okay.

Better than okay, in truth. Continue reading

Tools vs expertise: A conversation about writing, processing words, and setting type

A couple of years ago, this tweet was pinned to the top of my timeline for a few months. I still quite like it:

Last night my good friend Brandel Zachernuk picked up on this and no, I have no idea why he was sitting around pondering things he’d seen on Twitter 23 months ago. Whyever that was, we had a good chat and came up with a few things that are worth keeping, so here’s a transcript (edited for grammar and to remove chat about children, radio, SpaceX, and macroeconomic psychology). (The two of us aren’t very good at staying on track.)

BRANDEL: I just had a neat thought, related to your Keanu moment about ‘word processors’
Microsoft Word and its ilk never started as being tools for writing.
They were tools for typesetting
That’s a different task you do at a totally different time.

MAX: I suppose the typewriter had already combined composition (i.e. authoring – choosing the words that you use to express your ideas) and typesetting, but by incident of their mechanics they had limited almost every possible design decision to choice of 1 option.
You buy a typewriter and it comes with a single font. You choose a paper width and the margins are built in, etc.

B: That’s true, typewriters fit in there too as an uneasy middle ground. I guess there was such a ‘bright line’ between publishing and everything else for a long time.

M: Typewriters took away typesetting decisions which word processors then gave back, but they handed those decisions to authors rather than designers.

B: It’d be great to talk to people who did information work in earnest before computers made all the phases and distinct disciplines so muddy.
Get the tangible sense of what proofs and drafts were, etc.

M: Yes! It’s funny to think that disciplines or sets of skills were mixed up with control of machinery – e.g. you must be the visual designer if you have access to all the little metal letters
…and if you don’t have any little metal letters, you’ll never get to set type in your lifetime.

B: But then the task of setting those letters into a line of type was so arduous that you couldn’t really be expected to manage any editorial decisions too.

M: And now that we’ve built machines that reduce the labour and take away the physical objects, we stress about the wrong people making bad decisions. People are never happy!

B: People misidentified what’s hard about a lot of stuff. [They] mistook the physical things as the hard parts [when the hard parts are actually the seemingly] incidental things also done by people doing the physical work.

M: I reckon that designers have done a much better job of reclaiming their expertise, and redefining it for modern tools, than wordsmiths.

[…We get distracted and end up making jokes about what Karl Marx would make of modern-day space exploration, before Brandel drags us some of the way back to our original track…]

B: Yeah people in liberal arts and humanities haven’t done a great job of seizing the systems of digital production for their own ends.

M: Do you mind if I blog this conversation? There are some useful things in there that I want to have written down somewhere, and a transcript on a blog is as good as anything else for now.

B: Fine by me! It’s really interesting to be surfacing what computers aren’t doing, or haven’t been set up to be doing properly. It’s so easy to lose sight of the way into the present moment and which values were prioritized.


That’s as far as we got. Interesting? I hope so. I think so, too. But I think that of pretty much anything Brandel comes up with. (Seriously, have a look at what he’s done on Codepen.)

Inter-city content strategy meetup love is quite possibly the world’s purest, and greatest, form of love

At CS Forum last year the three of us who organise Auckland Content Strategy Meetups met a lot of out counterparts from other cities. Briefly, we even shared a stage with them all. They were, and are, all lovely and brilliant people. And since that conference, a lot of inter-meetup activity has followed. Continue reading

What Twitter thought of ‘Marketing people and content people: It’s complicated’ at CS Forum

I love presenting at conferences. Love it. I love picking a topic and spending hours thinking about it. I love having a reason to read up on stuff that interests me. I love that when you say to someone, “I’m working on a talk and I’d like to hear your thoughts on [topic x]”, they almost always give up time for a chat. At events, being a speaker is a great way to meet people. At CS Forum (which was great, by the way), someone found me during a coffee break and opened with, “Hi, you made me really angry,” but with a smile on her face. I love seeing and hearing reactions to what I present. I love it all.

Except the post-conference wrap up blog post. I don’t love that bit. It’s hard, and it takes longer than I want it to, and especially after the best conferences, it drags back the post-event blues that you get for a couple of days afterwards.

Last week I was at CS Forum with a presentation called ‘Marketing people and content people: It’s complicated’. It was a brilliant conference. My talk was fun. It seemed like people got something out of it, which is the result you want as a speaker. The slides are embedded at the bottom of this post. Continue reading

Bots will be bots

Chatbots! After floating around the edges of the useful web for a few years now, the right underlying technology is finally making it plausible for companies and organisations to build and run their own online bots. That’s cool, and it’s brought to mind a lesson that I first learned in 2009, when we launched an experimental (now dead) chatbot at NAB.

For writers, that lesson is:

Let your bot be a bot. Make it sound like a bot, let it behave like a bot and, most of all, tell people it’s a bot.

For strategists:

Your bot is here to help people learn stuff and complete tasks. You’re not here to beat the Turing Test.

For designers:

Over-humanised bots are just another version of skeuomorphism gone bad.

We didn’t get this right in 2009. We used a photo of a woman in a headset, I wrote in as chatty a voice as I could, and although we used the terms like “online assistant” (too vague) and later “virtual assistant”, we weren’t clear enough about who or what this thing actually was.
Continue reading