BrainScrum

Recently some friends attended a ScrumMaster Certification class held by my friend Joseph Pelrine here in London. Considering they are all very experienced and very eXtreme/Agile (some of them were using eXtreme Programming when others were thinking “let’s try this new thing called waterfall…”) this evening at XtC I asked them if, even with their extensive Agile experience, that course had left them at least one interesting thought. They all said the self-organisation idea.

The strange thing is that I’ve always believed that this idea is common to every Agile approach but I recognise that my point of view is somehow contaminated because by nature I tend to assimilate ideas and put them together without really keeping in mind the exact original source…

By the way, the brief discussion that followed started with a phrase like “I like the idea but I’m a control freak, I cannot really leave the team in anarchy”. I don’t see self-organisation as anarchy even if I agree that different situations (and different people) need different degrees of independency.

Briefly, my view on self-organising team is this:

• the iteration is the shield that isolates the team and gives it the time and space needed to inspect and adapt
• the ScrumMaster (or whatever you call it, you can replace Scrum with every Agile approach) is the one that works hard to keep the noise out of the iteration shield
• the ScrumMaster is also responsible for making sure that the team follows Scrum - it’s more about the attitude, values and principles than strict practices and formal process. Do you remember? It’s the art of the possible

Point number 3 is where the coaching-mentoring skills matter instead of a command-and-control mentality: you do the right questions instead of imposing your answers, you help the team review what they are doing (and what they did - retrospective) in order to facilitate little steering every now and then.

I like the image of a set of little, coloured spheres in a vibrating container. If the vibration is constant they tend to find an equilibrium. If you need them to find another configuration you need to apply a little force to break the current formation and let them find a new configuration.

I see the same thing in both user stories and refactoring

User Stories (and Planning Game)

When you work on your user stories, splitting them so that they are INVEST (Independent, Negotiable, Valuable to users/customers, Estimatable, Small, Testable), your goal is to transform something that represent value for the system’s actors into something that represent value to be delivered to the customer. Splitting the stories the business system is separated into simpler compounds of utility more communicative, atomic, orthogonal and cohered (and the problem’s complexity is reduced as well). You then put all these cards on a table and compare them, remove duplicates and group similarities….. Isn’t this an emergent, self-organising configuration facilitated by little forces applied by us?

Refactoring

Our goal is to reduce the marginal complexity so that introducing a new feature/a change is cheap. We need the code to communicate clearly and in a simple way its design intentions and we need the abstractions to emerge. Abstractions are not done by construction, instead you put the behaviours (the code) on the screen, compare them, remove duplicates and group similarities….. Isn’t this an emergent, self-organising configuration facilitated by little forces applied by us?

End…?

A system in equilibrium naturally tends to resist to change and that’s why we need to apply a force (questions/retrospectives/etc for people, splitting for stories, refactoring for code), because we need to take the system at the edge of chaos to facilitate the emergence of a new, spontaneous configuration.