Archive

Monthly Archives: July 2010

Transcript of Email to @papachrismatts Explaining #Rightshifting

July 31, 2010
Archive, Ex-Amplify.com, Rightshifting, Snippet
Leave a comment

Transcript of Email to @papachrismatts Explaining #Rightshifting

[From the Archive: Originally posted at Amplify.com Jul 31, 2010]

Having kindly taken the time to look into the Rightshifting ideas I have been championing for some time, Chris Matts recently emailed me with his comments:

“From what I’ve read, Rightshifting seems to be a call to arms to radically shift improvement of organisations. What I’ve not discovered is the means [Rightshifting proposes] to achieve this.”

He thought my reply warranted wider publication, so I’ve taken the opportunity to post that reply here:

You’re absolutely right, in that the Rightshifting campaign is a call to arms to radically shift improvement of organisations (and specifically, their *effectiveness*). We have expressly avoided nailing ourselves to any particular means, for a number of reasons (see below).

I firmly believe that the first and biggest hurdle to improved effectiveness is the ignorance of the vast majority of decisions-makers, software development services purchasers, etc., as to how *in*effective their software development organisation presently is, and just how much *more* effective it could be. The question of “how” although relevant, only enters the equation once people have determined that they’re no longer satisfied with their status quo.

And of course, as you and I know, the “how” (or rather, many different “how”s) has been demonstrated in practice in enough places that “how” is not so much of a problem these days.

So, in a nutshell, Rightshifting is about education. Specifically, it’s about educating people as to what’s *possible* (and realistically achievable).

Note: Whereas the top line for Rightshifting is about education and thence to improved organisational effectiveness, the bottom line for me has ALWAYS been about creating more humane, fulfilling work and workplaces.

BTW Grant Rule – my comrade-in-arms in Rightshifting – has a marginally different take on the bottom line (concerning e.g. social responsibility, the Five Capitals, and sustainability in the macro-economic sense).

If you’ve not yet seen it, the article I feel that best speaks to the above is my “All Executives Are Unethical” paper, available here: http://fallingblossoms.com/opinion/content?id=1001 (pdf).

Some reasons for remaining silent on means
================================

  1. The idea of Rightshifting as an awareness campaign comes, not least, from Sir John Whitmore’s work on coaching. Specifically, the A.R.C. acronym: Awareness, Responsibility, Commitment. i.e. People won’t commit to take action about something before they have come to feel responsible for the issue, and that feeling of responsibility can only happen once they have become aware that there is an issue needing attention.
  2. I believe means are utterly contingent on context (Genshi Genbutsu – at least for Analytic-> Synergistic transitions and further to the right, c.f. the Ha and Ri stages in “Shu Ha Ri”, or beyond stages 1 and 2 in the Dreyfus Model) and would be loath to see the emergence and consolidation of Rightshifting “best practices”.
  3. We want to enrol as many supporters into the Rightshifting campaign as possible. Not least because we have a whole industry to educate. Leaving the means open to individual suppliers allows them to compete on delivering the most effective means they can find into the market, whilst cooperating on the basic education and awareness campaign (coopetition being a watchword of Chaordic organisations, btw, c.f. Dee Hock).
  4. I have always felt that people buy in to change better, when they feel ownership of the change. Allowing (encouraging) folks to discover and implement their own means will, I believe, contribute positively to feelings of ownership, and thus to the sustainability of the necessary changes.
  5. On a personal note, Falling Blossoms* was founded on the notion of emptiness as a positive dynamic. I believe that emptiness (as in empty space) motivates people to fill in the blanks for themselves. Lack of express means for Rightshifting is my attempt to implement this concept in the Rightshifting equation.

*One day, in a mood of sublime emptiness, Subhuti was resting underneath a tree when flowers began to fall about him.
“We are praising you for your discourse on emptiness,” the gods whispered to Subhuti.
“But I have not spoken of emptiness,” replied Subhuti.
“You have not spoken of emptiness, we have not heard emptiness,” responded the gods.
“This is the true emptiness.”
The blossoms showered upon Subhuti as rain.

Why Agile is No More (or Less) Than a Skunkworks

July 27, 2010
Agile, Archive, Ex-Amplify.com
1 Comment

Why Agile is No More (or Less) Than a Skunkworks

[From the Archive: Originally posted at Amplify.com Jul 27, 2010]


Agile as skunkworks. This simile struck me quite forcefully the other day, and I have already tweeted to this effect. But the more my subconscious works on it, the more the analogy seems apt. (My apologies if anyone else has already drawn these parallels.)

For those unfamiliar with the term, “skunkworks” is widely used in business, engineering, and technical fields to describe a group within an organisation given a high degree of autonomy and unhampered by bureaucracy, tasked with working on critical, advanced or secret projects.

