alacrity in action
| Tags: ,

There appear to be two opposing models of organisational change in the wild. The first one is often referred to as “revolutionary change”. The other may sometimes be called “evolutionary change”. For example I have come across some suggestions in the community that Scrum introduces a revolutionary change while Kanban promotes more of a slow and steady change. (Sorry, I didn’t mean to wake any demons up, really!)

When people mention revolution I have something like this picture in my head.
change-revolution

When faced with such an abrupt transition many instinctively feel more comfortable with an evolutionary approach that you might represent with a drawing like this:
change-evolution

In my experience the revolution ends up being so disruptive that the system eventually comes back to the starting point (which often was something rather chaotic or at best analytic) or is sustained only in a small island. The evolutionary approach tends to end up as a series of local optimisations. There are some able individuals who manage to create pockets of change but the reliance on that talent means that change is temporary. This is what it might look like in terms of the previous sketches – lots of small improvements that end up dragging everything down eventually.
change-actual

Picking from the complexity science and the expression of its understanding in the Lean methodologies we should probably stop seeing the two models as opposing but rather as complementing each other. Lean refers to this as kaizen (the continuous improvement) and kaikaku (the fundamental shifts of the system). In terms of the complexity thinking we may be traveling on the landscape of fitness and make small improvents around local optima but we require large leap to find ourselves in a better place (or worse!).

Put together you may expect something like this:
change-realistic

And if it looks familiar that’s probably because you too have been reading Jerry Weinberg, Virginia Satir or have met people who have.

The most important lesson for me is that we need to balance revolutionary changes with small steady progress and that we must anticipate decreased performance before a step change can happen. The challenge, of course, remains as to when each side of the change coin is more appropriate at any given point in time.

Disclaimer: These graphs are completely unscientific hence there are no scales, they are just rough sketches to help make the point.


| Tags: , ,

It appears to be the height of the political parties conference season here in the UK. It means politicians get to make many announcements about their policy choices. Now imagine one of the political parties decided to announce that during the next parliament they will work to increase the average speed of cars on the roads. In principle you can see the benefits of decreased travel time and thus earlier arrival at your destination. In practice however I suspect you would quickly discard such policy as not being sensible. You most likely understand the relationship between speed, safety, road capacity, vehicles’ capabilities, traffic, congestion, etc. We tend to understand traffic because it’s tangible and we experience it either actively or passively almost every day.

When it comes to software development however even practical experience doesn’t always create the same level of understanding. Writing software is not tangible – it’s just “bits and bytes on disc” – and hence it’s much more difficult to obtain meaningful feedback which is essential to developing a correct mental model.

Perhaps that’s one of the reasons why organisations adopting Agile jump on the bandwagon of “increasing speed of software delivery”. It makes sense to want to deliver working code more quickly and with the initial introduction of Scrum or another agile approach a step change is often experienced. However, just like increasing speed on the roads, on it’s own an understandably futile effort, so it appears to me is the common focus on lowering the cycle time.

My point here is not to draw any direct parallels between driving and building software though I hope it serves as a useful illustration. I would like to emphasise that a holistic approach which includes the understanding of all the elements involved and their interactions is essential to providing a basis for continuous improvement.

Now, a party which declares to commit to improving the road infrastructure makes far more sense in my mind. So where would you like to see improvements focused for software development?