Complex? Adaptive!

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.

Fighting the Boss - How and When

Vasco Duarte posted this entertaining story about a conflict between an experienced consultant and his new manager over dress code on-site. I commented there, but wanted to explore the story further.
Read the rest of this entry »

Stress vs Rhythm

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 »

Better backlogs (4) - the care and feeding of backlogs

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 »

Teams, motivation and change

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 »

Deal with it when it happens

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.

Reliability vs Efficiency

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…

Crosswords and group mind

Small victories … I’m working with e2x just now, and crosswords (Daily Telegraph and Guardian) are part of the company ritual. Over lunch yesterday five of us scored a first and completed one set by Araucaria, the Guardian’s celebrated and notorious setter.

For thirty minutes we were on a roll. It’s likely that none of us could have completed the puzzle, let alone in half an hour. Several times someone had an insight about a clue which was enough to trigger someone else’s half-solution, and a third or fourth of us would chip in with the complete answer. It’s a good while since I’ve seen as strong an instance of how a team can really work effectively towards a goal: achieving this level of group flow is something to aim for in all our teams.