Fixation
Fixation
Summary
Many folks ask me:
“If significant improvement in business effectiveness requires intervention on a system-wide basis (across the whole organisation), what am *I* supposed to do, stuck in this small box in one corner of the company?
Which is a very fair question. And one to which I am obliged to answer:
“Find some like-minded folks, even just one or two, broaden your perspective (don’t fixate) – and do what you can, together, for the organisation as a whole.”
Granted you’re not likely to realise the 100%, 200%, 500% bottom-line benefits that a full organisation-wide intervention can effect, but at least you’ll be doing something. And feeling better for that:
Whatever you can do, or dream you can do, begin it.
Boldness has genius, power, and magic in it!”
Aside: Not really a Goethe quotation.
Most Levers of Effective Software Development Lie Outside the Development Group
Knowledge work may have become the engine room of most modern businesses – but you don’t steer a ship from the engine room.
“If the organisation as a whole is doing the wrong things the significance of the approach used in software development is very small.”
~ recent @flowchainsensei tweet
A core problem with Agile and other such developer-led initiatives to “improve” things is that these initiatives are not connected to the levers that steer the ships of business, nor even to those levers that affect the overall performance of the development group itself.
Tunnel Vision is Not a Winning Strategy
Obsessing about code quality, the software development lifecycle (as manifest within the walls of the development group), wip, tools, testing, and the hundred and one other things that make up a developers daily routine is perfectly understandable and a natural response of the disempowered. When we feel disconnected from being able to change the things that make a real difference, most of us will hunker-down, and focus on those things to which we can make a difference. Pride in work has a long tradition and history, often conflicting with the more (apparently) prosaic concerns – like profits, revenues, market share, etc. – of the corporate elites.
What to Do
“Never doubt that a small group of committed people can change the world. Indeed, it is the only thing that ever has.”
~ Margaret Mead
Charlotte Pell recently afforded me the kind opportunity to review a pre-publication copy of Vanguard UK’s new book “Delivering Public Services That Work – Volume 2”, now published (as of 24 April 2012).
The most striking feature of this uplifting work, for me, is the numerous real-world stories of “ordinary” folks in “ordinary” organisations who have done what they could, given a limited scope and reach – and made enormous strides in improving things. Case studies like this encourage me to assert that significant improvement is possible, even when the folks involved do not have the authority or even the influence over their organisation-as-a-whole. Indeed, if the reported improvements are the result of “mere” localised interventions, then what scope for seemingly infeasible gains when tackling these issues organisation-wide? And yet wider still, given the stories’ highlighting of the enormous waste implicit in our egregiously disjoint public services?
– Bob
Think Different
One thing that stands out for me is what seems to be an inconsistency in what you say. You start with “A core problem with Agile … is that these initiatives are not connected to the levers that steer the ships of business” but then seem to contradict yourself towards the end with “…“ordinary” folks in “ordinary” organisations who have done what they could, given a limited scope and reach – and made enormous strides in improving things”.
Are the practices and techniques used in Agile software development not the effort of “ordinary folks” in “ordinary organisations” working within their own “limited scope and reach”? Can you explain this one further?
PS: I know this is a very early draft 🙂
Hi John,
My thanks for your contribution to the conversation.
You raise a very fair point, and one my most recent edit has attempted to (partly, and indirectly) address.
I’m thinking it’s a matter of context and perspective. The Vanguard case studies illustrate vividly how the folks making their (local) changes thought they had improved matters “enormously”, especially from their own quality-of-life-at-work (autonomy, mastery,purpose -> motivation) point of view. (Never to be sniffed-at, mind you). The more objectively-reported benefits (costs, service levels, customer satisfaction, etc. were (relatively) more modest, I thought.
Also, the case studies in the book highlight the value of taking an organisation-wide perspective on changing things, even if the actual changes are limited to one group, unit, or department. This blog post is (not least) about the risks of improving things locally *without* such an organisation-wide sensitivity. I commend the book to you as a means to illustrate the difference this shift can make to otherwise purely “local” interventions.
– Bob
Absolutely. In a lot of situations, it’s only the folk at the font line who can know what’s going on and what needs to change. The management job is to encourage the enthusiasts amongst them to lead on, to keep back the stifling stuff and, if it’s needed, to provide some technology (or other) help to ease the way. Driving change with technology just can’t work.
Hi Mark,
My thanks for your contribution to the conversation.
The case studies in the book do a great job or articulating the sea-change in e.g. management and staff attitudes to change that a whole-organisation perspective brings about, even when that sea-change is limited to the folks in a small area within a large organisation.
– Bob
In chemistry the slowest step in a reaction process is called the Rate Determining Step – it’s the same in any process where material/work flows. Strictly speaking, there is little point in optimising steps that are not that one critical one. However you can also find situations where the changes you make to speed up that part of the equation have a detrimental impact to the whole (such as by-products interfering with other stages in the reaction).
As always with chemistry however, the only way to be sure is to run an experiment and observe the results, make some changes and then run it again.
Same with knowledge work – understand the system, make changes, observe the impact.
I’ve read the first case study in the book mentioned, and noted that the author had since left the organisation. I would be interested to see if the successful changes that were made have remained in place, and have been built upon. i.e. have the system and organisation truly been changed by the intervention, or were there unexpected outcomes that have impacted the whole?
Paul
Hi Paul,
Thanks for joining the conversation.
I agree the question of *sustainable* change is often overlooked. It would indeed be interesting to see what had happened (in each case study) since the change initiative had “relaxed” into BAU. One aspect of Agile options that has long interested me is how long such an adoption lasts in the face of a wider organisation that has not changed its mindset. I generally see a half-life of some 9 months.
– Bob