Saturday 28 September 2013

Agile Cambridge 2013 Day #3

Lean Coffee

The day started particularly early today with Lean Coffee. It's a great way to look at a wide-range of topics in a short time period.

I got a lot out of the discussion, particularly around technical debt. I need to try the Get Kanban game as that's engineered to show that quality does matter. Someone also mentioned a low-tech way of capturing technical debt; just place a dot on the board when you're affected by it. At least that demonstrates improvements!

Real Options in the Real World

Chris is from a financial background and presented his approach to IT risk management. The briefest of summaries is:

  • Options have value. (maybe an indeterminate value)
  • Options expire.
  • Never commit early unless you know why.

The never commit early unless you know why point echoed Neil Denny on day 1, where he spoke about the delicious discomfort of uncertainty. As humans, we find it easier to close options out, but in reality from a rational point of view we should keep our options open.

Humans are bad at risk management. We have a tendency to want to assign probabilities to failures so that we can pretend that it's not very likely to happen. We should instead focus on time to business as usual; what are the options for recovery?

Chris then looked at how options thinking applies to moving staff between projects. Based on the theory of constraints, there's only one bottle-neck in the system and (logically) we should move people to solve that problem regardless of their role (such as blur the lines between dev/test). We (as an industry) worry about this because of people's attitudes (I'm not going to do testing!) or people's capability (but Joe's the only COBOL guy!).

Chris presented a compelling case. We should (counter intuitively) assign people with least experience to critical tasks first so we can use the experienced people in more of a mentoring/coaching role. The best developers coach; others fix problems with their help. This helps eliminate the "project heroes". Staff liquidity truly delivers agile.

This was a very compelling case, but something doesn't feel right to me. It ignores the human factors. Software engineering is not manufacturing; it's a craft. People also don't have an infinite capacity to learn (or at least I don't!). If I'm switched between projects, and dancing between coaching, developing and testing then I feel my overall effectiveness in each of these areas will be reduced. I mentioned this on Twitter, and I was given some pointers to reading more about this

I'll try to find the time to read that work, along with the Commitment book.

The Art of Systematic Feedback

Marcin Floyran gave a series of examples of how feedback is useful. I've long been sold on this point, and it was great to see it backed up by a series of examples. I've summarized Marcin's formula for systematic feedback below:

  1. Explicit Assumptions (scientific reasoning!)
  2. Clear Objective
  3. Careful design
  4. Learn from Results
  5. Rinse and Repeat

You know you're doing feedback right when you are "acting responsibly to meaningful data". I tried to argue before that we need to do this for coding and encode the explicit assumptions with deliberate development and this has helped me see the pieces that I was missing.

The AutoTrader Experience report

All too often in software development we focus our attention on the 1% of software projects that go well, and we never really look at the problems. The Auto Trader experience report was fascinating and brutally honest. They showed how despite being agile projects can still fail.

Given an impossible deadline, the team panicked. They tried incredibly hard to estimate the project to prove that it was mission impossible, but this didn't help. Instead the team was given unlimited resources (large numbers of contractors) and just told to "do it". It was great to see an insight into the panic, and this video is definitely one to watch on InfoQ when the video goes live!

.

Gamification - How I became a spaceship commander

Tomasz presented an entertaining study in gamification. The goal was to influence the behaviour of software developers to use their bug tracking system and track tasks. It was interesting to see the behaviours that this encouraged within developers. Definitely an area to spend some more time with.

Wrapping up

So what do I take from Agile Cambridge 2013? An awful lot of reading material, a huge collection of ideas floating around, some practical tips for Monday. Job done.

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)