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 #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

https://twitter.com/dnas2/status/1180147651448315905

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
– 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

Stefan Tilkov

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.

[This post continues from Reflections from Agile Cambridge: Day 2]

Real Options in the real world (Chris Matts)

This was a fascinating keynote investigating how we can consider the options we face in project management as being Options in the financial sense: they expire, they have a value and we should avoid committing to them too early.

Being able to take options requires you to have slack time in which to take them: Chris used the analogy of the lion who is an effective predator because he spends most of his time asleep in a tree. Taking options also involves considering how we will roll back a decision. There was a warning against using mathematical probability to decide what is unlikely to happen, because human beings tend to be too optimistic when calculating risk. Instead, we should aim to have a plan for what we will do if the risk occurs.

The other strand in this talk was around staff liquidity. All too often, we allocate people to tasks because they are the expert in that field. This just creates silos and dependencies on individuals. Instead, we should aim to keep the experts for training other people or for responding quickly to unforeseen circumstances.

The art of systemic feedback (Marcin Floryan)

Marcin’s talk considered the best ways of collating feedback on what we do. The main thing I learnt was about the relationship between the Cynefin model and the appropriate feedback loop to use. Marcin demonstrated how Complex problems should be considered using the OODA loop, while PDCA is more suited to Complicated problems. One area in which I wasn’t so happy was the idea that Simple problems don’t require feedback because there are established practices. Surely those practices themselves have room for improvement?

It’s not your fault – why targets don’t work (Francis Fish)

This talk also had two parts. The first was a reminder about normal distributions and standard deviations. If your business asks for a 6% increase in sales in the next 6 months, this is meaningless if the 6% is within the natural variability of the measure. All too often, we forget this, because we just look at the output from a spreadsheet.Francis suggested that we should put the standard deviation on all the graphs we produce for management to highlight this issue.

The second part of the talk described the distinction of ‘efficient’ and ‘effective’: the former is best for a short-term bottom-line but is high-paced and so there is little room for innovation; the latter is more about the long-term, and allows for innovation and experimentation. The final slide contained an interesting note: that we need to be ‘response-able’ for improvements, i.e. that we need the slack time to improve.

 Unlimited resources deliver faster… right? (Alun Worrall)

I always appreciate conference talks where companies feel able to give a ‘warts-and-all’ presentation, owning up to simple mistakes they have made. This was one such talk as Alun described a big project at AutoTrader which involved releasing some software by a critical date. Having estimated that it wouldn’t be possible, the company threw a load of contractors at the problem, hoping that it would speed it up. But the product was still delivered when it was originally estimated, and all that they had achieved was a lot of stress. It also appears that some fundamental mistakes with prioritisation of the individual components of the system could have been done better, which might have helped some of the project to have been delivered earlier.

How I became a spaceship commander (Tomasz Borowski)

Tomasz had tried using the YouTrack system to create YouGame: a gamification of the story-points achieved. This was initially done in response to a particular set of issues, including tasks moving straight from ‘To Do’ to ‘Done’ on the board, and inaccurate estimation. Tomasz described the issues he had faced in various iterations of the game’s development, including the risk of the leaderboard being used for performance bonuses (not the intended use!), and the need to add a concept of ‘stamina’ to prevent people from marking excessive amounts of work as Done.

To me, it sounded very much like an excessive response, and it must have taken a lot of time to create the app, however impressive it is.

The Art of the Retrospective (Chris Smith)

I’ll admit to having seen a practice of this presentation at Red Gate a few weeks ago but this made it even more interesting for me to see the eventual, finished, talk. As someone who hasn’t traditionally done many Sprint retrospectives with my team, I found the number of practical examples in Chris’ talk very useful. I’m certainly looking forward to trying many of them out.

 

Overall, I thought Agile Camrbidge was excellent, and I hope to be back next year!

[This post continues from Reflections from Agile Cambridge 2013: Day 1]

Change or be changed (Janet Gregory)

Today’s keynote dug down deeper into the concept of how we often can’t avoid change. The presentation was split into three parts: types of change, influences for success and how to introduce change.

The types of change section discussed how we can change a ‘want’ into a need to face change, which often involves seeing opportunity. The change we are driving may have its success determined by other factors, however, including how it was introduced, resistance and whether people feel there is an implicit blame in a culture change. It is therefore necessary to consider any personal agendas people might have. Introducing change involves sharing a vision and involving others, and giving people space to voice any concerns and fears. If the change involves measuring something, it’s also important to explain what we are measuring and why, so they don’t react, thinking they will be punished. [This is something I know that I’m particularly guilty of.]

Scrum & Kanban (Jon Terry)

Unfortunately, this talk had a published title which was different from the one that was presented, entitled ScrumAgiLean, which I had seen previously. The talk is a useful reminder that Scrum and Kanban are complementary, and how they relate to Lean Management. One of the main things I learnt is that we can defer commitment to a particular path by building multiple options at the same time. I wonder how practical it would be to suggest to management that the team should develop something twice in different ways, although I can understand that it can save time in the longer run.

Requirements: whose job are they anyway (Allan Kelly)

This was a disappointing talk in my opinion, as it came across as predominantly being a rant. Perhaps it’s because I’m lucky that at Red Gate we have dedicated Product Managers who talk to customers, but the only really useful thing I took away was a distinction between Product Owner (as an umbrella term), Business Analyst (someone looking at internal users, who are measured by costs) and Product Managers (someone looking at external customers, who are measured by revenue).

Scaling out solutions development with feature teams (Luke Morgan)

