Many conferences have a hallway track, I loved that Agile Manchester had a jigsaw track. The organisers put out a jigsaw on a big table where attendees could mingle over searching through the 2000 pieces and chat at the same time. Such a great way of breaking the ice. And such a brilliant metaphor. A complex task is achieved through self organisation. Teams self-select and offer assistance all without intervention and imposed coordination or management. Who’d have thunk it?

The conference in the heart of Manchester kicked off with a keynote by Dave Snowden. It didn’t have an ideal start, Dave was not able to attend in person due to a problem with his car.

I’m sure Dave didn’t imply that Scrum is a car crash - and I apologise in advance for such a cheap joke - but I couldn’t help chuckling to myself. The keynote itself - titled “Rewilding Agile” - was very interesting. He started out with an observation. Scrum has only been so wildly successful because it was codified and therefore easier to follow that Extreme Programming (XP). The original manifesto writers were thinking of XP rather than Scrum.

More recently, agile has got a bit of a bad name. There are so many snake oil merchants and dodgy certifications that even Dave himself was able to sign up for a course on the Cynefin Framework where it turns out that the seller didn’t know how to pronounce the Welsh word and Dave only managed to score 50% on the questions about the framework he created. He still got a badge though.

That was quite a sobering thought, the problem with agile software delivery is that it is too easy to stray away from the roots and end up with an Agile Software Delivery Industrial Complex that tries to squeeze every last bit of fun out of delivering software. Of course, I’m thinking of SAFe here (this piece provides a good tear down, and this is also worth a read), but it also applies elsewhere. Andy Hunt said “Agile has come to mean doing half of scrum poorly and using Jira” and unfortunately, in past lives I came across this pattern all too often.

Dave Snowden ended his keynote with offering a way out:

No, it’s not Settlers of Catan, but Hexi which offers kits to combine lots of different methodologies from different frameworks. I’m not sure whether this came across as a little bit too sales-pitchy, but I am somewhat reminded of XKCD standards:

My Turn

Next, I had a lot of fun delivering my “Love Letter to Legacy” talk, based on this blogpost.

It’s an old problem

After the switchover, I really enjoyed Sath’s talk about Product Leadership. A couple of slides really jumped out at me. First of all, that nothing really changes:

And secondly, how many and how much biases influence us:

That’s a lot of bias!

I think, one thing to learn there is that it is really difficult to change attitudes. My take on this is that it is really difficult to change and that there are still a lot of opinions out there that think of producing software like building a house, or constructing a motorway. Release trains and waterfall should be consigned to history, but that’s easier said than done.

Talking of attitudes

Talking of attitudes that should be consigned to history, I loved Evelyn’s talk about Eating Frogs the Agile Way. Not only because she gave us a step-by-step guide to reducing our workload, but also because I am a fan of “hustle culture not necessary!”

Talking of hustle culture

One of my favourite conversations of the conference was with Paige on the jigsaw track, where we discussed interviewing. We very quickly agreed that “leetcode exercises” are pretty pointless. They verify that a person is able to cram lots of algorithms in their head that they’ll never use again. I loved his practice of just getting people to pair on production code as part of the interview. That gives the interviewee a chance to see what the work is really like and pairing or mobbing at an interview can give some really good insights. That of course presupposes that you do pairing or mobbing at work. Not everywhere is that forward-thinking.

In his talk the following day, Paige threw down another challenge. He asked us how many teams actually practice coding together? And why wouldn’t we practice as a team. Athletes don’t stop practicing once they start doing competitions. Golfists will spend hours and hours practicing their golf bat swings. Sportsball players will kick the ball again and again and again. So why aren’t developers honing their craft?

He took us on a journey of using Deliberate Practice:

One important point was to do this during production time. It’s not lunch and learn. Practicing your craft is work! Couldn’t agree more!

Serendipity

