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:

Agile Cambridge 2013 Day #2

Conference Cold. Every conference I attend seems to result in me getting ill. If you see me turning up next time in a mask, then you'll know why.

Conference Protection

Anyway, back to the writeup.

Change or be changed

Change. The ever-present moment of opportunity or terror that's been a staple of every company I've ever worked at. Janet Gregory explored the various types of change that occur in life.

Do you need or want to change? Sometimes you want to change (wouldn't it be great if I was fit?), but sometimes you have no choice(Your health is suffering, you have to get fit). Change can often bring new opportunities (Ford made cars, others wanted faster horses).

Towards the end, Janet highlighted some of the change models. I caught most of them, and I'll push them on my unbounded stack of reading material.

Making Sense of Systems Development

Cynefin. Kee - ne - fen. This is a word I've heard much about. And now I can pronounce it. It's a non-sense making framework (that was a cheap shot, sorry).

The workshop was well-run, and we classified situations as either:

  • Simple (the answer is clear, no need for analysis)
  • Complicated (solvable by an expert or process)
  • Complex (might know what to do better next time, hindsight)
  • Chaos (totally new, no idea how to do things)

There's something about this classification that feels familiar. Learning a new subject traverses from chaos (I've no idea what I'm doing!) to complicated, through complex and then finally simple (unconscious competence) and I can see how it would be a useful tool in the armoury. I didn't see anything that fundamentally changed my opinion (maybe something will click later?)

I'm very sceptical of things you have to pay for to understand (see ScrumMaster courses, Agile certification, Scientology and from the looks of it Cynefin.). I coin Jeff's law:

Blurring the Lines

Chris George presented on blurring the lines. The central premise is that by putting walls between dev and test, we've suffered. By breaking down these walls, we can produce better software.

Chris references one of my favourite papers, the 1968 NATO Report on Software Engineering and starts by introducing a quote by Alan Perlis along the lines of "testing is a process best undertook throughout the product life cycle".

Dedicated testing departments split this process, introducing artificial communication barriers which (due to Conway's Law) resulted in a split between development and test. Chris looked at breaking down this wall and merging the roles of test and development and the positive effects it had on his team.

This was a theme revisited by Chris Matts in the next days key-note. There's something I don't quite agree with from both talks, namely that it assumes that people are fungible resources. More to come on this, once I get my thoughts together.

The Open Session

Due to the conference flu, a number of speakers dropped out at the last-minute. Huge kudos to the organizers for managing to fill sessions at the last minute with interesting and relevant content. The final session of the day was an open session organized by Simon and Ryan.

Our group discussed controversial opinions.

I'm not sure we tried hard enough to rock the boat!

No comments:

Wednesday, 25 September 2013

Agile Cambridge 2013 Day #1

I'm at Agile Cambridge 2013 this week. I participated in the review panel this year and there was a huge amount of quality submissions. The programme looks fab and I'm looking forward to the rest of the week. Here's my notes on the sessions I've attended on the first day.

Moving Towards Symbiotic Design

The opening keynote by Michael Feathers explored Conway's Law which states:

"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

He gave some examples of this in action, and I found it easy to relate these to experiences of my own. When working with remote teams we've struggled with communication issues, and so has the code. The boundaries between "our" module and "their" module was as cloudy and wooly as the communication between the teams.

I've also seen the Tragedy of the Commons that Michael described. I've worked at some places where shared code had no clear owner and thus depleted over time. On the flip side, I've seen shared code be tremendously successful when a team was devoted to it full-time (and that team was highly communicative). Conway's law holds!

Michael's observation that people working on a code base for too long become immune to the cruft that's accruing hit home. Uncle Bob has this great metaphor of developers understanding the geography of their code when working with large classes (this function is just here, after all this whitespace, and the really long method beginning foo...). I think this kind of complexity is what developers who work on a project for too long get comfortable with. When you're a new person on that code base you don't have that historical knowledge and you struggle to pick it up.

So what would change if code were king and people were subservient to it? It's an interesting question. People working on the same code for a long time become immune to the cruft that's accumulated within it. The code is screaming out for someone else to tend to it and address this. With this in mind we should probably be more deliberate about moving people around between software projects

If code was a first class citizen in project discussions then we'd pay more attention to things like "death by 1000 features". There's a point at which adding features to a project becomes considerably more difficult. Perhaps we should push back more and do what the code wants sometimes and not just caving in and sacrificing the code base?

The takeaway for me that we don't do a good job talking about code as a party in the relationship between people and process. We're already happy to change project structure to deliver the product, but let's start to explore changing project structure to drive the code in positive directions.

Revere the code!

Unpicking a Haystack

I thoroughly enjoyed the Unpicking a Haystack session by Duncan McGregor and Robert Chatley. We took perhaps the worst example imaginable of legacy code (decompiled from binaries!) and tried to make sense of it.

There were different approaches tried. One group did a lot of reading (they only had a text editor, not an IDE). Another tried to get a foothold in the code, test it and test their way to success. The group I was in took a slightly different approach and leaned heavily on the IDE. I've touched on this idea before (You don't need tests to refactor).

Our approach was to crowbar out large lumps of code with repeated "Extract Methods", rename things to make sense and use the IDE inspections to fix all the silliness (e.g. redundant variables, constant parameters, unused methods). It seemed to work pretty well, but I think there was some skepticism among others as to whether this was a good idea or not.

I hope in the future development tools will evolve to become something more developers trust and code becomes malleable putty we can shape in seconds. As a thought experiment, imagine if you could put your IDE in "semantic lock" mode and just drag, drop and reshape code to your heart's content with the guarantee that behaviour would be preserved. How would that change your ways of viewing legacy code? How would it change your design process?


To wrap up the group discussed how they might change the way they write code in light of the problems of refactoring. I didn't say anything at the time, but I've thought some more about it. Decompilation loses names (not all names, but some names), but decompilation always preserves types. I've waffled before about Types and Tests.

With this in mind, we should be more aggressive about encoding information within types (e.g. compiler verifiable properties) rather than names. As an example, we found some code with a value that either referenced working directories (pwd) or a password. The type information told us it was a string. The variable name was str12345. We had no idea which one to choose. If the original authors had encoded that information in a type, then we wouldn't have had a problem, the type would describe the shape of the variable.

Rob and Duncan are organizing a Software Archaeology Conference which looks fabulously interesting.

Rituals of Software Engineering

Alex Shaw examined the topics of rituals in software engineering. Rituals have a long history, and the essential parts of a ritual are:

  • Obligatory (not in the sense of being forced, but you feel like you should attend.
  • Admit of Delivery (the style of delivery doesn't matter
  • Consequence Free (measurable outcomes are not the goal

I guess rituals has a slightly negative connotation for me. When I hear rituals I think of animals being slaughtered and cargo-cultism (obviously not a healthy way to do things. From the wikipedia definition:

A ritual "is a stereotyped sequence of activities involved gestures, words, and objects, performed in a sequestered place, and designed to influence preternatural entities or forces on behalf of the actors' goals and interests"

By the end of the presentation I was more convinced that I was disagreeing with a word and not the content. The essences of great team 'rituals' included that members of the team know the context and understand the value and reason for the ritual. With all that in mind, I agree rituals are important for engineering teams and it's a really interesting idea to explore.

Growing XP Teams

Rachel Davies gave us a great insight to how the team work at Unruly media, a company run from the start on XP principles.

I love these kind of experience reports. Speaking afterwards, The Agile Pirate described it as voyeurism. I like that description (slightly sordid though it sounds). It's great to get an insight into how a team works and interacts.

It was interesting to hear how the "Lone Ranger" role worked at Unruly. The idea of having a single developer being available to answer questions from support/sales/product managers is interesting, and I can see how that could help protect the other members of the team from unwanted interruptions.

We don't know where we're going. Let's go!

Last, but by no means least, was a talk with an intriguing title by Neil Denny. This was my favourite talk from the first day, and had nothing to do with software whatsoever!

Neil's talk explored uncertainty, that "delicious discomfort of not knowing". Uncertainty is something we face all the time in software development (because no-one knows how to do it right), so it was great to explore this topic. The presentation style was fantastic with audience participation, touches of humour and an engaged audience.

What's more dangerous than uncertainty? "We are never more wrong that when we are most right". Once you convince yourself that you definitely have the answer then you become closed to better solutions, becoming dogmatic and rejecting alternatives. This is a dangerous place!

The point I left with is that we should treat uncertainty is a challenge to savour, not something to fear. When people are looking for answers, they tend to just want the smallest possible change (confirmation bias?). This often makes us go for the minimal change, rejecting the truth of what we need to do.

There were a few books mentioned which I need to add to my reading list

And then...

So there I am, it's the end of the day and I'm outside the college waiting for a taxi. I get talking to someone else waiting and I discover that she's a retired mid-wife. Nothing too strange yet. And a bit more talking and I discover that she's from the same area that I was born in. A few minutes later, we talk about times and ages, and realize that she would have worked at the same hospital I was born in. Putting more dates together we discover that I've just bumped into a person who possibly delivered me. Freaky

Looking forward to tomorrow!

Oops, should have mentioned we're hiring.

No comments:
Subscribe to: Posts (Atom)