[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]