I had been looking forward a lot to Emily Webber’s keynote on the second day. “Team Memory, Sharing and Serendipity in Hybrid workplaces” took us from pre-covid times, where work was centred around the office, to post-covid times where work is increasingly remote or at least hybrid.

She found it interesting how the attitudes had shifted. All the big corporations that are now insisting that return to office (RTO) is absolutely necessary were the ones that said during lockdown how remote working is here to stay.

Emily proceeded to explain how important it is as an organisation to reinforce:

• team memory: this is the knowledge of the team, how people moving affects that team knowledge and how remembering context is important.
• join up the organisation: silos are bad, silos encourage inefficiency
• serendipity: these are the chance encounters during coffee breaks or chats with people at lunch. These are really important for creativity and for solving problems.

During his keynote, Dave Snowden mentioned that informal networks carry trust. Formal networks don’t. And trust is needed to get to the truth. In my opinion, Emily was making the same point about serendipity. And if Dave and Emily’s word isn’t enough, how about Steve Jobs - adjusted for post-pandemic:

I loved Emily’s closing point about the cost of remote serendipity. Having random coffee or team days, or sessions for playing games is not free. But consider the cost of burn-out, commuting or stress. I know what I’d like for my team.

Psychological Safety

One of my favourite talks of the conference was Jit Gosai’s journey through Psychological Safety. Now, I’m convinced that psychological safety is one of the most important success indicators in a team and have heard and read quite a bit about it, but I found Jit’s presentation to be one of the most succinct and comprehensive ones I’ve seen so far.

Interestingly, it is the same presentation that he would give as a principal tester at the BBC to introduce teams to the concept. I loved how the presentation flowed and the logical approach on why psychological safety is such an important part of working together successfully.

Psychological safety is the belief that the work environment is safe for interpersonal risk taking

It is not about creating safe spaces, avoiding criticism or conflict. That’s a really important distinction. If the environment is safe to take a risk in telling a colleague or a boss that something is not right, then problems can be discussed rather than hindsight applied when something invariably goes wrong.

The other really important aspect of Psychological Safety is how to create and destroy it. Leadership has a very big influence. It is really easy for the wrong kind of leadership to destroy safety almost instantly. And it is very hard to build it back up. But leadership and management are also two different things. Using micro-leadership it is possible for everyone to contribute to creating the right environment. Note, unlike micro-management, micro-leadership is to be desired. We’re all leaders and influence each other!

The Cat Situation

Unfortunately, I wasn’t able to make the final day of Agile Manchester. I was gutted about it, I had seen Vimla speak before and was looking forward to seeing her again and I also missed some ex-colleagues speak. Hopefully, next time! But our cat had a seizure. She’s fine now.

Conclusion

I titled this post “agile is fragile”, because as attendees of an agile conference I think it is fair to say that we all agree on the benefits of working in an agile way. But what we mustn’t do is to take it for granted. Capital A Agile certification slingers are only too ready to send out impressionable young project managers into the world that take a dogmatic view of agile based around one or another framework. It is really important to remember that agile was created because building software is not the same as building a bridge, but there is always great temptation to think that with enough planning and design, we can exactly estimate how long a specific feature will take to build, despite the body of evidence against it. Sometimes we have to remember that building software can be a counterintuitive thing. We say that more and smaller changes are safer than big ones. We want to deploy more frequently to go faster. We want to estimate less to be able to spend more time on planning. And when we do plan, we want to do it in smaller teams and just leave them to it.

Doing this is not obvious to everyone and it takes a lot of patient explaining. As Emily said in her keynote, sharing needs to be done:

• where people are
• little and often
• repeat, repeat, repeat

So we need to go out in our organisations and explain and convince, collaborate and campaign for people over process. Agile methods must always support people, not become rigid processes themselves!

Final Thought

Paige got some stickers from Charity Majors for Agile Manchester and dropped them on a table next to registration. I managed to snag this one, which is now my new favourite:

Tags agile conference

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