I’m on the plane returning from a Scan Agile conference that was just joyful. What made it that way? Was it the setting in the gorgeous looking Paastorni conference centre, was it the fact that the hotel was next door or was it because the speaker dinner the night before the conference set just about the right tone? Erm, of course that all helped, but I think it was the people. Jose - one of the organisers - said that all their work stopped at 9 o’clock in the morning on the first day. Then it was all down to the attendees and the speakers to get together, connect, chat and exchange experiences. Or just talk shite and have fun.

I was there to do my legacy talk, but mainly I was just glad to have come to get the change to talk to lots of people. There’s that P word again. People. It’s not surprising that at an agile conference, people will want to talk about people. I’ve long said that 80% of software engineering is social and only 20% technical. Especially nowadays “in this ever-changing landscape of revolutionary and groundbreaking time of…” (I think that’s enough to trigger Eli) where Silicon Valley is trying to sell us on the idea that code will write itself and people just need to talk to the machine in the right way, it is important to focus on what people bring to the table.

Story Time

Let’s start at the beginning. Linda opened the conference with introducing us to the first Programming Playground, which she built in Helsinki. Linda is a techie turned children’s author, and makes complex tech concepts accessible to children by getting them to play with cardboard models and more. And now children can jump on a keyboard in a park. What a great idea!

But what is even greater is the amount of thought that goes into public works in Finland. Playgrounds need to last, and they are not just for playing but also for a social good. And one of the great experiences for Linda was to discover how children are using the playground in ways she never imagined. They make up their own stories!

Ah, stories. There’s that other seemingly constant in our world. People need stories. People learn and communicate in stories. I was fascinated to learn from Osita that after only 20 minutes we tend to forget nearly half of what we’re told. And that listening to stories is one of the ways that we can make concepts more memorable. He introduced us to basic storytelling rules and structure and how culture is created by stories. And, as we know from Drucker: “Culture eats Strategy for breakfast”. Maybe that’s why we’re so hungry for stories.

I always think that telling stories, telling people what went great and what failed is a really important skills for any engineer. We don’t work in isolation, we can’t do it all ourselves. So we need to communicate, collaborate and come together. And stories make that possible.

Markus came next, and I really liked his talk because there is a bit of a fairy tale that I often hear:

We can’t use agile for something safety critical

Now, when I last heard that it was mentioned in the context of a financial app. Not exactly life and death stuff. So I was particularly tickled by the story of “decommissioning a nuclear reactor using agile”. Markus and team spent 10 years planning and executing the clean-up of a reactor on a university campus. Now, that wasn’t in some remote location, but 5 minutes (by Moose) from where the conference was hosted. What can be more safety critical than that?

Instead of the usual waterfall approach, they worked in sprints. They iterated, even when it came to talking to regulators. Instead of trying to get everything together and 100% accurate first time, they entered a dialogue with the officials. Chatted, asked questions and were able to get the right information. I would argue, regulators are people too! ;-) So treat them as such! But how much easier is it when you can fix problems early!

Another point that I really liked about the decommissioning is that they pushed for transparency. Any issues were collected as tickets, discussed and recorded to be able to do better next time. Their mantra was to “just raise a ticket”. And when there was an unexpected contaminated water leak, they didn’t bury the story but proactively told the public about it. That’s how to build trust!

Jira and Nuclear Waste

Now, I can’t resist a jibe at Jira (yes, that’s what they used), but it’s not often that the Atlassian stack is literally full of nuclear waste.

But seriously, if I hear “we can’t use agile for something important” again, I know what to point to!

Let’s move on, from safely decommissioning a reactor to guardrails: Areti told us all about how we can get confidence in our release pipelines. Continuing the thread of transparency and treating people like people, it’s important to be open:

• Do we know whether we can trust the tests?
• Have we told people on support what was changed?
• Are we monitoring our build pipelines?
• Are we balancing avoiding and handling errors?

Lots of really good questions there, and I also liked the emphasis on psychological safety. If you don’t have a culture where it’s ok to raise doubts, warnings will not only go unheeded but also unspoken.

My Turn

Then it was my turn to talk about legacy systems and why I think that people should learn COBOL (because so many systems still provide value after lots and lots of years) but the people are retiring or otherwise disappearing. But I also tried to convince people that legacy doesn’t mean it’s shite. You can learn a lot! For anyone really interested, here’s a recording when I did the talk previously.

Did someone say COBOL?

Talking of COBOL, our Thursday closing keynote speaker - Tricia - knows COBOL and is trying to get her children to learn. Sensible move I think.

Maybe less sensible was the idea one New Years Eve of betting she can do a handstand and hold it for 10 seconds. The talk was a tour de force about resilience. It took 18 months of hard work, it took compassion, confidence, courage and dealing with complexity. I really enjoyed reliving Tricia’s journey and she weaved a fantastic story on what it means to be resilient. Mainly she confronted all the little lies she told herself. Like “I can’t do it” or “I need to do it on my own”. I think it shows real strength to show vulnerability in admitting that it took lots of work. And then she only went and did it. On stage. In front of hundreds of people. In heels. See for yourself. Respect.

Lies, More Lies!

Fast-forward to the next morning and the next keynote. Sander talked us through all the lies that organisations tell themselves. We started with a menti. Perhaps unsurprising, the audience decided that the biggest lie we tell ourselves is that “we are agile”.

