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 »

Whatever your iterative practice, and whatever you call the repository of requirements, the best start to an iteration – planning and execution – is a well-defined, well-understood backlog. Agile is not new in this, but some of the practice that’s developed around planning and backlog preparation doesn’t help. Here and in some subsequent notes I’ll suggest some ways of thinking about backlogs to improve the experience of teams when it comes to turning backlogs into features.
Read the rest of this entry »

A good perspective on teams, motivation and change in a recent article on InfoQ, posted by Urs Peter and summarising a keynote and book by Mark Lammers. Lammers is coach of the (six-times world champions) Netherlands women’s field hockey team. The book is not (yet?) translated, so its good to have these ideas summarised.
Read the rest of this entry »

When estimating and planning with a team, one kind of question that keeps coming up is “what if”. What if a server isn’t ready, what if another team hasn’t delivered a library, what if Harry isn’t around that day, what if there’s no coffee. In some cases of course, these represent real project risks, and you need to record, track and account for them, but in many cases they can reflect a more general sense of worry - worry that we don’t quite understand what will happen, worry that something unexpected (but I don’t know what) will derail our work.

It’s great to be able to kill these little worries. I’ve found something that helps is asking about whether, if the bad thing happens, we’re confident our ability to deal with it at the time. This is, of course, proposing a real option, but doing it in a way which hits on a team or individual’s ability to deal with a situation as it arises. Put this way, I’ve found most people able to put the worry in perspective, and it evaporates.

As Bobby McFerrin says, Don’t Worry, Be Happy.

Thanks to Steve Freeman for a great pair of book recommendations - Atul Gawande’s Complications (A Surgeon’s Notes on an Imperfect Science) and Better (A Surgeon’s Notes on Performance).

Keen observation, great writing, and a mine of great stories about individuals and groups working in a field of particular “risk and consequence”, as Gawande memorably puts it.
Read the rest of this entry »

Having been - a little - disappointed by the Wieck/Sutcliffe book I talked about here, I went back to the source and dug out the article :from which the book draws some of its stories (specifically the narratives of operations on aircraft carriers). “Collective Mind in Organizations: Heedful Interrelating on Flight Decks”, first published in 1993 and collected in Making Sense of the Organization.

Its a stimulating read (and convinces me of the value for practitioners of going back to the source - leave the management books for management types…). Among many insights - the contention that organisations concerned with reliability offer more examples of adaptive group intelligence (the “collective mind” of the title) that those that are concerned with efficiency.

In software, agile practices are directly concerned with building strong, adaptive teams - so one of the misunderstandings that arises when agile is implemented is that practitioners come at development process from the direction of reliability (we can build an iteration’s-worth of features again and again, under precise steering from product owners) whereas management thinking is grounded in organisational thinking that emphasises efficiency (lowest cost, predictability).

Organisations that develop reliable group practices often do so because “the consequences of any lapse in attention are swift and disabling”. At the other end of the scale, repetitive industrial processes are clearly areas in which cost and predictability rule. Software development is in the middle, and it’s going to be interesting to see how the tug-of-war between reliable (agile) and efficiency (outsourcing and its friends) continues…

Courtesy of JP’s blog, a stimulating article by Nicholas Carr - Is Google Making Us Stupid? - along with a set of rejoinders on The Edge from the likes of George Dyson and Jaron Lanier.

I like the article a lot (it passes all my criteria for non-fiction writing I wrote about a couple of weeks back). There’s a self-consciously contrarian side to it that goes too far - Carr seems to suggest there’s an evil conspiracy amongst software developers in general and Google in particular to overthrow Civilization As We Know It. I don’t think there’s an argument with his key thesis - that the nature of the way we interact with information on the web, and the way it’s replacing the sustained narrative of the media of yore with a multiplicity of fragments of information, changes the way we structure our attention, and changes the structure of thought and hence the mind. I’m not going to comment on it directly (read it!), but here are some of the resonances that it evoked for me, from my own experience and from other bits of reading and thinking I’ve done over the past few years
Read the rest of this entry »

Nice blog on teaching kids programming from Nat Torkington. There’s also a summary (which in an unsummary fashion says a little more than the original about some aspects of the work).

Interesting insight about ditching Lego Mindstorms in favour of MIT’s Scratch. Torkington suggests that the Mindstorms hardware just doesn’t consistently provide the expected feedback/reward (if the light sensor isn’t quite up to stopping on the line, for example), whereas the feedback/reward cycle for a pure software environment like scratch is much more immediate. I’m inclined to think we may have seen the last of the real Lego/Meccano generation (when all you had were rectangular bricks, roof pieces if you were lucky - now everything’s pre-moulded…) It’s telling that Lego’s new lease of life is as video animation platform.