Agile Lab Blog

Why is software development in the complex space of the Cynefin framework?  Why can’t you hire professionals who’ll do a good job and deliver it on time? There are a whole bunch of reasons.  We’ll just visit a few right now.

Shifting Sands

 Any software development isn’t going to happen on just one piece of technology.  It’s going to happen on a “stack” of technologies.  Any complicated piece of software is going to at least involve an operating system, a database solution a front-end programming language and a back-end programming language.  All of these are changing all the time.  Beyond this the hardware that runs this software is changing all the time.  As an example, I spent two years working on a web-based platform for academic publishing.  During that time the iPad came out.  This created an expectation on the part of the majority of our end-users – American undergraduate students - that everything they read should be available on the platform: today.  But reading on the iPad changed almost everything.  The licensing model, the required look and feel, the software capabilities that we needed in the team, the number of UI Designers we needed. This is really pedestrian, but it needed to be pointed out, and argued about a lot longer than you’d think. Developing on the iPad meant we needed iPads!!! And there was no organisational structure in place that could provide us with this kind of cool hardware.  For the first twelve months all development happened either on private iPads or iPads bought against regulations on company credit cards.

Nobody knows what they want

Expressing software requirements in natural language and pictures is a vague business fraught with difficulty.   What the people funding a project want aren’t the same as what the customers want.  What the customers and the people who are paying for it want might not be the same as what the regulators want and what is most sensible, maintainable and supportable from a technological point of view.  Collecting requirements is a bun fight.  What makes it even worse, the best know ways of collecting requirements – the good practices and approaches that you’d want to be tending towards if you were trying to be professional are completely the opposite of what people who don’t know much about developing software, and actually, a lot of people who do, think it should be.  Iterative methods work best. But intuitively, most people believe deep in their bones, that the best way is to try to detail absolutely everything that they want in a specification document right at the beginning of a project.

Few people know the value of what they want

The people who are initiating a project rarely know what the value is of what they’re asking for.  What about regulatory projects you might ask?  What about projects which meet a legal requirement?  Well first of all, these are a very small proportion of the projects that ever get undertake, secondly, even in these kinds of projects, what’s precise required to fit a regulation and what the cost of not meeting it will be is rarely understood.

Most projects get kicked off because of some perceived business value, because somebody manages to persuade someone who has control of the purse strings that a project might be a good idea.  But the exact nature of this value is rarely known.  This shouldn’t be a surprise because most businesses are skirting around the edge of the “chaotic” part of the Cynefin problem space, if they haven’t been pitched right into the middle of it.

Again, the intuition to deal with this is completely the opposite of what actually works.  If you’re exploring an unknown space, the best way to do this is a little bit at a time – iteratively.  The basic, basic, Agile approach, make a list of things that you want to do – do the most important ones from a business point of view, get something working, let everybody have a look at it, play with it and then decided what comes next.

Software development discovers value

One account of what designers are doing is that they are “discovering new value”.  In my experience this happens all the time with software development.  Once stakeholders and users see actual working software they see values and opportunities that they couldn’t or certainly didn’t imagine to be possible before they saw it working.  The weird thing is that this is very often perceived as a problem with a project.

We’re not Chinese

I don’t think this is racist.  Although some of my super right-on friends have suggested that it might be. If you can tell me how it is racist, then please write to me and tell me.  Even if it is racist, I’m not sure I care, because it’s still funny.  The “not Chinese” thing comes from this little exchange in a Goon show.

Bloodknock: You Chinese think of everything!

Eccles: But I’m not Chinese!

Bloodknock: Then you’ve forgotten something!

These are what might be described as “forehead slapping moments.”  The moment when you realise that making changes in one system is going to break almost everything that happens in another system.  If you’re not Chinese, you’ve probably forgotten something.  Actually if you are Chinese, you’ve probably forgotten something as well.  Small changes in one system can require huge changes in another system.  It’s in the nature of software systems that are being built on and built on that they get more and more fragile.  The new bit that you’re adding to them might, and actually very often does, push them over the edge.

Software is in the complex space because of the high level of Discovered Demand

In books like “Freedom from Command and Control” John Seddon draws a distinction between two kinds of work is done in the systems that he examines – Value Demand and Failure Demand.  Value demand is work that delivers the stuff that people want.  In the examples that John Seddon uses in his book this is stuff like having a plumber fixing the heating system in a council tenant’s flat.  Failure demand is fixing things that have gone wrong with the value demand.   Again in the example John Seddon gives, this is work like having to deal with calls from irate customers because the plumber didn’t turn up when he was supposed to, or did turn up, but was unable to fix the problem because he didn’t have the requisite part. I would argue that the work that Seddon is talking about is largely in either the simple space (arranging appointments) or the complicated space (fixing heating).  The big difference between this kind of work and software development is that in software development there is completely different kind of demand that consistently rears its head – discovered demand.  Stuff that the customer realises that they want half-way through the process – because as we’ve discussed above, they don’t really know what they want, nor the value of what they want until they see it. Stuff that the software developers realise they’re going to need half-way through the process.

Coming back to our central theme of “Late and Over-Budget” the weirdest thing about “discovered demand” is that it is almost always treated by developers and stakeholders as failure demand.