Coevolution in biology references a change triggered by one object interacting with another over time. Bumblebees interact with flowers over time (the illustration obtained from the wikipedia article on the subject which is poor and really needs some attention) and both are modified in the process. The idea has been picked up by many of us working on complexity in human systems to apply to culture, ritual, artifacts and identity. As interaction happens over time patterns form, and as those patterns stabilise they create irreversible pathways. Its why in human systems weak signal detection and outlier monitoring is so key. If you allow coevolution to progress beyond the point of no return its difficult to counter radical shifts in culture attitudes and so on.
Now while coevolution happens naturally, there is not reason why we should not use the process deliberatively. In my post yesterday I suggested that Seddon (and by implication others) were missing the opportunity provided by coevolutionary thinking. By suggesting that manual systems should be perfected before technology is procured, and restricting technology based systems to what the manual system was capable of (per Seddon’s example) seemed to me an unnecessary and potentially damaging constraint.
Now of course Seddon’s wider complaint that It people offer things that people don’t want, needlessly complicate large projects etc. is valid. But the solution is not to abandon the radical transformation that technology can bring. Lets take the iPod (I almost said humble but decided against it) which has become ubiquitous over the years and in consequence all modern car radios now have an auxiliary socket. Development in one section, combined with human agency has produced a physical modification in another. For those of us who drive long distances this is a real boon, for me story books are essential for long distances along with podcasts etc. There are many other examples where people interacting with different technologies have enabled co-evolutionary processes which stabilise unanticipated needs to the point where they become the norm.
Now the needless complication to which Seddon refers is no co-evolutionary, it is an imposition of something on a user base which has no understanding of its potential by a group of technocrats who have little connection with the day to day work which they are about to disrupt. The problem here is not that technology cannot provide radical benefits, but that the granularity of the experiments is wrong, and there is no real initiation of co-evolution. By dealing with systems that are too chunked (I like that word as it is more expressive than the simpler big) we inhibit any change of the multiple small changes by micro-interactions over time that are necessary for co-evolution.
One of the ways I suggested yesterday is the use of social network stimulation for system design, another the use of mass narrative capture over time using SenseMaker®. I’m going to summarise the first of these today and pick up the second tomorrow. All of this will thread back to my earlier sequence of knowledge management posts by the way. The basic principles of SNS as a method is that people self-organise into teams based on pre-determined constraints. Pure self-organisation is anarchy, constrained self-organisation allows evolution to take place (a theme I am building on some of the Agile/Scrum/Lean work I am doing). The constrains are designed to ensure variety in team formation. They might for example include specific technical skills, or users from defined backgrounds in both cases qualified by defined levels of experience.
Having determined the constrains we then focus on a series of broad problem definitions for those aspects of a project which fall into the complex domain of Cynefin. Those which are in simple and complicated can be subject to fairly strict definition, and in the case of simple Seddon’s restrictions are probably OK. However its the complex issues which are going to cause most of the grief. The self-organising teams (which remember include both users and techies) then work on proof of concept prototypes which are tested against a broader population. The teams choose what will they do. If what the produce demonstrates utility when presented to that broader population then the reward to to be allowed to continue to build that element of the system. The “punishment” is to be put on one of the other waterfall based teams!
Now what has happened here is two levels of co-evolution. Within each team multiple small interactions over time produce capabilities that could not have been anticipated or designed. Technical members of the team learn about user needs in the context of small interactions and vice versa. The second level is where multiple self-organising team interact with the overall project. Instead of a separation between users and technical staff, we create multiple common merged identities within an experimental and time boxed environment.
More on that method, or rather than application of the method in the new year after some more work, meetings and experiments. However I hope it makes the point that if you understand the theory of systems you can go beyond simple declamations of what works or does not work. Tomorrow I will look at an even more finely grained method namely narrative based requirements capture.