New blog for complexity study

My continuing investigation into the effect of TDD on code complexity (and maybe other things, too) will continue on this new blog.

Agile has little to say about Projects

At the 2011 UK Agile Coaches Gathering at Bletchley last week I convened a session about the desire for (larger) organizations to execute "projects" but the desire of people working in them to use "agile" techniques. I perceive a contradiction there.

Agile has little to say about Projects, a photo by Keith Braithwaite on Flickr.

For the purposes of the discussion I define a "project" as a management structure with a start date, and end date, a budget and a goal. (It says "goal", but subsequent scribbling makes it look as if it says "goat", prompting one of my colleagues to quip: pick which one you want to sacrifice!)

My contention is that when people talk about managing Agile work they generally mean Scrum or these days Kanban (or something very much like them) and that these techniques talk mainly about the steady state of product development and how to control that. They have relatively little to say about what happens at the beginning of a "project". How to get one signed off, for example. Kanban seems particularly weak on this. Nor what happens at the end of a "project" when a set of features go into production. Scrum seems particularly weak on that. As a side note, when I first started working with banks it took me a long time to properly grasp that when they talk about the "delivery" phase of a project they don't mean the relatively trivial bit at the front where the programmers write code.

So, the conclusions of the group were that projects exist as a management structure to mitigate a certain kind of risk in a certain way. As such, I would not agree with this tweet (in reply to one I sent about the very session:

The concept [of a project] is superfluous as it does not add business value.

the concept seems to persist as (some people) believe that having projects allows them to protect money. They might be mistaken: thinking about risk in software development is often wrong, but the idea of a project cannot be dismissed out of hand.

The group observed that different stakeholders have different concerns at different size and time scales, and these are nested. Scrum and Kanban talk mostly about the innermost few layers of the onion.

There was a concrete recommendation: when communicating from the inner part of the onion (smaller scale, shorter time frame) to the outer, do not talk about "iterations" or "cadence" or much of anything time based. Talk about money: pay something in this range, get something in that range.

Agile Charlatans

At the 2011 UK Agile Coaches Gathering at Bletchley last week I convened a session which was prompted by comments like this one from reddit user grauenwolf:

I used to think people like you were quacks, but now I see that there are teams that really need your services.

Grauenwolf and I have both been on reddit or a good long while and we've had a few...full and frank exchanges of opinion about the merits of this thing called "Agile". The issues I wanted to address in the session were: what causes competent professionals like grauenwolf to think that the sort of people who would go to something like an "Agile Coaches Gathering" are quacks, and what changes their mind? How might we do less of the former and more of the latter?

The output is captured here:

The "Agile Charlatan" Problem, a photo by Keith Braithwaite on Flickr.

It needs some explanation, though.

"Quack" is an evocative word. "Snake-oil salesman". "Charlatan". We felt that these words appeal to an analogy something along these lines: Agile consultants are like bogus medical practitioners.

The poster shows a 2-by-2 matrix (naturally!): well or ill against conventional medicine or alternative therapy. The model is that conventional medicine is mainly for people who really are ill and need to get better, while alternative therapy is mainly for people who are basically well but feel entitled to be "well-er".

Yes, that is quite cynical. We did talk about the fact that some alternative therapies do work, for the things they work for, but when that happens it's not for the reason that the practitioner thinks. And we talked about how some conventional medicine is not nearly as well founded as many people would like (you) to think. But, bear with me.

So, the top right and bottom left cells of the chart are the exemplars. Bottom right is the really bad place: trying to treat a mangled road traffic accident victim with a very, very, very dilute solution of London Bus, for example. Top left is pretty bad too: pushing pills for restless leg syndrome and things even less needing of allopathic intervention.

It seems that there is a problem with some kinds of Agile coaching or consulting or training or certification practices. They could be trying to address a really serious organizational problems with techniques that cannot possibly help (and maybe they even know it), or they can be barging in to teams that are functioning perfectly well and crashing about the place changing things that don't need to change.

How could we recognise these cases? Maybe this way:

1. conventional medicine often leads to treatment regimes that are quite unpleasant
2. people often need to be talked into consulting a conventional medic (partly because of [1])

vs

1. alternative therapies are often really rather enjoyable
2. people often self-refer to an alternative practitioner (partly because of [1])

How to avoid breaking a working team by spuriously making them "Agile"? Watch out for one-size-fits-all solutions. Watch out for inflexibility, a rejection of new ideas (on the part of the consultant or coach).

How to increase the chances that you're really helping? Look for objective evidence of improvement, change your behaviour based upon that evidence.

The final question we came up with extends the analogy. If Agile coaches are a bit like certain kinds of medical practitioners, then what is the equivalent for us of public health?