Some reflections on two recent agile conferences I attended (and ran sessions at). Both very stimulating, with a great deal of learning going on. Both raising questions for me in several directions.
Read the rest of this entry »

Blogging from the Munich Scrum Gathering, so here’s a rare Scrum-focussed blog, though (of course) there’s a lot here that parallels other thinking in the Agile and Lean world. The Scrum Picture is Wrong: well, not wrong, but incomplete. Misleadingly, dangerously incomplete. It’s easier to say it’s just wrong, and this is why.
Read the rest of this entry »

As you’ll know if you’re reading here, I’ve become excited by the way theatre Improv can inspire us as agile coaches. One direct result of this is a day-long workshop I’m organising with Mike Sutton through the UK Agile Coaches Gathering, which will be run by Tom Salinsky. We’re working with Tom on structuring the day around ideas and outcomes directly relevant to coaching practice: collaboration, innovation, status and influence. It’s going to be entertaining, fun, inspiring and useful, and it’s a snip at £65.00 for the day. Saturday 21 November, Highgate, London: more details here.

I’m reading - and enjoying - Alfie Kohn’s classic, Punished by Rewards: The Trouble with Gold Stars, Incentive Plans, A, Praise, and Other Bribes. It’s definitely a one-issue book, but that’s not such a bad thing: what’s more, it’s one of those rare works which is both pleasurably readable and impeccably referenced: three hundred pages of text, a hundred of notes and bibliography, so if you want or need to follow up on the research results which inform every argument Kohn makes, you can. [1]
Read the rest of this entry »

The estimable John Nolan, with whom I’m in the habit of swapping book recommendations, waved Richard Sennett’s The Craftsman at me, saying “I’m half-way through the introduction, but it’s already making me think…”. Recommended, duly bought, and now some weeks later somewhat digested. This is a long time for me: not a reflection on the writing, which is conversational, urbane, knowledgeable. The quality of the discourse and the thinking behind it made me realise quickly that this was a book I wanted to spend some time with.

Read the rest of this entry »

Some years ago, when I was completing a PhD in music theory, a friend observed to me that composers have methods, techniques, processes to help them do things that don’t come naturally or easily to them. This (so to speak) struck a chord, and it’s true in many ways in software development.
Read the rest of this entry »

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.