One by one, Sander dismantled all those comfortable things we tell ourselves.

• “we are special”,
• “we just need more people to increase output”,
• “we can transfer knowledge easily”,
• “we can work on multiple things simultaneously”,
• “we need to scale”
• “reports in themselves are valuable”
• “AI will fix everything”
• “products provide value”

That last one is a bit funny. After all, don’t we all want to be product-led organisations? What’s the point of product owners if “products provide value” is a lie? Well, it’s people. People use products to provide value. That is a really important distinction. We just forget it too easily in my opinion. People are important, whereas products… meh, there’s more than one way to achieve a goal.

That people point was driven home by Justyna later. Her talk was titled “Product Starts with People”, and it contained a really interesting observation: We have lots and lots of product metrics like customer satisfaction, conversion rates and hundreds of other numbers. But what about the people that build the product? All to often we just have one number: how many people are in the team? We don’t know whether the team is happy or frustrated. We should apply a bit of systems thinking and realise that people are at the centre. It costs a lot more to replace someone than just the hiring cost.

People are not resources

I hate it when there is talk about “we need more resources” and mean people. Engineers (and managers for that matter) are not interchangable bums on seats. It really pays dividends to make working fun. People who laugh together can work together, so why not invest in that. Make it fun, show your appreciation and find out what makes people tick.

That’s the advice from a product manager, because the product is made by people, so she tries to look after them, connect with them and provide the right environment. Simple!

It’s People, People!

There was one more people-centric talk I really enjoyed. That was Pawel on “fighting tribal knowledge”. He explained how important knowledge is. It’s that stuff that gets lost when Alfie retires or Bertie gets made redundant. And documentation won’t often save you.

Who hasn’t got a confluence instance that is full of outdated stuff and you can never find the page that you are looking for? I often found myself searching on Slack to find links to confluence pages, because the confluence search is such a wasteland.

I really liked the idea of “do-not-bother-me duty” where team members are not allowed to be interrupted with questions for a week. I see this not so much as a way of giving them some much-needed focus time, but as a way of showing up bottlenecks. What is the thing that only Fred can do?

We shouldn’t be focussing on knowledge, rather focus on teaching and learning. So many skills and useful bits of information are better learned by doing!

But Won’t AI Fix This?

I am a bit of an AI sceptic. I get triggered by it quite badly. So when I read about MobAI twice in the program, my thinking was along the lines

Here we go again, here comes the snakeoil

But I was intrigued enough to join a workshop run by Kimmo and Maarit where we used AI to program a PiSloth as a mob, which was fun. (Hehe, child’s play again)

And then there was Joe’s closing keynote on MobAI. I have to admit that when I first read “ex-Tesla employee” my view was clouded by the current shitbag of Muskian politics. But luckily I managed to snap out of it, and the more Joe talked about how he built an EV racing team with agile methods, the more I listened. How wrong the preconception of “you can’t do agile with hardware” is, too. Joe built teams around the same philosphy of Finland’s Future Crew that managed to create demos with hardware that was not thought possible. Eventually, he won the 24-hour Nürburgring by keeping it simple. Sticky tires and a light frame. Everything was kept as separate as possible and people focused on improving things iteratively.

Just like mobbing. Just like agile. Or how agile should be before the certification salespeople and big consultancies get their hands on it. That enabled him to build a new road-legal car in a week. When he went to Tesla, the modularisation meant that new car parts could be created in 45 minutes. Now he’s doing the same at Toyota. So much so that the famous Toyota method has been thrown out. Do I hear a million agile voices cry out at once?

Enter MobAI

So how does AI fit in? Well, it was refreshingly people-centric. Joe proposes the following way of mobbing:

• a driver does the actual job (programming, building car parts, creating music)
• a navigator advises the driver

so far so normal

• an AI-wrangler (not its official title) consults an AI model and passes relevant information on to the navigator
• the AI-wrangler also records the things that help the driver

By collecting three simple things:

• Question
• Context
• Answer

The AI-wrangle basically builds up a knowledge base that gets fed into the model

This where it gets good

Now, one of the things that is really important is that the model that is trained is your own model. Don’t train ChatGPT or Claude, train your own model. Why should the Silicon Valley techbros benefit from all your knowledge? The know-how that you feed into the model is value, at the end you could sell it. Why would you give it away for free?

Well, this is unexpected

As I’m writing this I am still try to grasp the implications. This way of using AI makes even a grump AI-sceptic like me sit up and take notice. This makes sense, the people aren’t replaced by an AI, they just get another tool. Separating the driver and navigator from the tedium of trying to prompt the LLM to spit out the right information allows them to focus on the task at hand. The AI-wrangler can pay attention to the discussions between the driver and navigator and record the relevant and useful bits.

Best bit of all: this doesn’t require a fancy all-singing, all-dancing model. Joe says he’s using Llama2 on his laptop.

Well, well, well. Very interesting!

More Cowbell

I loved ScanAgile. It was chilled, interesting, exciting and felt like all those people I never met are long-lost friends. If you get the chance, go! You’ll learn something new! And you’ll meet cool people.

And that’s what it is about. People!

Tags scan-agile conference agile

If you'd like to find more of my writing, why not follow me on Bluesky or Mastodon?