Last week was Agile Cambridge, the annual, three-day, conference on Agile at Churchill College in Cambridge. Despite the fact that my new job role doesn’t directly involve Agile any longer, I was speaking and I wanted to go for all three days anyway, because a lot of the sessions looked interesting.
For the last couple of years, I’ve been thinking of Agile Cambridge as getting a bit samey – the same topics, often by the same speakers – and I wasn’t getting a whole load of value from it. This year was different, however. The conference had a different feel and a fresh approach, which made it very useful once again. I summarised it after the event on Twitter, thus:
End of 3 days at the 10th
https://twitter.com/dnas2/status/1180147651448315905#agilecam. Main takeaway: Agile is now mainstream. Few talks discussing process, how to release faster, how to get user feedback. Instead, lots of team formation, the need for diverse (inc. neurodiverse) people & safe communication. We’ve come a long way
In this post, I wanted to cover some of the sessions that particularly resonated.
It starts from the team
Previous Agile conferences have tended to lump together the team as a single, homogeneous unit. This time, the role of individuals within the team and their diversity was a key topic.
- Zara Sheldrake from ARM gave a particularly thought-provoking presentation on the subject of Neurodiversity in Agile Teams, talking about some of the ways that Agile is both good for neuro-diverse individuals (the Prime Directive, the role of Scrum Master as a shield, and pairing) and terrible (the enormous PI planning events from SAFe, open plan offices, and the language of sprinting). She discussed some ways that ARM have tried to mitigate some of these factors, both through things like mental health awareness and making the environment better suit the team.
- Through this work, which includes features like setting team norms and personal user guides, they are trying to create a psychologically safe environment for learning. Two other sessions explored how such safe environments have been adopted in other contexts to ensure lessons are effectively learnt in life-and-death situations. In One Super Dog and her servant leader, Darren Yates from Lowland Rescue talked about how techniques for search and rescue scenarios have evolved over the last 20 years. Similarly, Jeff Foster from Redgate explored Why planes don’t crash, again about how the aviation industry goes to very substantial lengths to ensure they fully understand root causes for any incidents, so that flying is made safer. It really made some of our retrospectives seem quite superficial.
It’s always communication…
- Of course, all of this ultimately comes down to the most difficult problem in software development: communication. Nick Maidment, now at ARM, previously Metail, explored some of the challenges Metail had faced and overcome as they moved from a mainly onsite team to a mainly remote one. As you might expect, neither extreme proved particularly problematic, but The Space Inbetween, where only a couple people are remote, is where the difficulties lie.
- One of the few talks to directly relate communication to processes was Your bugs aren’t special by Emily Tate. The challenge is the perennial one that ‘little things’ often get done on the sides of the prioritised work. In one case cited, the ‘little things’ were taking up to 30% of the iteration time. The thing I found most interesting was framing this as a communication breakdown, that different stakeholders aren’t adequately talking about their competing priorities.
- Related to both the psychological safety and communication themes, Redgate’s Chris Smith ran a workshop on Crucial Conversations. He explored some of the theory from The Chimp Paradox to explain how we can help get our ‘chimp brains’ under control at work, and how to accept it when we, or other team members, have chimp responses.
How to get change
- One of the bases of what Chris was talking about is that you can only change yourself, not others. You’re much more likely to be successful by opening your own mind than trying to convince other people of your opinion. This was also a message that came across in Linda Rising’s second keynote of the conference on Moral Foundation Theory. Her argument was that we should aim to listen people into agreeing with us, and we can do that by examining issues from the opposing moral standpoint. For liberals, we tend to argue about care and fairness, while conservatives tend to focus on loyalty, authority and sanctity, so listen for their arguments from their moral foundations. Linda’s other key message in this talk was that correcting people with data tends to lead to them holding their view more firmly. This is because we’re evolved to take quick decisions and justify them later. It’s much more effective if we tell stories around our ideas like a press secretary, rather than as a judge spurting facts.
- The different points of view in a team, and the challenges arising from them, was also the topic of Linda Rising’s first keynote of the conference, Who do you trust? Beware of your brain. She used the example of the Robbers Cave Experiment to show how we are keen to divide ourselves into them/us tribes, even when there is no difference between the groups, and how the tribes were only unified when there was a significant, real-life problem, to solve through joint teamwork. This is a lesson that software team leaders can learn from.
- Selena Delesie’s keynote The Soul of Agile, picked up on some of these points. Her fundamental message was that we get the best from our teams at the intersection of three things: An open mind (curiosity, to have power with an individual, not over them), an open heart (compassion, focusing on the individual) and an open will (reducing fear and increasing courage in the team by being willing to release the need to control individuals and releasing the need to have future plans). Notice the focus on the individual here – you may need to take different approaches for different people.
Diversity in background
- If all of the above focus on individuals seems hard, it’s worth it because of what different skill sets bring to the team. In the keynote The Death of the Liberal Arts, Ashley Hunsberger argued that there is a need for liberal arts students in development teams, because understanding what to analyse, the context of data , writing (communication) and giving feedback are all transferable skills that are gained in essay writing in literary criticism. The ability to juxtapose having a big picture view while also focusing on details is (literally) a feature of art criticism. So why do we often insist on Computer Science degrees in our job advertisements? The other thing that liberal arts students can bring is the consideration of ethics. The need for ethical programming is becoming increasingly visible with the likes of Cambridge Analytica news stories, and so asking ‘How can what I’m building be used to hurt somebody?’ is a useful thing to consider.
- The other regard in which we might want to consider ethics more is asking ‘How does your product end?’. In the final keynote of the conference, Ends – The lost narrative of consumerism, Joe Macleod promoted thinking of the off-boarding journey for your product as much as you think about the on-boarding journey. Considering what happens to a product at the end of life, whether it’s software and there’s a hard user experience to let go, or hardware that needs recycling in an easy way, off-boarding can make business sense in increasing loyalty. (Incidentally, in our field of academic publishing, the whole industry has mechanisms to ensure content lives on after a publisher has ceased to exist.)
So what am I taking back to work?
First off, I haven’t covered a couple of the useful sessions in this post so far, because they didn’t quite fit the narrative flow. Given my recent change in job title, however, I found Stefan Tilkov’s session on Agile Architecture and Innovation particularly useful, and I’m certainly talking to my colleagues about his ideas. I especially liked his proposed Architecture Manifesto on the basis of the Agile Manifesto as a way of explaining what we are trying to do:
– Conscious trade-offs over emerging architecture
Stefan Tilkov
– Documented rationale over quick ad-hoc decisions
– Sustained changeability over easy initial development
– Design for replacement over design for re-use
– Simplicity over fast delivery
Beyond this, the other things I want to do include:
- Considering the needs of individuals more than thinking of Agile as a one-size-fits-all thing that the team agree and compromise on. I may well promote Zara’s talk a bit within the company.
- Trying to change the P1 process we have at work for retrospectives so they are more deep and get to better root causes. Of course we aren’t the airline industry, but thinking about some of their detailed analyses is something we could do to improve.
- I’m going to read The Chimp Paradox so I can look out for ‘chimp responses’ in individuals and account for them better.
- Think more about working with remote colleagues as we are in that ‘space inbetween’ of having just a handful of remote workers.
