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.

2009 could be the year that a number of big organisations make a success of Agile. This will be because - at the right level in those companies - there will be people who fundamentally understand the principles, have had experience applying them, and (here’s the nub) are effective, inspirational, persuasive leaders. Pushing agile out beyond development teams and single projects is organisational change, and this doesn’t succeed without clear need and great - visible - leadership.* The clear need is provided by the turmoil in the world of business and finance: companies that get this right will survive strengthened, those that don’t will perish or at best stagger through.
Read the rest of this entry »

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.

It’s a link-to-a-quote, but nevertheless Steve Freeman sums up a lot of what I’ve been seeing lately in small and large organisations making the move to agile.

How do developers practice? Practice in music is fundamental - and it’s a myth, by the way, that only classical musicians worry enough about developing technique to the extent of working for several hours a day (there are plenty of stories of the punishing routines that Miles Davis, Coltrane, Charlie Parker and others put themselves through to be able to play what they did, and the same goes for many of the superstars of rock and pop).
Read the rest of this entry »

A backlog won’t look after itself: someone has to care for it, and it has to be fed (and watered, and bathed, and clipped, and pruned…).
Read the rest of this entry »

So this evening I hosted the last talk in the SPA Autumn Series, in which Nick Ababurko talked about how IBM is using a Systems Engineering approach to tackle large and complex projects with its clients. Lots of food for thought: it’s clear to many of us working in agile development that - in spite of what some would have you believe - agile doesn’t scale, at least not in the trivial sense some people suggest (note to Ken - I’m sorry, but Scrum of Scrums just doesn’t cut it).
Read the rest of this entry »

Here’s a collection of backlog smells – things I’ve encountered in backlogs in various projects, with some thoughts on how the backlogs got into the respective states and actions to take to improve matters.
Read the rest of this entry »

So, a backlog item is a quantum of value. If something is of value, by definition it is valuable to someone: agile development identifies that someone as the user (represented by an actual user or by a proxy, such as Scrum’s Product Owner).
Read the rest of this entry »