Pagina's

Showing posts with label agile. Show all posts
Showing posts with label agile. Show all posts

Wednesday, 30 May 2012

Calmly going where no (wo)man has gone before (or have they?)


My colleague and I are setting up an agile consultancy within an existing consulting firm, Qualogy. Our mission is twofold – spread the agile word, increase agile expertise among our own consultants and build and promote an agile services portfolio. I've been involved for about a year and although we have a long way to go, things are really beginning to take shape.

Because of the nature of our mission we are always looking for ways of killing two birds with one stone. For instance, we offer (agile) training to our partners and clients, but also to our own consultants, which has the double function of increasing agile expertise all round while hopefully making a name for Qualogy as an agile provider. This is easier said than done however and we're not the first to think along these lines; the market is nearing saturation point. We try and set ourselves apart by concentrating on technique over process and by getting the very best to come and offer courses not easily available elsewhere (in the Netherlands). For example, Ron Jeffries & Chet Hendrickson have been to Qualogy twice to deliver hands-on agile development training.

Recently we added Gojko Adzic's Specification by Example training to our portfolio. As is our policy, Wouter & I attended this first instance of the course at Qualogy. Due to some late cancellations from our own consultants we could only claim a tarnished victory – good service to our clients, not much penetration among our own consultants. This slight disappointment did not impinge (much, after a while :-)) on my enjoyment of the course though. As is always the case with when attending these courses, I'm not just interested in the material but also in how the course is run. Adzic was a joy to watch.


This post is not however about the course itself, or even Gojko's admirable delivery of same. As Adzic himself writes, and as was clear from how he delivered the course, Specification by Example is method/framework/etc. agnostic. He tended to use lean terminology during the course, speaking as he did of bottlenecks and/or the theory of constraints as opposed to impediments for instance, while at the same time, his explicit insistence on cross-functional collaboration smacked of agile. What I would like to share from my learning is the realisation that Specification by Example (or BDD or A-TDD) might well be the M (mashup) we so badly missed at CALM alpha!

At CALM alpha, Dave Snowden named three heuristics that seemed to offer common ground between (social) complexity, agile and lean; fine-grained objects, cognitive spread and dis-intermediation. Fine-grained objects meaning; small well-defined stories, short clearly-demarcated iterations etc, cognitive spread meaning; input and reasoning from multiple perspectives & interests, set-based design etc and dis-intermediation meaning; visualisation, no separation of design & implementation, narrowing the gap between information and meaning etc.

Back to our Specification by Example course – Gojko was prompted a number of times during the course to state that any specification which required an ever-growing list of examples to illustrate it should be split. While working on turning 'classic' requirements into specifications with examples, merge&diverge was explicitly employed to ensure the best results. But it was while examining a bunch of specifications with examples for how useful they might be as respectively, a tool for shared understanding, acceptance tests and/or documentation, that I was struck by why I had found this idea of living documentation so powerful all along.

Requirements that are tests that are documentation – no handovers, no translations, no interpretations, no esoteric jargon pitting one guild against another – that's lean, that's agile. Specification by Example is the ultimate in dis-intermediation!

Tuesday, 15 May 2012

Project managers as scrum masters? (Know your attractors!)


Inspired by a flattering response to a couple of tweets of mine at the weekend, which were a condensed paraphrasing of the Cynefin model's approach to complex problems, and keeping in mind @0x17h's (via @RonJeffries) paraphrasing of Arthur C. Clarke, “Any sufficiently advanced catchphrase is indistinguishable from wisdom”, I decided to try and illustrate my statement with an example problem and how it might be dealt with.

The (combined) tweets:

Similarly constrained self-organising systems will tend to organise towards one of a few attractors (patterns), the trick is getting the constraints right & then damping, or encouraging, patterns as they emerge. Know your attractors!

Problem statement

What to do with the project manager when transitioning to scrum?

Constraints
  • There are only three roles in scrum; PO, scrum master & team
  • Team should plan it's own work for a sprint and meet daily during the sprint to take stock and make any adjustments necessary to stay on track

