It seems to me that some of the thinking in complexity science is starting to have more effect on the way we think about software. The very first Scrum book, for example, has a section giving a complexity science view of how Scrum works, so this thinking is by no means new.

I’m finding that many people involved in agile projects are increasingly happy to think about the structural implications of complexity (those, that is, who can get beyond the “we’re at the edge of chaos - how cool is that” reaction). However, when considering software development as a complex adaptive systems, they lose the view of what it means to be adaptive. Stating the obvious here, but to adapt (1) means adapting to something, so you’d better get good at making sense of that something, and (2) means changing - explicitly and consciously doing something different.

I think there are a lot of people claiming to work in an agile way (and there are certainly many who aren’t) who are scared of changing, resist change, or simply don’t know how to change themselves, their teams or their organisations. The system of software is not just the end product that a team delivers - it’s the team, its tools, its memory (as recorded in change logs, wikis, IRC and mail trails) and more: this is the system that embodies complexity, and the system that must (but so rarely does) display adaptation.

Sadly, not the great movie, but anyway:

Thanks to Koen van Loo and Guy Vaneeckhout of ADMB for inviting me to talk in Brugge, Belgium in February. There are pictures from the talk, a video (it gets going after the customary “word from our sponsors” 10 minutes in), and an interview with Belgian IT weekly DataNews (in Flemish, of course, so I’m not sure how well it really reflects what we talked about: I’m not sure I said “beware of unrealistic expectations” in so many words, my point was that many organisations underestimate the discipline and attitude to change required for successful agile adoption, and I think there’s a strong sense in which our expectations need to be higher. Ah well..)

It was a pleasure meeting folks at the talk and in the day I subsequently spent with ADMB - thanks Koen, Guy.

… was a panel discussion I ran on Tuesday evening at a joint meeting of the SPA Conference and the Extreme Tuesday Club. Ten years ago, at OT99, Kent Beck gave a keynote which effectively kick-started agile in Europe, and Paul Dyson and I ran (I think) the first conference workshop on XP this side of the Atlantic. I asked four of the UK’s agile pioneers - the aforementioned Paul Dyson, Tim Mackinnon, Rachael Davies and Ivan Moore, to tell the stories of how they got started in XP and agile development, before the proliferation of books, courses, coaches, conferences, certification; where they think the world is at today, and what they hope and fear for the next ten years of agile.
Read the rest of this entry »

On Sunday, a mind-stretching Haskell tutorial by London-based Hoodlums. Yesterday, Joseph Pelrine’s workshop on Coaching Self-organising Teams, then Peter Marks and I put twenty people through the mill in a dragons-den exercise on Pitching Agile. And in the evening, a beatbox workshop from the incredible MC Zani. And still two days to go…

A longer answer to a good question asked after my talk at SDC 2009. Someone asked if they should give in and let their line manager attend their team’s iteration retrospective. The short answer is clearly no (in the safe assumption that the manager in question wasn’t participating in the day-to-day work of the team).

However we’ve all come across managers who through insecurity or a desire to control (or indeed both) insist on coming along. In this case there are a number of things you need to establish, in pretty much this order:

Find out why your manager thinks they need to attend. What are their objectives? If it’s to find out what’s going on in the project, tell them to observe your daily stand-ups from time to time, or your review of the iteration deliverables, or improve whatever status reporting you’re sharing. A retrospective is not the place for this. If it’s an interest in what the team is planning to do to improve their practice (from their perspective)/performance (from the manager’s), copy the manager in on the retrospective actions, and arrange a brief meeting to go over them . Turn the (potential) conflict into an opportunity for better communication.

Explain what the retrospective is for. Tell the manager that the team will be talking about tools, techniques, ways of facilitating designing and coding - heavy duty geek stuff - to help them get their day-to-day work done better.

Tell the manager that they’ll inhibit conversation. If you’re lucky, you’ll be able to do this freely and openly, though in the circumstance we’re looking at here it may be unlikely. You might be able to play on their authority (”the team are a little in awe of you”) although that can backfire, as they may see it as an opportunity to break the ice (if this is a genuine desire, ask them to take the team out for beers one evening).