This talk was much more useful. Luke started by introducing the ‘Capability Complexity Curve’ to describe how ‘solutions’ different from ‘products’. The majority of his talk, however, focused on the structure of his feature teams, which exist as a subsidiary of a single solution team. For example, he has usability and architecture specialists at the solution (not feature-team) level, to help avoid the issues of Conway’s Law. Another interesting factor was the need to have a DevOps engineer in the feature teams, helping to resolve any infrastructure impediments. The solution team, meanwhile, contains the Release Manager (which is similar to the Project Manager), whilst the ScrumMaster exists at the feature team level.

Open session: DevOps

In an impromptu open session at the end of the day, we discussed the role of DevOps, and in particular whether they should be embedded in the team or separate. The general consensus was that embedded DevOps improves speed and flexibility, whereas separate DevOps teams help get more time for working on infrastructure. Generally, DevOps were seen as being crucial for scalability. Slightly more worryingly, however, the best definition we could come up with was that DevOps are ‘A group to shout at, even though they have no cost centre’.

[This post continues at Reflections from Agile Cambridge 2013: Day 3]

For the next three days, I’m attending Agile Cambridge at Churchill College, Cambridge. These are my thoughts and notes from the sessions I attended on the first day (Wednesday 25th September).

Keynote: Moving towards symbiotic design (Michael Feathers)

Michael’s talk was one of those which warrants further time to digest. There were lots of individual strands that made sense, but if I were asked to summarise a single conclusion in a take-away tweet-sized sentence, I wouldn’t (currently) be able to.

That’s not to say there wasn’t a lot of good, useful content, however. One of the main strands was about Conway’s Law and the relationship between code and the organisational structure of the teams working on the code. At a simple level, APIs and other interfaces tend to form at the boundaries between different teams but this can result in nobody owning the APIs and so all the teams involved end up doing more work so as to avoid changing the API. An interesting idea presented was that of teams having permeable membranes, the model in which teams in this position share information and, sometimes, people break off into the other team.

Another, related, strand was about Spolsky’s Law of Leaky Abstractions. Agile encourages us to abstract our requirements into Stories, but because this abstraction will be imperfect (will leak), the result will be technical debt. We know this is happening if the developers tell us a feature is big because of some side-effects of decisions that have already been taken. The presenter asserted that Agile development teams rarely communicate back this sort of constraint to the Product Owner, which can lead to the effect Conway described. The metaphor of software engineering being like gardening was introduced: in Waterfall models we may be told to plant something without seeing the garden first. Agile lets us see first whether there are weeds that will choke the plant already present but do we tell anyone about this?

One of the ideas we’ve been thinking of at Red Gate was invoked in a further strand: the idea of ‘internal open source’, whereby any team can contribute to any codebase. While it sounds appealing, the danger is that (without an owner), the product will be trashed just as Common land tends to be spoilt by BBQs and people grazing cows.

What linked these threads was that the Agile manifesto’s assertion of ‘People over process’ is more complex than this. Whilst Michael explicitly stopped short of saying ‘Code over people over process’, the idea of code being king, and considerations of the effects of people on code, underpinned the whole presentation.

Complexity, Governance and the Agile Team (Graham Oakes)

Compared to the keynote, this was far less intellectually challenging but still resulted in some useful learning. The workshop mainly comprised splitting the room by our job titles (Developer, Project Manager, Product Owner, etc.) and asking us to dot vote on who should be responsible for taking a range of decisions. We were then asked to place a number of typical business decisions on the Cynefin complexity model.

The result was surprisingly fascinating: whilst it was a highly unscientific survey, the different roles had ranked the decisions and complexity of the decisions in very different ways. Developers, for example, saw most decisions as coming either from individual team members or from the Project Manager, whilst Product Owners saw most decisions as coming from Senior Management or the whole team – leaving the Project Manager responsible for surprisingly little! Similarly, our job role affected which decisions we saw as simple, complex, etc. quite drastically.

Whilst interesting, I’m not entirely sure what to do with the information, or whether it’s even a problem. If I, as a Project Manager, shield my team from Senior Management’s decision-making, meaning that they see decisions as coming directly from me, can’t that be a good thing?

The rituals of great software engineering teams (Alex Shaw)

This was a fascinating talk about the role of ritual in teams, going right back to Confucius (‘Ts’ze, you love the sheep; I love the ceremony‘). The main message was that a key point of ritual can be that the reason for a ritual may be of lesser importance than the ritual itself. There were a few good examples of how the culture of ritual had affected teams, and what can happen to the rituals when the team is upset (for example, by people within the team changing).

Growing eXtreme Programming teams (Rachel Davies)

This was a case study into the way XP is done at Unruly Media. While such insights into other companies are always interesting, there were few original ideas in this. One, however, was the idea of ‘Gold Cards’, whereby team members can opt to spend up to 20% of their time on their own projects on condition that they present back to the team what they spent their time on, if they chose to do this.

We’ve been thinking recently about giving developers some slack time but an enforced 20% for everyone, with potentially little to show for it, seemed likely to work for some people and not for others. This model may be an answer.

We don’t know what we’re doing; let’s go! (Neil Denny)

Probably the best session I attended today and completely relevant to the situation I’m soon likely to find myself in, this was a motivational workshop on dealing with uncertainty as an opportunity for profound change. Although less ‘workshopy’ than I expected, there were some immediately applicable techniques. I couldn’t help thinking, however, that the reality of getting organisational structure to change (if that’s the outcome) was somewhat trivialised.

I’m looking forward to tomorrow…

[This post continues at Reflections from Agile Cambridge 2013: Day 2]