Project managers often have former lives, meaning that many see a transition to scrum as a natural way for them to return to the work they actually love without losing face, i.e. they become team members. Others are naturally inclined to assume the Product Owner role. Some consider themselves good candidates for scrum master, or are cajoled into it, as the scrum master role is often, erroneously, seen as equivalent to the project management role.

Whether or not a PM will be a good scrum master is a problem in the complex or chaotic domain because, even if it were possible to identify all the variables involved, they are usually fuzzily defined and (therefore) difficult to measure – e.g. scrum master competencies – which means that causality is often discernible only in retrospect, if at all (retrospective coherence).

According to the Cynefin model's probe-sense-respond approach to problems in the complex domain it should be possible to observe the scrum for one of a few known attractors (this is what differentiates action in the chaotic & complex domains – act vs probe – probe implies that you have some idea of the range of possible consequences of your actions) and amplify positive developments and/or dampen undesirable ones appropriately.

For the sake of brevity we will specify two (possibly overly?) simplified attractors and a number of patterns by which you might identify which attractor your situation is headed for, and how you might intervene.


Attractors
  • Command-&-Control (alpha male/the way things were)
  • Subsidiarity/Distributed cognition (agility; the path you want to follow)

Probe: PM transitioning to Scrum Master
  • Pattern: Scrum master as power broker, boss (Attractor – Command-&-Control)
    • Sense
      • Scrum master determines sprint scope (in committee with PO)
      • Scrum master dictates tasking
      • Scrum master assigns tasks
      • Scrum board not a source of truth
      • Scrum master unilaterally decides on action in the event of interruptions
      • Little regard for sustainable pace
      • Estimates as commitments, regular overtime
    • Respond
      • Dampen
    • How
      • Insist that PO prioritises and Team forecasts
      • Insist that scrum teams must organise their own work to be successful
      • Insist that tasks be pulled, during the sprint, and not assigned (pushed) during planning
      • Ensure that only work represented on the scrum board gets done
      • Ensure that interruptions are triaged with team input, and resultant outcomes agreed with the team
      • Ensure that variance in velocity is recognised as normal, coach the team and the PO to create stories small enough (~10 per sprint) such that (occasional) failure to fully meet the sprint forecast should not cause any serious business issue
  • Pattern: Ingrained habits and perspectives difficult to displace (Attractor – Command-&-Control)
    • Sense
      • Scrum master plays an active role in task planning
      • Daily stand-ups always convened by scrum master
      • During stand-ups, team members look to scrum master when 'reporting status'
      • Burndown updated by scrum master
      • Burndown 'flatlines' till last day or two of sprint
      • Stakeholders ask scrum master for status updates
      • Scrum master coordinates effort to be able to demo during review
      • Scrum master demonstrates new functionality during review
      • Team communicates with other teams through scrum master
    • Respond
      • Dampen
    • How
      • Scrum master leaves the room while story is being tasked
      • Schedule stand-ups for the same place & time daily, ask the scrum master to hang back until a few team members have approached the board
      • Have team members pass a token during stand-up, whomsoever has the token, has the floor. Ask team members to update the scrum board as they talk. Have scrum master stand laterally to the group.
      • Ask team members to rotate this duty, agree that the last to speak updates the burndown
      • Encourage swarming, introduce explicit WIP limits
      • Ensure scrum board is big, visible and kept current
      • Make it clear that the scrum master's role is to facilitate the team's demo, not run it
      • Introduce subject matter experts and leave the conversation, facilitate setting up communities of practice etc.
  • Pattern: Scrum master facilitating & delegating (Attractor – Distributed Cognition)
    • Sense
      • Planning meetings not dominated by scrum master
      • Retrospectives not about the scrum master
      • Impediment list ordered, current & highly visible
      • Team decides on sprint scope
      • Tasking completed by the team
      • Tasks pulled during the sprint
      • Number of open stories less than number of team members
      • Stand-up happens of its own accord, at the same time every day, in front of the scrum board
      • Trust between PO and team evident
      • Communities of practice emerging
    • Respond
      • Amplify
    • How
      • Ensure the scrum master does intervene when necessary (e.g. PO pressuring team)
      • Have scrum master change format of retrospective on occasion to prevent stasis, ensure that PO allows for (a minimum of) one improvement story per sprint
      • Ensure impediments are being cleared (list isn't just getting longer and longer)
      • Ensure the team continues to challenge itself – organise it such that that variance in velocity is recognised as normal, coach the team and the PO to create stories small enough (~10 per sprint) such that (occasional) failure to fully meet the sprint forecast should not cause any serious business issue
      • Challenge tasking outcomes; are we missing anything? etc.
      • Remain alert to power distributions within the team
      • Continue to try and minimise the number of concurrent 'open' stories
      • Have the scrum master be the first to approach the board on occasion
      • Continue actively encouraging transparency
      • Bring people together, don't get in their way

This is anything but an exhaustive list dear reader, and in a real-life situation you will probably be both dampening and amplifying on different tracks simultaneously, but I'm sure you get the picture.

Wednesday, 18 April 2012

Princely agile


Whether running an agile project or a Prince 2 project, the principles at work are the same, in both cases a project is broken up into small pieces and regular formal inspection is applied to ensure alignment. It is in the detail of the how & why of that decomposition, and the interpretation & exercise of control, that important differences can be found. Another important difference is the level of prescription, Prince 2 attempts to describe the complete set of possible project contexts and states that the method should be pared to fit. Agile methods, like scrum, tend to prescribe very little and insist that context will determine how the method or framework should be extended for any given situation.

Ironically enough the majority of so-called Prince 2 projects are PINO (prince in name only), have few or no (non-project management) products defined and never include stages (which should not be confused with phases), nor the associated formal decision moments on how to proceed, or not. This means that stopping a project often only becomes an option when original deadlines and/or budgets have been thoroughly and spectacularly violated, more often than not without the delivery of any usable product whatsoever. The PID (project initiation document) often remains live deep into the project lifecycle, sometimes being finalised only when the project draws to a close (talk about gaming the numbers!).

Product based planning is a cornerstone of Prince2 and, if applied appropriately, can provide a link to agile methodologies. Appropriate application would involve hi-level specification of products during the Initiation phase, whereafter detail is added incrementally and iteratively, just-in-time and through collaboration with the team. Minimum viable product (or feature) should be the guiding principle in designing a product breakdown structure (PBS) - not process flow like requirements document, analysis document etc.


But if scrum is a framework for project management, why would you need Prince 2 at all?

Well, scrum is indeed sparsely prescriptive and basically says nothing about (financial) governance other than that it is up to the Product Owner. In fact the role of Product Owner is one of the most problematic aspects of scrum. Scrum says that the PO should have vision & authority and be (always) available to the team thereby ensuring maximum value delivery. This is a difficult assignment, and if the stakeholder and/or user landscape is complex enough, it requires nearly superhuman abilities to execute satisfactorily. A sparse version of Prince 2 could provide a solution here. Specifically, a steeringboard could provide a workable escalation channel in priority disputes (as long as it is still employed according to the principle of management by exception, i.e. at the discretion of the PO), and the maintenance of a formal business case might provide an explicit policy for the PO to work from from day to day.

I have used Gojko Adzic's (most excellent!) Specification by Example to create a mapping between Prince 2 phases (always mandatory != stages) and agile execution:

Project Start
  • State goals (Brief/Mandate)
  • Appoint Steering Board
  • Appoint Project Manager or PO
  • Assign existing team(s) to the project



Project Initiation
  • Collaboratively determine scope (hi-level PBS e.g. in the form of Story Mapping/Initial creation of Product Backlog, consisting necessarily of primarily rough-grained stories)
  • Create business case
  • Collaboratively elucidate hi-level risks


An initiation phase could easily consist of a small number of sprints, this would ensure a much better understanding of scope & risk, and allow for using actual velocity in provisional (release) planning etc

Project Execution
  • Managing stages & stage boundaries: Each iteration is closed with the demonstration of working software, actual progress is tangible and concrete which means that the validity of the business case can be continually reviewed and assessed with confidence. The definition of formal stages to this end may be overkill.
  • Work package creation & acceptance (and associated wasteful hand-offs) are replaced by the ongoing collaborative activities of backlog grooming (“refining the specification”) & sprint planning. A project manager (if there is one) therefore has no role in activity planning.


Closing a project
  • Lessons learned – continually generated during the project (review & retrospective)
  • Product handover – not necessarily applicable if every sprint realises (potentially) shippable product
  • Review goals
Et voila – princely scrum!

Of course, there are those who suggest that management generally (Radical Management, Management 3.0) and financial governance specifically (Beyond Budgeting) would also benefit hugely from an agile approach. I agree, princely scrum (if and when contextually appropriate) should be but a step on the road to imperious agility.

Thursday, 22 March 2012

Fighting the good fight (A personal parole)


Recently, Bob Marshall (@flowchainsensei) has raised his lashing of agile and all its manifestations to a frenzy. His language has become ever more dramatic and sensationalist, culminating in a post entitled 'Agile Coaching is Evil'. To understand what the point of all this might be it is essential to read another post of his; 'On the Morality of Dissent'.

If you can peel back the layers of irony and provocation - all this talk of morals and ethics and Good and Evil – then there is certainly value to be discovered in what is being said. I continue however to disagree fundamentally with much of the detail of what Marshall is promulgating, even as I find his stated goals honourable and worthwhile. Yes, I am an agile coach.

I view the three main points of Marshall's argument in 'Agile Coaching is Evil', points that he makes repeatedly over many channels, as:

  1. Tackling partial problems leads only to more problems – systems must be addressed holistically otherwise any change will eventually be swallowed up by the system.
  2. Effectiveness being a function of mindset implies that significant change can only be realised once a radical and wholesale philosophical shift has been effected
  3. Anyone purporting to help an organisation improve its effectiveness by way of local optimisations is at best naïve, probably disingenuous and possibly plain corrupt
Let's start with the holistic systems-thinking argument. It is in fact, easily dismissed:

There is no point in addressing problems in your software development organisation because the organisation around it has not yet changed its mindset (had its mindset changed? brainwashing, hypnosis, how does this happen?), therefore any optimisation achieved within your sw development organisation will eventually be nullified or even reversed by the immovable object of the mindset of the departments adjacent to it in the value chain. Okay. Say we effect mindset shifts in product management, sw development and operations? Not enough - finance, sales, customer service etc, still have not moved so eventually the local optimisation will be swamped by the inertia of the rest of the organisation. And so on until the company has somehow instantaneously leaped the mindset chasm as a single organism. But wait. Then there is the system that is the markets in which the company operates. If said markets haven't changed their mindsets in the meantime the company we have been talking about is doomed, after all, it will eventually succumb to the mindset of the greater system in which it, sub-system, is embedded. Etc., ad infinitum.

There is much of use in systems-thinking, and its focus on people and their empowerment can be found in agile, lean and the Cynefin model (complexity). In all these other cases however there is either the implicit or explicit recognition that everything progresses in small steps. In the case of Cynefin, which specifically addresses complexity and our inability to use reductionism to solve certain problems (initially), it's interesting to note that a heuristic like 'fine-grained objects' is prevalent. Wicked problems are untangled strand by strand. Possibly also interesting to note at this juncture is the fact that much of what one might do in the complex domain in the Cynefin model is aimed at moving problems into the complicated domain. Black-box observation with the specific aim of making reductionist analysis possible!

Regarding mindset shifts as a pre-requisite for increased effectiveness:

I think that Marshall has this exactly wrong. Strangely enough this would seem to be a position he has arrived at since he first published his Marshall Model, sub-titled as it is “Dreyfus for the organisation”. The Dreyfus model of skill acquisition, as with other learning models, implies that insight (mindset) follows practice and not the other way round. In other words, Marshall's insistence that effectiveness follows mindset is in my opinion, the misattribution of cause and effect to an observable correlation. I would posit that mindset is an emergent property of practice. More correctly, practice informs mindset which in turn informs practice – a positive (meaning re-enforcing) feedback loop. There is no conflict here with the observed mindset leaps at the boundaries of the organisation types in Marshall's model. Punctuated equilibrium is not an alternative to gradual change, it is its manifestation in the real world; phase shifts are the result of cumulative change in combination with tipping points.

If Effectiveness = f(Mindeset)
         and Mindest = f(practice)
then Effectiveness = f(practice)

Rightshifting phases - copyright 2010 FallingBlossoms.com

On local optimisations and the nefariousness of their champions:

It is possible to learn without a teacher, in some ways it might even be better (conjecture; one might continue to nourish a beginner's mind more easily), but it is almost certainly the slowest way to learn and autodidacts are often hampered by strategic weak spots in their conceptual armoury. There are of course always bad teachers, in every domain.

In my role as coach, I pursue small modifications in local practice and understanding, while keeping an eye on the bigger picture. Does this make me naïve, disingenuous or corrupt? I can't be accused of naivete precisely because I realise that change, if achieved at all, happens in small steps. Because I communicate exactly this to (prospective) clients, and always start any discussion with an enquiry as to why agile, I am not disingenuous. If my only motivation were my pay cheque I would be corrupt. I am however motivated primarily by the conviction that work for most people is unnecessarily miserable, a drudgery to be survived rather than a fulfilling and rewarding part of life. I feel that the agile manifesto can help and that it is as relevant today as it was ten years ago. The only thing required to make it universally applicable is to replace 'working software' with 'concrete product' (or some such).

I shall continue to try and execute workplace coaching transparently, on the basis of high bandwidth communication, and regularly vetted by concrete results, as a force for good in the world.

Tuesday, 14 February 2012

Fractals at the office


I have been struggling with the idea for this post since LKBE11 in October of last year. For most of that period, suffering as I was from a bulging disc in my lower back, I was on large doses of morphine and I attributed my lack of progress to my induced state of mind. The one post I did complete in the same period was meandering and maudlin, and I took that as proof that the problem was the author, not his subject matter.

Now, clear-headed for almost a fortnight, I have only succeeded, despite concerted effort and a sense of urgency (I wanted to post prior to CALM Alpha), in bloating my notes. I've had to accept that the basic problem is that I do not in fact know what it is that I want to say. That is, as long as I do not try to examine my thoughts directly, I 'know' intuitively what it is that I want to express but, as soon as I try to look my subject in the eye, examine it in detail so to speak, it seems to shimmer & fade and dissolve into a million tiny pieces. Each fragment may be open to investigation but it seems that I can only grasp the whole obliquely.

I have played with a number of titles such as “The magic of feedback; the roux to your secret sauce”, “The key to Emergence (Feedback)”, “On Fractals, Feedback and Emergence (Why IT is where it's at)”, “Connectedness; Complexity simplified” and so on. To no avail.

So I have decided to proceed as follows: I will revisit LKBE11 and the topics touched there that are close to my heart, propose some auxiliary reading - inspired by the reading list for Calm Alpha - and wrap up with a brief deliberation (and an outlandish extrapolation) on an emergent order that some feel is on its way, if it isn't in fact already nascent. In doing so I hope to give you, dear reader, some idea of why I think IT is such an exciting field to work in at the moment.

Probability

At LKBE11 Don Reinersten & Alan Shalloway separately made a case against Deming's 95% (as related in an earlier post) while John Seddon wound the conference up with a stinging attack on the idea that individuals could win against the system. In fact this is a (useful) false dichotomy.

Stating that the probability of a person failing to change a system approaches 1, when he or she is a constituent of that system, would seem to preclude any individual successfully effecting change in any system. But we now know that small changes in initial conditions (of any system incorporating recursive feedback) can lead to large scale differences in output over time; the (by now slightly infamous because so widely misunderstood/frequently overstated) butterfly effect.

We humans are not good at probability. The Buddha (karma) and Jesus (Do unto others..., Live by the sword, die by the sword...) knew that the system (society in their case) was a function of the individuals composing it and their interactions. I'm pretty sure that they themselves also understood that their preaching was fundamentally flawed. Doing good acts may well increase the probability of meeting good acts but it's not a direct relationship (certainly not in the asymmetrical power distributions of old). Living by the sword most definitely increases the chances of dying violently, and yet there's many a warrior has passed away peacefully in their sleep.

Both Christianity and Buddhism dealt with this problem by introducing a non-falsifiable reckoning. If a Christian lived a good life they would see paradise in the afterlife, if a Buddhist lived a less than exemplary life he or she would be punished by dint of reincarnation (as a lower form). Don't blame the ancients though, probability continues to trouble us - see for instance the Copenhagen interpretation of Quantum Mechanics (as parodied by Schrodinger's famous thought experiment).

I have found Popper's “Quantum Theory and the Schism in Physics” and, more recently, Nassim Nicholas Taleb's “Fooled by Randomness” to be very helpful in trying to avoid probability pitfalls in my thinking.

And back to LKBE11. Despite the rhetorical enmity, the three speakers mentioned proposed similar methods for improving systems – the way to create an effective and humane system is to give those governed by it the power to adjust same according to their (quantified) experiences working in it. What they might have agreed on was that it was in fact all about the feedback...

Feedback

I was first introduced to the power of feedback, self-similarity (fractals) and all that wonderful stuff by James Gleik's seminal “Chaos”. In the days and weeks after LKBE11 I realised that the principles of the various agile methodologies and lean, and the basic practices they imply, represent in fact a fractal! Delivering value from the start; expand incrementally, refine iteratively, create a trusting/trusted environment, seek out and incorporate feedback early and often – these edicts apply equally well at all levels whether you are writing software, coaching or setting up a new business venture. They are loosely worded, ambiguous even, such that they must be adapted to any given concrete context or scale; no two “instances” of a fractal pattern are the same

And it gets more exciting, for instance, TDD is in many ways a fractal instance of the agile principles; hypothesise, test, reflect, repeat (or OODA, PDCA, do+ inspect&adapt, whatever your flavour or context). Further, Kent Beck's 4 simple design rules are:

  1. Run all the tests (create a trusting/trusted environment)
  2. Contain no duplicate code (expand incrementally)
  3. Express all the ideas the author wants to express (seek out and incorporate feedback early and often)
  4. Minimize classes and methods (refine iteratively)

So, if, for instance, a team is working scrum + lean, with XP inside, guided by A-TDD, self-similar patterns can be observed throughout the system. Multiple levels of fast feedback are then built in, allowing magic to happen, through the emergence of strange loops. Strange Loops? I only began to truly understood the implications of chaos theory, fractals etc. through reading Douglas Hofstadter's “Godel, Escher, Bach; An eternal golden braid”. To do a whopping intellectual feat absolutely no justice I will summarize it by saying that Hofstadter makes the case in this book for emergence as a function of feedback.

Emergence, Evolutionary Change

At LKBE11 I was introduced to the Marshall Model. In his original paper, Marshall states that “The basic premise of Rightshifting is that organisations can improve their effectiveness incrementally (and with little turbulence / disruption), until such time as they approach a transition zone.” but also “At these transition zones, major upheaval – in the form of a shift of mindset – is required to proceed further to the right i.e. to continue to improve the effectiveness of the organisation.



Personally, I suspect that this major upheaval is a symptom of the phase transition as much as an agent thereof. Things proceed incrementally or they do not. Think of heating water through its various physical states, from liquid to solid to gas. The change applied is the addition of heat. Heat may be applied constantly but the behaviour of the system varies. It displays punctuated equilibrium, ice remains ice even as its temperature creeps upwards, as it approaches 0 C strange things start to happen, some liquid water is produced but the rise in temperature seems to stall even as the heat applied remains constant. This is called latency (heat supplied goes into loosening bonds, in this example freeing molecules from their crystal straitjacket instead of raising temperature) and it occurs at all phase transitions. Now, there is increased turbulence too, the newly freed water molecules in our example are sliding around banging into bonds, imparting energy and amplifying the instability of the remaining crystal. So, even though the system displays major disruption and or 'sudden' state changes (large shifts), and allowing for significant qualitative difference on either side of a transition zone (liquid/gas, synergistic/chaordic mindset), it remains so that the change process (heat supply, conscious adaptation of practice) evolves step by step.

For a truly enlightening discussion on (biological) evolution by increment, and much more, see Daniel Dennett's “Darwin's Dangerous Idea” and his “skyhooks & cranes” analogy. Further understanding may be gleaned form John D. Barrow's “Impossibility” which is a delightfully accessible book on limits, tipping points and so on.

Another concept that I was introduced to at LKBE11 which struck me as oddly familiar was Real Options. I was sure I had come across it before. And I had. The central argument of Dennett's (loftily titled) “Consciousness Explained”, is that mind is an emergent property of the brain. A model for consciousness is proposed which boils down to the self as “narrative centre of gravity”; consciousness as an assemblage of mechanistic tricks including a “multiple drafts” model for action. This has largely been borne out by neuroscience since with one important caveat – we do not apply “best fit” when choosing from multiple drafts but “first fit”. For a less speculative discussion on the mechanics of mind, see the excellent and more recent “We are our Brains” by Dick Swaab.

Complexity theory

Dave Snowden also spoke at LKBE11. Cynefin and the sense-making model were an exotic beast to me, angry socialist Celts with a sense of humour less so as it happens. I did not understand everything, and am still quite vague on practical detail even having done pretty much all my reading homework for CALM Alpha, but I was immediately sold on the general framework. I undertook to re-read “Frontiers of Complexity” by Peter Coveney & Roger Highfield but haven't gotten round to it yet. What stuck with me from that book was the idea that complexity at one scale often yields to simplicity at another and vice versa. It is possible to know something about attractors, to recognise patterns, but not necessarily when or where they will arise. On the other hand, setting simple boundaries on a system with a sufficiently high number of agents can gave rise to complex patterns, emergent properties. Snowden cites the example of a flock of birds (simple rules: fly to the centre of the flock, match speed, avoid collision) in this instance saying that you can be sure they will avoid an oncoming mountain peak, just not whether they will go past it on the left or the right. For a spectacular example of flocking in action see the following video of a starling murmuration.

Elsewhere Snowden talks informatively and entertainingly about order & chaos since antiquity, which got me thinking.

This idea of patterns which arise again and again also surfaces over and over throughout the history of human thought. From the Buddha (reincarnation) to French folklore (plus ça change, plus c’est la même chose) and beyond to Nietzsche’s “eternal recurrence” and Camus' search for meaning in the Myth of Sisyphus, humanity has seen this tendency to (almost)repetition as something negative, fateful, at the very least something to be faced down, overcome. Should we despair? According to Snowden there's no need; with the right tool set, the beast can be tamed! I look forward to learning more.

To conclude, at the risk of indulging my apophenia: if mind is an emergent property of the brain with its fifty to a hundred billion neurons and their trillion connections, constrained locally by a relatively small number of variables (potential barriers, neurotransmitters), has humanity not been building its superbrain(s) since the advent of language? Or at least since agriculture was first practised? Every advance in communications since, from domesticating the horse to the printing press to the telegraph, and on to the internet, has increased our interconnectedness. Our ability to share and exchange narrative. The internet may as yet have a relatively small number of physical nodes and display only loose connectedness but phenomena like Facebook and Twitter are adding another dimension.

If you were to view users as equivalent to neurons and the internet 'merely' as infrastructure, then that one facet of the human super brain alone already has 2 billion neurons... Supra-identities like nation, tribe or corporation (that may pre-date internet) could get stronger and display more cohesion with ever more internet capacity and connectedness. I wouldn't go as far as those who talk of Gaia, or The Technium, or The Singularity. I'm not suggesting a global consciousness. For one individual human mind the self is already a much trickier idea than might appear at first glance. I'm thinking more in terms of a fragmented and multidimensional space where initially rough-hewn, badly bound and shifting personalities (consciousness as an extremely loose narrative centre of gravity) interact. But even at that scale (decidely smaller than global) some problems already seem a lot less of an issue. Inter galactic travel for example; if a consciousness can expect to exist coherently for centuries what's a few light years' travel between friends?