If all this fails, and you can’t escape by (for example) scheduling the retrospective at a time when you know said manager is occupied or away, then you’ll have to deal with said manager in the retrospective. Perhaps you could arrange to do something essential and highly technical (review of SCM branching, discuss pros/cons of moving to a new version of development tools, talk about ways of improving design discussions). Or structure your retrospective as a workshop in which you look in detail at some aspect of the project (performance in a particular area of code or infrastructure for example). All being well, this will get the message across. Then (of course) hold the real retrospective (sans Manager) in the coffee shop or pub afterwards.

Just returned from a trip to Göteborg, Sweden, for SDC 2009, the first of what the organisers plan to be a regular series of developer events. 450 delegates, mostly Swedish but some from further afield, gathered to hear a keynote from Kent Beck and participate in a densely packed programme, streamed around Java, .Net, IBM System i, development process and methodology, and emerging technologies.
Read the rest of this entry »

Here’s a situation I’ve seen many times. Generally in large rather than small organisations, but I don’t think a company has to be huge to suffer from some variant of this. Someone (let’s call them “Worker”) needs access to a resource to get their job done. They have to apply to a second person (”Gatekeeper”) to get this done. For some reason, there’s an organisational policy in place that determines that Worker is not allowed access to the resource. Somewhere in the organisation there’s a third person (who we’ll call “Deus ex Machina”, or “Deus” for short) who has the authority to override or change the policy.

Examples of a resource might be (say) a particular server, system or VPN, and the policy may hold that workers of a particular sort (say, contractors rather than permanent staff) are not permitted access to that resource for security reasons. It’s important to realise that the request is not an arbitrary one - our Worker really does need access to the resource to work effectively. Other than this, the details aren’t important - I’m sure you’ve seen this situation, and can fill in your own examples.
Read the rest of this entry »

Stress and rhythm - both musical terms, but both also part of software developers’ everyday lives.

Sometimes I hear from a team or individual that the stress of achieving sprint or iteration deliveries every one or two weeks is turning them off the whole idea of agile development. This is a sign that something is wrong, and is an indication that (as often happens) one aspect of agile practice is being emphasised at the expense of several others. Programming is design (all the way down), design is a creative activity, and it’s well established that the experience of stress is completely at odds with the states of mind associated with creativity. (Caveats, in case you’re yelling at this point. One - there’s a difference between stress and challenge, and sometimes too little challenge can be more stressful than too much; Two - yes, there will always be the occasional pathological case, an individual who is able to be genuinely creative under pressure, who maybe even - as a consequence of their own particular psychology - needs the pressure. I’m not convinced this is healthy, and I’m looking at what I hope is a more general case here).
Read the rest of this entry »

I like Jeff Patton’s approach to agile product development - rooted in his experience as a user experience designer, which (unless you’re delivering APIs or pure web services) has to be the place to start. He has a good post on what he’s called the Backlog Map, although the technique he describes is just one way of structuring backlog.

I’ve been liberating backlogs from tools for some time now - one of the things you lose as soon as you move from cards to spreadsheets, databases and web-based agile planning tools is the ability to manipulate the backlog in multiple dimensions (Patton quotes a colleague who notes that - when workshopping the creation of a backlog - you’re building a tree, with branches and leaves, but then it’s as if you pull all the leaves off the tree and put them in a big bag. Backlog mulch!). It is more than two dimensions of course (you can put cards on top of each other, of course, but also by moving them around and grouping them differently you expose multiple dimensions of structure). Doing this with a team is a great way of sharing the big picture: and when all the cards are (really) on the table it becomes very easy to see if anything’s missing, or duplicated, or if you have significant variations in scale, and so on.

A great post from Steve Freeman on what he learned about programming from his experiences as a musician. I’d reiterate the necessity of practice, and underline the fact that at a certain level, practice moves beyond being a chore and imposition into something of immense absorption and value. One of my favourite expressions of this is Pat Metheny’s 1996 Commencement Address to graduands at Berklee:

…the fundamental reward that I still get the most satisfaction from, is the process of what being a musician is. It is that need and desire to want to go home and practice that’s the coolest thing. The part where you start with nothing, have a musical idea or vision or aspiration, and through discipline and organization and preparation, and especially inspiration, you finally end up with the capacity to do something that you didn’t know you could do.