The correspondences with Agile, and in particular with those Agile Pilot projects so beloved of organisations dipping their toes in agile waters, seem manifest:

  • Agile projects generally receive dispensations to forego “normal” standards of documentation, project reporting, etc.
  • Traditional processes – aka ways of working – cease to be mandatory .
  • Agile projects often get to work on something critical to the business.
  • Agile projects can freely(?) adopt a different world-view than their parent organisations with respect to hiring practices, treatment of staff, incentives, working hours, dress code, job titles, roles & responsibility, and so on.
  • Parent organisations look-on in bewilderment, and sometimes outrage or fright, at the corners that the agile project teams seem to cut, and maybe at their general alien demeanour, too.

So, if you accept these parallels, what’s the relevance of the analogy? I believe the relevance lies in the history of skunkworks. Even though some have produced amazing products, like the U-2 spyplane


and the later SR-71 Blackbird,

few skunkworks have succeeded in exporting their highly-effective ways of working back into their corporate host organisations.

Agile exponents by and large still cling to the forlorn hope that Agile will go mainstream, leach into traditional organisation by osmosis – and the benefits of the Agile approach will be realised by all.

I use the phrase “forlorn hope” advisedly, because if skunkworks have been unable to shift the mindsets of their “host” organisations for fifty years and more, why should we expect Agile to be any different in this regard?

As ever, your comments and conversations will be most welcome.

– Bob

Just Burning Toast and Scraping It

July 26, 2010
Archive, Ex-Amplify.com, Organisational effectiveness, Snippet, Software development
Leave a comment

Just Burning Toast and Scraping It

[From the Archive: Originally posted at Amplify.com Jul 26, 2010]

Of course, Deming was talking about manufacturing, but I suggest that his observations also hold for Product Development (including software development).

Do go read Glyn’s whole post [Update: full post now only available via the Wayback machine] for more context.

Amplify’d from www.glynlumley.co.uk
“Just burning toast and scraping it”

In one of his 14 Points for Management, Deming called for mass inspection to cease. Prof. Henry Neave comments that this is not to suggest that we eradicate all inspection. He writes, ‘There is the world of difference between, on the one hand, dependence on inspection as an attempt to provide the customer with something that he won’t complain about and, on the other, the use of inspection to provide guidance toward improvement of a stable process as well as to pick up the occasional special cause that creeps unannounced into that otherwise stable system’. In an interview with Mary Walton (June 1985), Deming stressed that, ‘Quality comes not from inspection but from improvement of the process’. In other words, we should seek to build quality in rather than inspect it out.

Read more at www.glynlumley.co.uk

– Bob

Agile: Doing the Wrong Thing Righter

July 19, 2010
Agile, Archive, Ex-Amplify.com, Snippet, Software development
2 Comments

Agile: Doing the Wrong Thing Righter

[From the Archive: Originally posted at Amplify.com Jul 19, 2010]

Introduction

Undoubtedly we’ve come a long way since Snowbird (http://martinfowler.com/articles/agileStory.html, http://agilemanifesto.org/history.html). And Agile seeds – when planted in fertile ground, at least – can grow successful, productive teams. Even hyper-productive teams (http://gojko.net/2010/04/20/jeff-sutherland-how-to-make-your-team-hyperproductive/).

Several conference announcements recently have trailed John Seddon’s upcoming polemic against Agile: “doing the wrong thing, faster”. Neither knowing exactly what John’s going to say on the subject, nor wishing to steal his thunder, I’m writing this piece to present my own views on why Agile has, more often that not, been doing the wrong thing righter.

One thing John and I are likely to share, though, is a Systems Thinking perspective on the subject. Hence the notion of Agile as “the wrong thing”.

Systems Thinking

Systems Thinking, in a nutshell, encourages us to take a look at wholes, not parts, and judge the worth of a system on its end-to-end effectiveness, rather than on how well individual parts operate (aka their efficiencies).

We can choose to regard any business as a system, with software development being just one part of such systems. No matter how well-run the software development team or department, the system within which it exists can still be dysfunctional and perform poorly. The introduction of Agile to a development group often only helps to enhance that one (relatively small) part of the whole system.

Some people note that Agile, and Scrum in particular, drives the discovery of these dysfunctional system behaviours e.g. throughout a business. And while I have seen that happen, few businesses have the will or insight to act on the messages coming from the agile teams. NB @dpjoyce has just tweeted about the “Red Pill / Blue Pill moment” (http://twitter.com/dpjoyce/status/18901380780).

Cognitive Dissonance

This highlighting of dysfunctional behaviours often leads, in turn, to significantly increased friction between the Agile folks and the rest of the folks they work with. Ultimately, the friction can become sufficiently uncomfortable to threaten the Agile initiative itself, improved software development outcomes notwithstanding.

I could write more (much more) on this topic, but – not least because this post was prompted by various folks wanting to talk about this question – I’m going to park my keyboard now and invite you to contribute (below)… 🙂

Amplify’d from twitter.com
flowchainsensei I’d still like to talk about why #Agile is “doing the wrong thing, faster” and why the Agile community fails on the “big picture”. Amplify?Read more at twitter.com
– Bob