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]