I’m coming to the end of a small development project with Peter Marks. We’ve been using the Pomodoro technique, individually and as a pair, to pace our work over the course of a day, and have become big fans. We were talking about it: Peter wondered what a Pomodoro organisation might be like, and together we tried to imagine what it would be like to work in one.
Read the rest of this entry »

A few times recently I’ve tweeted on Software Craftsmanship, and my concerns about the form the current emphasis on craft is taking. I’m still trying to understand what it is about the movement that — actually — alarms me. After all, how can anyone be against craftsmanship? That would be like being against world peace, or saving whales, or open government…?

Read the rest of this entry »

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.

An informal talk at Skills Matter last year, on JavaScript and AIR (based on the application I blogged about here and here), given as part of the London JavaScript Meet-up. Mostly ends up being about how it’s perfectly possible to do TDD and nice application structure in JavaScript.

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 »