Sunday, March 21, 2010

Change models: Shook, Schein, Dreyfus and Constructivism

Continuing on from my opening comments in the last entry, “Why forecasts fail: simple ones are better ”...

The other article which was good in the latest MIT Sloan Management Review was John Shook’s piece on change. His change model complements my own ideas well.

Shook’s model is shown below. He sees change starting with specific practices, e.g. just-in-time inventory, and as teams improve their practices and deepen their understanding they move to more thinking for themselves.

Shooks model
I’ve written before about my Agile triangle (or maybe pyramid is a better term). In the last few months I’ve added another insight into this model. Team which start by just “doing Scrum” or “XP” and want to advance, improve their process and practices further, deepen their understanding and application, take the next step, call it what you will, well, they need to advance by moving down the triangle.

Agile traigle
You might start doing XP but over time you want to look outside XP and see what else is out there in the Agile toolkit. Deeper still is going back to Lean and picking up the Lean tools (value stream mapping, A3s, focusing on flow, etc.) And deeper still is a learning organization, a team or unit that is continually learning and changing.

While this goes some way validating my ideas its not the end of the story. Shook goes further and suggests his model parallels Edgar Schein’s writing - Schein is an MIT Management professor who has written extensively on culture and organisations.

Schein argues that organisational culture cannot be changed directly, indeed, to start with a desire culture in mind is a mistake. Better to start with the issues in hand and set about changing the cultural artefacts. Shook gives the model below (similar but inverted to the one on Wikipedia.)
Sheins model
It hadn’t dawned on me before, although heaven knows I once read plenty of Schein, that this isn’t far from my model. XP and Scrum, and other Agile methods, really start by changing the culture artefacts of an organisation.

Out go Gantt charts, in come burn-down charts.
Out go status meetings, in come stand-up meetings.
Out go moving deadlines, in come fixed iterations.
And so on.

Only later, are teams expected to reflect and modify their models - moving down the triangle/pyramid, moving from XP to Agile, to Lean, to a Learning Organization.

This also fits well with the Dreyfus model of skill acquisition which is so well liked by many in the Agile community. In this model a Master teach the pupils, when the pupils have mastered the skills they are allowed to think for themselves.

I’ve always disliked the Dreyfus model, and I believe it has failure built in. This is because the learner spends a long time looking to the teacher for the answers, they are not encouraged to find their own, indeed they are discouraged from trying anything different to accepted norm. Consequently someone may have mastered the skill they set out to, but they are no better at learning or problem solving. Faced with a new problem, or a need to deepen their understanding, and without a Master teach and ready made answer they are lost.

Maybe I over worry about this danger, as usual the truth is probably somewhere in between the two extremes. Rather than the Dreyfus model I look to the Constructivism model of learning. Under this understanding it is peoples understanding, derived from their experience which constitute learning. The teacher is not there to teach so much as to help individuals experience something different, the individuals sense making process then takes over.

Still, as I’ve said before: my interpretation Agile comes from Lean and the underlying idea of organisational learning. (Indeed, I think I wrote a book about that!)

As a result when I’m trying to make teams more Agile, I’m really trying to make them better learners, and make the organisation as a whole a better learner. While publicly we might be working down the Agile pyramid secretly I’m trying to work up.

1 comment:

  1. Hi allan,

    Not so much of a secret now you've mentioned it in your blog ;-)

    My team is definitely moving down the pyramid as you describe. We essentially started out with XP.

    Our biggest revelation of the past 6 months is that it's cheaper over the whole development practice to have developers run acceptance tests. The developer coding the feature runs the tests once on their dev boxes, a second developer runs them on their test kit and then finally run by testers at the end to make sure we haven't missed anything.

    It seems like this should be hugely inefficient, after all it's 3 people doing the same work isn't it? And those devs could be doing other features?
    It turns out though that we've implemented a kind of one piece flow whose main benefit is reducing the cycle time in the queue.

    The rest of the team don't know anything about Lean Thinking, and yet this is where we have ended up as a direct result of inspecting our process, picking a problem in it and adapting the process.


Note: only a member of this blog may post a comment.