Deming: “Cease Dependence on Inspection”

[From the Archive: Originally posted at Amplify.com Jun 29, 2009]

Deming’s view on inspections, which I share: “Cease Dependence on Inspection”.
(Caveat: He way talking about manufacturing and factory lines. Collaborative knowledge work, such as product design or software development, is a different context which will require some re-interpretation and repurposing of the fundamental concepts underpinning his words).

I also recognise that many folks may feel so uneasy in some extreme situations – for example, where life and limb are at risk – that they may still choose to require inspections (via statistical sampling, or even 100% inspection).

Aside: I’d suggest that such unease generally comes from a lack of trust in the effectiveness of the process(es) involved.

Amplify’d from curiouscat.com

From Deming’s 14 management points: “Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.” Out of the Crisis, 1982.
Prior to Deming’s ideas being adopted inspection was often used to select out the bad products. Companies would make products then sift through the resulting output removing those that were defective. If they could re-work them to be sold they would do so. Otherwise they would scrap the defective output.
Obviously this is a costly way to do business. It is much better to work on improving your processes so the output is all acceptable. Deming used to colorfully describe the old practice as “you burn the toast, I’ll scrape.”
Deming believed in improving the process, and doing so using process measures to guide improvement efforts.

In the New Economics, page 179, Deming states:

Conformance to specifications may be achieved in several ways:

1. By careful inspection, sorting the bad from the good. Dependence on inspection is hazardous and costly.
2. By work on the production process to shrink variation about the nominal value.

Obviously, option two is the preferred method. He also recognized that there are extreme situations where 100% inspection may be required (where safety may be jeopardized for example).

Read more at curiouscat.com

– Bob

Coaching and Peer-instruction More Effective Than Teaching

[From the Archive: Originally posted at Amplify.com Jan 3, 2012]

Excellent article (well worth reading the whole piece) presenting quantitative evidence that teaching / lecturing is way less effective than “coaching” and “peer- instruction”.

Taken from the domain of Physics education, but I see many parallels with e.g. Agile coaching and, yes, even Scrum Mastering (done well).

Amplify’d from www.npr.org

Mazur sees himself now as the “guide on the side” – a kind of coach, working to help students understand all the knowledge and information that they have at their fingertips. Mazur says this new role is a more important one. Read more at www.npr.org

– Bob

Clausewitz’s Concept of Friktion – Bungay’s diagram

[From the Archive: Originally posted at Amplify.com Dec 3, 2011]

The closing Keynote at Lean Kanban Central Europe 2011 (Munich) was presented by the excellent Stephen Bungay. You can see the highly informative video here [Update: sadly now only available to conference attendees on request] and read more about Stephen Bungay via his website and on Wikipedia.

As there is no HD version of the video (that I can find), the chart in the video is a little difficult to read. I have therefore prepared a version of the chart (see below), which he uses to illustrate Carl Clausewitz’s concept of “Friktion” i.e. the “resistant medium” in which War (and Business) has to operate.

Carl Philipp Gottfried von Clausewitz (1781-1831)

The Chart

(Open in new window to see at full size)

HTH

I am also struck by the fact that throughout history, Man has repeatedly found the answers to the problems of “modern (i.e. twentieth-century) management”, yet these problems still persist almost universally.

– Bob

 

Software Kitchen Nightmares

[From the Archive: Originally posted at Amplify.com Nov 20, 2011]

Explaining FlowChain Via A Restaurant Analogy

I love Gordon Ramsay’s TV series “Kitchen Nightmares” (including the USA version).

As well as being entertaining, I share Gordon’s obvious passion for helping folks improve their businesses (in my case, technology-related businesses – not restaurants!). The series illustrate in an almost visceral way the key issues facing any business, and a simple means to address these issues.

He follows much the same strategy in each encounter, a strategy which guides the changes he proposes to owners:

• Understand what the customers actually want in the way of food, prices, dining experience, etc..
• Change the restaurant’s offerings to more closely match that demand.
• Get the management and workers to care about what they’re doing again (intrinsic motivation).
• Sort out the kitchen so it has the capacity and capability to meet the expected increase in demand.

It’s the latter point which I’m going to use, as an analogy, to illustrate FlowChain and how the FlowChain perspective can benefit technology businesses. (In this post, for the sake of clarity, I’ll talk exclusively about the software development aspects of producing or enhancing a technology-based product or service).

Things In Common

In a restaurant kitchen, orders from customers arrive at the pass.

Newly-arriving orders are inserted into a running backlog, according to some prioritisation scheme, as the whole kitchen, synchronised by e.g. the Head Chef, works to prepare each element of the highest-priority orders. As elements become ready, they arrive at the pass, where they are assembled and checked before being dispatched, in small batches (one course for one table at a time), to front-of-house and the waiting diners.

In a FlowChain context, orders (in the guise of, say, new user stories) enter the software development department (or maybe it’s called the IT department – that’s an issue for another day).

Newly-arriving orders are inserted into a running backlog, according to some prioritisation scheme, as the whole department works to prepare each element of the highest-priority orders. As elements become ready (with Continuous Integration we can skip a separate assembly step, and with e.g. TDD/BDD we can skip much or all of the checking) the orders are dispatched to the waiting customers. (With Continuous Deployment we can skip much of the dispatch step, too).

So, the essential aspects which these two scenarios (kitchen, software development department) have in common are:

• Incoming orders arrive with unpredictable variation in e.g. size, timing, priority and requested customisations.
• There’s a constantly-changing, enterprise-wide backlog of pending orders.
• Workers assign themselves to the highest-priority items, depending on their skills.
• Customers do not want, nor expect, their entire meal to arrive at once.
• Customers do expect to have a single course for the whole table arrive at the same time.
• Continuous operation, day-in, day-out.

Benefits

The benefits of this approach include:

• Elimination of overheads such as project management (no projects!) and programme management (no brawls over resources for competing projects).
• Elimination of project set-up and tear-down overhead (no project teams!).
• Reduction in delays due to e.g. elimination of handovers and sequential processing.
• Much improved flow (of valuable user-stories to customers). Increased flexibility in responding to customer needs.
• Improved collaboration between workers, and between front-of- house and the delivery unit.
• Provides opportunities for learning and, especially, multi-skilling, in the workforce.
• Requires leadership (although not necessarily ONE leader), not management.

Of course, as we described in Gordon’s strategy, building a successful business as a whole means we have simultaneously to attend to a range of issues, not just simply ensure that the “delivery” part of the organisation has sufficient capability to play its part in the new scheme of things.

And please accept that this is ONLY an analogy, to help explain FlowChain a little better. A software development department is not a kitchen, and the issues – whilst similar in some aspects – are sufficiently different that I for one would not want to run a software shop in the same way as a restaurant kitchen.

– Bob

The Nature of Time-boxing

[From the Archive: Originally posted at Amplify.com Nov 18, 2011]

Time-boxing seems like such a simple concept. A team – with their Product Owner – gives themselves a fixed period of time, say two weeks, to:

• figure out what’s the most important things to next add to their working product
• build those things
• integrate them into the working product

(Note: I’m not going to digress about the need for *working* software in this particular post. Maybe another day).

But there are some hidden dynamics at play, underneath this simple- looking veneer.

This post is about just one of those dynamics, namely, the interplay of time-boxing and commitment.

Many Scrum practitioners (and their customers even more so) have come to believe that if a Scrum Team fails to completely deliver ALL the items it has planned for a given time-box (Sprint), then it has “failed” in some way. Failed, indeed, to “meet it commitments”.

This viewpoint leads to increasingly dysfunctional behaviours, as describe recently by @yuvalyert (Yuval Yeret) in this blog post.

For all the successful development projects in which I have been involved, we have always treated time-boxing as a means to curtail overruns of effort, especially with respect to individual items (deliverables). That is to say, during Sprint Planning the folks involved in working on a given Sprint deliverable (for example, a User Story) agree amongst themselves – and with the rest of the team – on how long they will spend on that item (Note: NOT how long they expect to take to bring that item to some kind of completion, or state-of-readiness. I.E NOT an “estimate”). So, the Team commits to spending some finite amount of time on the item, NOT to completing it. We have found this distinction to be crucial.

We also apply this same perspective to the Sprint as a whole. We commit to spending two weeks (no more, no less) of our collective best efforts on working towards the Sprint Goal. We do NOT commit to delivering specific things in a fully-finished state. (Aside: It’s kind of important that everyone – Team, Product Owner, stakeholders, management, customers, etc. – all understand this clearly, with regular reminders).

Of course, if during the Sprint it begins to look like some items will not be completed in their allotted (mini) time-boxes, then the Team, the Product Owner (and maybe other stakeholders too) can have a discussion about what to do. This, for me, is one key aspect of being Agile (correcting course as necessary, even whilst “in flight”).

This does mean that some Sprints will deliver less (integrate less functionality into the working product) than expected. And some will deliver more than expected. Swings and roundabouts :).

This is the nature of software development.

– Bob

PERMA and the Positive Business

[From the Archive: Originally posted at Amplify.com Nov 5, 2011]

In his great, recent book “Flourish“, Prof Martin Seligman introduces the idea of “Positive Business” – an idea aimed at “broadening what MBAs care about” – i.e. beyond mere money, towards the five different pursuits which he posits comprehensively constitutes “well-being” (and for which he uses the acronym PERMA):

• Positive emotion
• Engagement
• positive Relationships
• Meaning
• positive Accomplishment

Upon reading this, it immediately struck a chord with me, surfacing some subconscious thoughts I had been accumulating whilst reading his book up to that point. For me, Rightshifting is inseparable from the idea of creating workplaces where well-being (of employees, for sure, but also of all other stakeholders) is at the core of the work experience. As Prof Seligman states:

“If you want well-being, you will not get it if you care only about accomplishment [e.g. profit]. If we want our [Management] students to flourish, we must teach that the positive business and the individuals therein must cultivate meaning, engagement, positive emotion, and positive relations – as well as tending to profit.”

Aside: John Kay in his book “Obliquity” goes even further, positing that accomplishment, such as profit, desirable as it is, often best comes about obliquely – as a fortuitous by-product of the search for other things.

Prof. Seligman goes on to write (paraphrasing): “Even if rich profits and growth are not forthcoming, individual and collective well-being may well remain stable, or even rise, on balance.”

Quoting Friedrich Nietzche’s concept of “The Child Reborn” he then asks:

“To what can we say ‘yes’? What can every human being affirm? We can all say ‘yes’ to more positive emotion; we can all say ‘yes’ to more engagement; we can all say ‘yes’ to better relationships; we can all say ‘yes’ to more meaning in life and we can all say ‘yes’ to more positive accomplishments. In short, we can all say ‘yes’ to more well- being.”

Amen to that.

+1 for Flourishing.

+1 for the Positive Business.

– Bob

A Round-up of European Lean/Agile Conferences

 [From the Archive: Originally posted at Amplify.com Nov 3, 2011]

I’ve been speaking at a bunch of Lean/Agile conferences across Europe recently (e.g. October 2011). Some of the organisers have asked me for my feedback (I applaud folks who listen to their customers and want to improve). So here’s my feedback on each of the events I attended, in the “Perfection Game” format:

Lean/Kanban Benelux

What I liked

• The venue
• That everyone was in the same hotel
• The production quality of the videos
• The audio and projection facilities for the session speakers
• The Hotel lounge
• Belgian beer and food
• The camaraderie common to all the attendees
• Meeting many Twitter friends in meatspace
• The roster of great speakers

Overall score out of ten: 8

What would have made me give a ’10’ score

• Reliable Hotel Wifi
  • As a visitor from another country wishing to avoid excessive mobile roaming charges, and not wanting the cost and hassle of buying and swapping-in a local SIM, wifi is the best solution for me to stay in contact with home, and MORE IMPORTANTLY to stay in contact with other conference folks to arrange e.g. social events during our stay.
• Reliable Conference WiFi
  • Ditto the above, plus live tweeting
• Hotel and conference venue closer together (within a short walking distance)
• Better air-conditioning in the conference venue
  • I guess we could not have anticipated a heat wave in October, but the venue was often way too hot for me.
• Better Hotel management
  • Although the hotel decor, bar service, food, etc was great, the Radisson Astrid seemed poorly organised and run overall (i.e. great staff were defeated by a dysfunctional system).
• Absence of personal attacks from some of the speakers on the work and – more perniciously, on the integrity – of some of their fellow speakers. I am speaking in particular of Dave Snowdon as the major offender (literally).
  • Maybe some formal “polite request” of speakers to refrain from this kind of thing might help?
• Less confusion and uncertainty over speakers’ arrangements, expenses.
• Real-time display of the conference (or even better, session-specific) tweet streams, on stage (big screen), during all sessions.

Magrails Manchester

What I liked

• The organisers: Lovely people who went way beyond the extra mile to make me feel welcome and valued.
• The venue (in general, but not the room layout – see below)
• That all sessions were videoed
• That there was just a single session track – great!
• The Magrails website – great job, guys!
• The audio and projection facilities for the session speakers (barring the audio glitches)
• Attention to detail, especially the handouts / conference bag
• Tee-shirt (quality!)
• The audience. A very attentive, inquisitive and widely knowledgeable bunch

Overall score out of ten: 7.5

What would have made me give a ’10’ score

• Much more attention to the social dimension
  • Example: Late-night chatting in the hotel bar (didn’t happen)
  • Example: Over-breakfast chatting in the hotel (happened marginally – thanks Jason!)
  • Example: Evening events held somewhere quiet, calm and cosy, to facilitate conversations
• A better layout for the session room (long and thin made it difficult to engage with the speaker in the far distance)
  • Personally, as a “speaker” who likes to get close up and personal (engaged) with an audience, I would have like it to be “in the round”.
• A panel session as part of the day’s schedule (or maybe an early-evening thing)
• Everyone in the same hotel
• Reliable Hotel Wifi
  • As I could not get a 3G signal in the hotel, I may as well have been a visitor from another country. Under such circumstances Wifi is the best solution for me to stay in contact with home, and MORE IMPORTANTLY to stay in contact with other conference folks to arrange e.g. social events during our stay.
• Reliable Conference WiFi
  • Ditto the above, plus live tweeting
• Hotel and conference venue closer together (within a short walking distance)
• Better Hotel management
  • Although the hotel decor, bar service, food, etc was OK (but not great), the Radisson (Park Inn Hotel) seemed poorly organised and run overall (i.e. nice staff were defeated by a dysfunctional system).
• Real-time display of the conference tweet streams, on stage, during all sessions
• Not being barred from charging things to my hotel bill just because the Hotel had lost the billing details.
• A reliable taxi firm
• More Buzz during the second (workshop) day.
  • OK, it was a Saturday, and I guess some folks had hangovers from the previous night, but the buzz of the previous day seemed conspicuous by its absence.
• More effective “policing” of the day’s schedule (sessions overran)
• Mike-up the audience (or as a minimum ensure speakers repeat ALL questions so all can hear)
• Opportunity for Open space session(s) and/or lightning talks aka Pecha Kuchas

Lean/Kanban Munich

What I liked

• The venue
• That everyone could get to the Alpen Hotel quickly and easily
• That some of the sessions were videoed
• The audio facilities for the session speakers
• German beer
• The camaraderie common to all attendees.
• Meeting many Twitter friends in meatspace
• The roster of great speakers

Overall score out of ten: 8

What would have made me give a ’10’ score

• Reliable and convenient Hotel Wifi
  • As a visitor from another country wishing to avoid excessive mobile roaming charges, and not wanting the cost and hassle of buying and swapping-in a local SIM, wifi is the best solution for me to stay in contact with home, and MORE IMPORTANTLY to stay in contact with other conference folks to arrange e.g. social events during our stay.
• Reliable Conference WiFi
  • This was particularly poor.
• All sessions videoed (especially mine :}
• Quicker publication of videos, slide packs after the event
• Better (suggested?) Hotel
  • Avoid the Metropol 😦
• Less confusion and uncertainty over speakers’ expenses.
• Real-time display of the conference (or even better, session-specific) tweet streams, on stage, during all sessions
• A lounge area (specifically, with comfy seating) at the conference venue

LESS Stockholm

What I liked

• The “volunteer” nature of the event – thanks to all those who made it so great 🙂
• Everyone in the same hotel
• Outstanding catering facilities, especially the fruit, drinks, amuse bouches, and cake
• The audio facilities for the session speakers (when they were used)
• The camaraderie common to all attendees and organisers alike
• Strengthening many Twitter friendships in meatspace
• The roster of great speakers

Overall score out of ten: 7.5

What would have made me give a ’10’ score

• A chance to see something of Stockholm
• Better beer
• More cake! 🙂
• Not getting bounced out of the bar in the late evening “because of Swedish alcohol laws”
• Better session rooms
  • Rooms were too bland and impersonal
  • Room B1 was imo too wide and shallow and too small for keynotes
  • Other session rooms were too large
  • All projection screens were way too high
  • Lighting of e.g. the speakers themselves was poor. Needed spotlights!
• Sessions videoed
  • I really hated having to miss sessions from the multiple tracks in the knowledge that I’d not ever have the chance to catch them on video later.
• Convenient Hotel Wifi
  • As a visitor from another country wishing to avoid excessive mobile roaming charges, and not wanting the cost and hassle of buying and swapping-in a local SIM, wifi is the best solution for me to stay in contact with home, and MORE IMPORTANTLY to stay in contact with other conference folks to arrange e.g. social events during our stay.
  • Telia’s wifi service was (generally) reliable, but a UX nightmare (continually having to reauthorise).
• That the Hotel had refrained from remodelling their bar area during the time we were there
  • Particularly all the banging (demolition noise) during breakfaster and lunch
• More clarity re: speakers’ expenses.
• Real-time display of the conference (or even better, session-specific) tweet streams, on stage, during all sessions
• Cheaper airport transfers. The Arlanda Express is way too pricey.

Happy as always to answer any questions, etc.

– Bob

Applying Silent Grouping to Sprint Retrospectives

[From the Archive: Originally posted at Amplify.com Aug 26, 2011]

I recently tweeted about the advantages of Ken Power’s Silent Grouping technique for Scrum Release Planning sessions. We have found it much preferable (i.e. quicker, more fun) to the more common “Poker Planning” approach.

I have been thinking about using the same principle more widely, and had the opportunity yesterday to apply a variant of Silent Grouping to a Sprint Retrospective.Our teams have recently found the Speedboat Game a welcome improvement to retrospectives, but have been somewhat frustrated by the time it was taking for everyone to contribute their ideas (leaving little time to prioritise issues and discuss possible remediations).

So I suggested we apply Silent Grouping to the contribution, and prioritisation, of issues via the speedboat’s ‘anchors’.

This turnout out swimmingly (sic) and gave us much more time to identify and discuss some Rightshifting (i.e.. improvement) stories – as backlog candidates for the next Sprint.

Approach

• Briefing: Folks were encourage to write (just) one or two (super) stickies identifying issues that they really thought needed positive action and resource to address in the next sprint (i.e. fix or do more of).
• Round 1 (silent): Each team member in turn adds ONE sticky to the speedboat, until all stickies have been posted.
• Round 2 (silent): Each team member in turn has the chance to move one group of stickies (i.e. one anchor chain) towards to the bow or stern of the speedboat (we arbitrarily decided that the highest priority anchor chain would be the one nearest the bow). When movement ceased, we proceded to round 3.
• Round 3 (discussion): The team then discussed the issues in order of priority (top priority first). In this case we devoted about 10-15 minutes to each of the top two issues, clarifying the issue (reaching some consensus on the nature of the problem) and floating possible (general) solutions. Each such issue then became a candidate Rightshifting story for the next Sprint.

Possible improvement for next time: Start with the speedboat and chains from last time, so as to sweep up issues not yet actioned as e.g. Rightshifting stories.Happy to share more detail/ideas on this with anyone interested…

– Bob

Further Reading

Using Silent Grouping for Rapid Story Ranking – Blog post

Managing Costs Causes Costs to Rise

[From the Archive: Originally posted at Amplify.com Jul 10, 2011]

In case anyone wants more detail on why this is so. A handy reminder.

Amplify ’d from www.thesystemsthinkingreview.co.uk

Managing costs causes costs

Before we explore how managing costs causes costs in service organisations, we need to consider an important advance in manufacturing, where this counterintuitive truth was first discovered. Taiichi Ohno was the man who developed the Toyota Production System: a system designed to make vehicles not at the rate the machines demanded in order to achieve economies of scale, but at the rate of customer demand. He took Ford’s ideas a massive leap further. While Ford was concerned with unit cost, Ohno concentrated on total cost. He took the view that cost was in flow – how smoothly and economically the parts were brought together in the final assembly – not just the aggregation of unit costs. How long the part is in the system is also part of its real cost. So Ohno’s factory had parts delivered to the manufacturing line at the rate the line required them – ‘pulled’ in his language (by kanban or ‘just-in-time’).

Read more at www.thesystemsthinkingreview.co.uk

– Bob

The Carrying-Cost of Code: Taking Lean Seriously

[From the Archive: Originally posted at Amplify.com Jun 5, 2011]

A somewhat tardy response to a recent blog post by @mfeathers. http://goo.gl/9KUGq

Amplify ’d from www.twitlonger.com

@mfeathers /cc @markdalgarno

Re: The Carrying-Cost of Code: Taking Lean Seriously http://goo.gl/9KUGq

I was with you all the way until your assertion that “code is inventory”. (And only dysfunctional Lean Software Development groups have “chosen to see tasks as pieces”).

In software development we are not “essentially working on the same car or widget continuously, often for years”. We are working on the *designs* for the same make or model of car, continuously, often for years. Regularly (as regularly as every couple of weeks, or even every couple of hours, for some web companies) we pass the latest design to the “factory” and another car instance pops out and passes into service.

To me, requirements (user stories in the product backlog) and everything downstream from there (including code, and even testing effort) is inventory. In fact, borrowing from Theory of Constraints’ definition of the term, I hold that inventory is “everything that a business spends money on (e.g. buying or building), that it might expect to sell again some time later”.

And inventory itself is not necessarily a bad thing. It’s the *carrying costs* of inventory that suggest we might do well to minimise it. Yes, code certainly has carrying costs. But so do many of the other assets/artefacts that arise during the process of software development.

-Bob

P.S. Thanks for your patience. And I’ve posted here as your blog post seems to not want to accepts comments any more.

Read more at www.twitlonger.com

– Bob

10 Reasons CEOs Unwittingly Sabotage Innovation

[From the Archive: Originally posted at Amplify.com Jan 2, 2011]

An insightful list:

Amplify’d from www.ideachampions.com

There’s a huge gap between CEOs saying they want their companies to innovate and actually acting in a way consistent with what they say.

This lack of congruence drives internal change agents crazy, catatonic, or out the door. At the very least, it makes them cranky and unwilling to go the extra yard required to turn their inspired ideas into reality.

And so, as a public service to all of you out there whose CEOs are not walking the talk, here’s my TOP TEN reasons why not.

Choose one, align with some fellow change agents, and kick start the process of actually doing something about it.

1. Innovation sparks dissonance and discomfort.
2. Innovation is all about increasing variability. Most CEOs want to decrease variability and increase predictability.
3. Results only show up long-term — not next quarter.
4. CEOs conserve resources. Innovation requires more resources.
5. Innovation flies in the face of analysis.
6. Imbalance of right-brain and left-brain thinking.
7. It’s not in the job description.
8. Over-reliance on cost-cutting and incremental improvement.
9. Inability to enrol a committed team of champions.
10. Insufficient conviction that innovation will really make a difference.

Read more at www.ideachampions.com 

– Bob

Microbes Swap Genes to Communicate; We Have the Option to Swap MEMEs to Communicate

[From the Archive: Originally posted at Amplify.com May 29, 2011]

[The original page has gone, it’s now at: http://www.discovermagazine.com/the-sciences/festooning-the-tree-of-life – updated here 2 June 2021]

Random thought of the day.

New research from biology tells us that microbes can actually swap genes in order to communicate with each other. We as humans have the option to swap memes.

Amplify’d from unlocktao.com

Microbes swap pieces of their DNA to communicate their behavior. Read more at unlocktao.com

– Bob

Critical Agile Memes

[From the Archive: Originally posted at Amplify.com May 17, 2011]

One topic of the recent #lru2011 London Rightshifting Unconference was “Adopting the Agile Mindset”, and to kick off the topic we chose to attempt definitions of those terms, so that we might be all on the same page.

In the course of that discussion, we surfaced the following “Critical Agile Memes”:

Agile adoption means personal change – not just for developers, but for other folks across the whole organisation. And by personal change here, we mean coming to see the world (and the world of work) from a different perspective.

Agile adoption means a focus on delivery of value – early and often – By value we mean, things of value to stakeholders; and by early we mean within a few days or weeks (sometimes even, hours) of starting a new project.

Agile adoption means understanding that people are different – seeing people as individuals, and recognising that a one-size-fits-all attitude to people has serious drawbacks.

I’ve posted these three memes here as I thought them worthy of recording, and because I find it very interesting that we focussed on these three (and not, for example, the multitude of other “what is agile?” memes).

– Bob

Second London Rightshifting Unconference Report #LRU2011

[From the Archive: Originally posted at Amplify.com May 15, 2011]

Second London Rightshifting Unconference

Wednesday 11 May 2011 saw the second London Rightshifting Unconference #LRU2011 take place under the kind auspices of London City University.

Following-on from the success of the first Unconference in December, 2010, bookings were strong but attendance was down, on the day.

As an Unconference, our first order of the day was to decide on a (few) topics for “slots” during the day. We arranged these into a simple backlog, Kanban-stylee.

The topics we decided upon (in no particular order) were:

Decision Efficiency

Why do business decisions take so long, how can we speed things up?

Adopting the Agile Mindset

Practical means to open folks’ minds to Agile ways of seeing, being?

Shared Experiences

Shared experience amongst the delegates of applying Rightshifting, or of situations where Rightshifting could have helped had we but known enough about it.

Cultural Challenges

Aspects of existing organisational cultures (collective mindsets) that make adopting new ways of seeing, being a major challenge

Chaordic Organisations

What do these kinds of organisations look like, feel like, work like? What role for managers in this brave new world?

The Role of Managers in Continually Improving Effectiveness

The Rightshifting Perspective on what and how senior and middle managers can contribute to Rightshifting their organisations, and in particular , shifting the prevailing collective organisational mindset.

Enrolling Stakeholders in Rightshifting

Who are the stakeholders in making organisations more effective? What’s in it for each for them.How can we nurture what Kotter describes as the essential “guiding coalition” for change?

Knowledge and Competency Constraints

What constraints are there on the velocity of Rightshifting in a typical knowledge-work business? How can we exploit and then elevate these constraints (cf Theory of Constraints)

Introduction to Rightshifting

A semi-formal presentation of / introduction to / recap on the fundamental ideas of Rightshifting and the Marshall Model (from @flowchainsensei).

Output (outcome) based Contracts

A brief overview (from @pg_rule) of how using output-based contracts (now well-established in some quarters) can ease customers concerns over the commercial aspects of agile methods.

The Five Capitals Model

How the Forum Of The Future’s Five Capitals model supports the discover and delivery of value within e.g. software development and other knowledge work.

The Running Order

The Running Order for the day turned out to be:

• Introduction to Rightshifting
• Adopting the Agile Mindset
• Cultural Challenges
• The Role of Managers in Continually Improving Effectiveness
• Chaordic Organisations
• Enrolling Stakeholders in Rightshifting
• Output (outcome) based Contracts
• Summary / wrap-up of the day

The sessions had a natural flow, moving easily from one topic and slot to the next. A good time was had by all, and everyone expressed that they had learned some useful things, and had found much value in attending.

In the spirit of “pull”, if you have any interest in hearing about what we discussed within each of these slots, please post a comment or question, below, and I’ll be happy to trawl my recollections for specific details.

– Bob

Rightshifting Recruitment

[From the Archive: Originally posted at Amplify.com Apr 19, 2011]

Introduction

I don’t think that anyone (excepting maybe those with vested interests) would dispute that recruitment in the knowledge-worker space is very broken. I have recently tweeted about how traditional CVs are a key element of the dysfunctional recruiting landscape, and how we would all be much better off without them (see the #NoCV hashtag).

Some folks have responded by asking, almost despairingly, “how else could organisations look to hire new people?” Hw might they:

1. Filter out the few most relevant applications from the fire hose of applications they receive and
2. Support the evaluation of filtered candidates at e.g. interview time.

Setting aside issue 2. for the time being (FWIW, I hold that interviews are almost as broken an element of the recruitment process as are CVs), let’s consider how organisations might become significantly more effective at tackling issue 1. namely, filtering applications.

Deming’s 95/5 Rule

W Edwards Deming, American father of the Japanese post-war economic “miracle”, wrote that “a bad system will defeat a good person every time”. He pointed out that when people work for an organisation, some 95% of their productivity is a product of the system within which they work, and only some 5% of a individual’s productivity is down to their own skills, talent, effort, etc.

If we choose to believe this, then the achievements, etc., found on folks’ CVs are likely 95% due to the system at their previous employers, and only 5% due to their own skills, talent, etc. in those previous positions.

Mindsets are Key

I titled this post “Rightshifting Recruitment” as Rightshifting (specifically, the Marshall Model) offers a different perspective, and a way forward, out of the CV trap, towards a better, more effective #NoCV recruitment process.

If we choose to accept the Marshall Model (which posits that Mindset is the key determinant of organisational effectiveness) combined with the observations re: Deming’s 95/5 rule, then organisations should NOT be recruiting primarily on the basis of applicants (claimed) skills and talent, but rather on the basis of mindset “fit”. I.E. We should match the mindset of each applicant against the prevailing (or target, if different) collective mindset of the hiring organisation, and filter those applicants that have an acceptable “range of fit”.

Range of Fit

Although hiring organisations will have a single “Rightshifting Index” (position on the horizontal “effectiveness” axis), each applicant will have a range of mindsets (a distribution along the horizontal axis) within which they will likely be effective. Organisations looking to maintain the status quo (a given Rightshifting Index value) may value applicants that match that Rightshifting Index value closely. However, organisations looking to continually improve, or maybe even transition to a more effective mindset (i.e. significantly shift to the right) may more value applicants that can span the range from the organisation’s present Rightshifting Index value all the way over to the target Rightshifting Index value. Put another way, applicants that have seen “the Undiscovered Country” will be at a premium – for such organisations contemplating, or already embarked upon, such a journey.

Example (see graphic, above): An organisation presently at or around “1” on the RIghtshifting axis may be seeking to Rightshift to i.e. “1.8” (this is typical of organisations “going Agile”). Recruiting for fit against the red curve will result in new hires who actively oppose this Rightshift aspiration. Better to seek new hires who fit in the yellow curve, as they are much more likely to actively assist the Rightshift / transformation.

Practicalities

We already have the means to assess the current and target “Rightshifting Indices” (positions on the horizontal “effectiveness” axis) for a given organisation. A simple (5 minute, multiple-choice) questionnaire can serve to assess the relative spread of the mindset(s) that a given applicant can span. Overlaying the two can then immediately show the relative “fit” for each applicant.

Zappos

Some outstanding organisations, like Zappos, have already discovered the importance of selecting new hires on “fit”, (Zappos famously offers new hires a $3000 “quitting bonus” to leave the organisation if the new hire feels they’re not a good “fit” at the end of each of their first four weeks).

Conclusion

Using CVs to filter suitable candidates just does not work at all well (does not find the most suitable applicants to go forward in the hiring process), for knowledge-work businesses. By selecting on mindset “fit”, knowledge-work businesses have a much better chance of selecting applicants that will be truly productive within the business’ prevailing (or target) collective mindset.

– Bob

Further Reading

“Why Good People Can’t Get Jobs” ~ Online article by Dr. Peter Cappelli
“Bad Hires Have Cost Zappos Over $100 Million” ~ Tony Hsieh

Postscript

This topic was the theme for my Magrails 11 presentation in October 2011:

Video of Magrails11 presentation

“Rightshifting Recruitment“

Another Definition of Rightshifting

[From the Archive: Originally posted at Amplify.com Apr 10, 2011]

@techphoria414 on Twitter said of the clipped tweet (below): “That single tweet is the best explanation I’ve heard from you. Save that one.”

So I have. 🙂

Amplify’d from twitter.com

Rightshifting explains the core issues of sustainable agile adoption, and what organisations can and must do to achieve that sustainability. flowchainsensei Bob Marshall Read more at twitter.com

– Bob

 

Psychology of Change in Organisations

[From the Archive: Originally posted at Amplify.com Apr 08, 2011]

[Updated Jan 17, 2021 to point to different online version of the referenced article, the original at www.psychologytoday.com having become inaccessible.]

Here’s a snippet from an article explaining the key role of (collective) mindset in organisational change.

Organisational psychology and neuroscience are two key influences in the Marshall Model. This article fills in some of the background to how these things relate:

Leaders today must understand and apply the knowledge of behavioral psychology and the lessons from brain science [a.k.a. neuroscience] to manage organizational change successfully. In the past, efforts at organizational change which have focused on the structural aspects of organizations have systematically failed because they have neglected the reality that change doesn’t happen without individual people changing their thinking, beliefs and behavior.

In an article in the McKinsey Quarterly, Emily Lawson and Colin Price argue that change success in large organizations depends on persuading hundreds or thousands of groups and individuals to change the way they work, a transformation people will accept only if they can be persuaded to think differently about their jobs. In effect, CEOs must alter the mind-sets of their employees—no easy task.

Read more at TheChangeManager

– Bob

Neuroscience of Rightshifting

[From the Archive: Originally posted at Amplify.com Apr 2, 2011]

A totally excellent paper providing insights into the neurological underpinnings of Rightshifting and the Marshall Model of Organisational Evolution.

Read the whole thing!

– Bob

Amplify’d from www.strategy-business.com

With a little knowledge of neuroscience, reframing behavior can be the essence of organizational change. Read more at www.strategy-business.com

– Bob

The Improvement ROI Sawtooth

[From the Archive: Originally posted at Amplify.com Mar 27, 2011]

Significant Change is NOT Continuous

The Marshall Model postulates that any business on a Rightshifting journey towards greater organisational effectiveness travels through a series of punctuated equilibria.

If you accept this, then an interesting implication follows:

Consider Company X – let’s say to begin with it’s in the Analytic mindset – making improvements to its effectiveness (whether folks in Company X are expressly focused on improving organisational effectiveness, or on other aspects of improvement which happen to have a fortuitously positive side-effect on organisational effectiveness is moot for the purposes of this discussion).

So, let’s assume Company X is rightshifting (making improvements) fast enough to offset the inevitable left-drift (entropy, changing operating environment, etc.) inherent in the running of any real-world business.

It’s All Downhill After a Transition

As Company X approaches the Analytic-to-Synergistic transition zone, we might expect that it begins to experience decreasing ROI on it’s improvement efforts. This is due to a change in the nature of the improvements necessary to continue to Rightshift, e.g. from relatively simple introduction of things like new tools and new ways of working to increasing emphasis on changing assumptions, and on new ways of thinking and being.

(I posit that another factor in the decreasing ROI on Company X’s improvement efforts comes from the increasing cognitive dissonance being experienced by folks up and down the organisation as the company approaches the transition zone).

Crunch Time

Eventually, Company X may reach the point where its ROI on improvement efforts has tailed-off to something approaching zero. Put another way, the company may find itself unable to make any further significant improvements to its effectiveness, regardless of how much time and money it ploughs into its improvement efforts. Upon reaching this position, Company X now has only two sensible options:

1. It can give up on rightshifting any further, and settle for its present level of effectiveness.
2. It can endeavour to embark on a transition to i.e. the Synergistic mindset.

(Note: Option 1 does not mean an end to Company X’s improvement efforts, as left-drift will continually degrade the company’s effectiveness. Company X will be obliged to continue to deploy some improvement efforts, in order to maintain its present level of effectiveness).

The Rightshifting ROI Sawtooth

Why have I named this the “Rightshifting Sawtooth”? Because, if we plot ROI on improvement efforts for Company X, as it moves along the Rightshifting axis (i.e. horizontally from left to right), the line plotted will resemble a sawtooth pattern, with a minimum just before (to the immediate left of) each transition zone, and a maximum just after (the right of) each transition zone:

As ever, I welcome your comments, observations and questions.

– Bob

The Origins of the Marshall Model

[From the Archive: Originally posted at Amplify.com Mar 25, 2011]

A Series of Happy Accidents

Like many discoveries, the Marshall Model came about more or less by pure chance, through a series of happy accidents. In explaining this series of events, maybe some folks can glean a further insight into the model and its utility.

Accident #1 – Agile North 2008

I was rather late in submitting my proposal for a presentation to Agile North 2008, and in a rush to put together said proposal, found myself following a line of research from Steve McConnell’s (excellent) book “After the Gold Rush” to his related paper “Business Case for Better Software Practices“(in turn, excerpted from his book “Professional Software Development”).

McConnell’s “asymmetric bell curve” spoke to me, in that it articulated a truth that I had been struggling to state for some time. I resolved to use his chart as the foundation for my presentation, but how to turn one simple chart into a hour-long session? (You can see the derived chart, here.)

Reflecting on the curve, and on my own experiences in many diverse kinds of software development organisations over the course of some thirty years, a question bubbled-up in my mind: what would life look like from the perspective of folks working in different organisations at various points along the horizontal axis? Surely that might be of some interest?

As McConnell observes:

“…most software personnel have never seen software
development at its best. This gives rise to skepticism about whether things are really better anywhere. Even people who have worked in the software industry for 20 or 30 years might never have seen software development at its best.”

This is certainly apparent, and so it was but a small step to decide to base the presentation on the idea of illustrating the different experiences of people, in organisations from inept to highly effective.

The “Rightshifting” Name

So what to call this presentation? Given the talk was largely anecdotal (based on my own experiences, my own perspective) and given that I was attempting to illustrate the different perspectives on the world of work of the folks in various organisations, I chose the word “Perspectives”. But perspectives on what?

I had been working for a decade or more in the field of process improvement (OO, CMMI, Agile, Lean, TOC, etc.). I had come to see that the concept labelled “process” was not only widely misunderstood, but generally much disliked by all concerned – from developers through senior managers. Looking at the chart, it was immediately clear that any organisation wishing to improve their performance (a.k.a. effectiveness) would be trying to move “to the right”. So it was that the term “Rightshifting” was born.

As the presentation evolved (both prior to its first outing, and subsequently), I repeatedly added new slides illustrating different dimensions of life in software development organisations (waste; productivity; favoured SDLC; prevailing flow mode; attitudes to workers; levels of fun; etc.) Aside: In the course of researching my (forthcoming) book on Rightshifting, I have now assembled a list of some fifty different dimensions in which life in organisations differs markedly, along the Rightshifting axis. (You may be interested to see the Agile North 2008 presentation – “Perspectives on Rightshifting” on Authorstream, as well as an annotated version here on this blog).

Accident #2 – Feedback from Agile North 2008

The presentation at Agile North 2008 was very well received (being voted the joint best session of the conference), and many of the folks in the audience came up for a chat after the session with observations, questions and suggestions. In the following week, and reflecting on both the event and people’s suggestions, my subconscious began to assemble a narrative, categorising the different “modes” of organisations along the rightshifting axis. Soon, these ideas coalesced and emerged into the daylight of conscious thought as the “categories” of the (yet-to-be- conceived) Marshall Model.

Accident #3 – Dee Hock

To begin with, I only had three categories identified (and as-yet unnamed).

Those are the three categories that now bear the names “Ad-hoc”, “Anayltic” and “Synergistic”. But there was a (large) blank space on the far right-hand side of the chart (from around 3.5 onwards), begging to be claimed and named. It was clear that something should be here, but what? It was not until some weeks later, when reading a paper by Dee Hock, that the idea of the “Chaordic organisation” slotted into place.

Around this time I was also discovering Ackoff and his unique perspective on systems and systems thinking. From his work came the name for the second category “Analytic thinking”. And the great R Buckminster Fuller contributed the name “Synergistic” (after some to-ing and fro-ing with my [update: now, sadly, late] colleague and co-conspirator Grant Rule, who btw also inspired the name “Ad-hoc” for the leftmost category).

Accident #4 – Seeing the Categories as “Mindsets”

It was only some months later – whilst reading Carol Dweck’s book “Mindset” – that the idea emerged of these – now four – categories as being “mindsets”.

Accident #5 – Transitions

Armed with a revised Rightshifting Chart, overlaid with the four mindsets, a new question struck me: What happens in the spaces where the mindsets overlap? Yes, one way of looking at this simply means that there can be some e.g. Analytic organisations which are (slightly) more effective than some organisations who have adopted the Synergistic mindset (and so on for the other overlaps).

But in a more profound sense, these overlapping zones signify the root of the challenge facing ALL organisations on their rightshifting journey: changing the prevailing collective mindset of the organisation. Incremental improvement is all well and good, and fairly straightforward within any one particular mindset. But continual incremental improvement (if resulting in a net shift to the right) will inevitably result in an organisation entering a transition zone, sooner or later.

With this realisation, I felt I had reached a stupendous milestone on my own journey of discovery. This was the key piece of a jigsaw puzzle I had been seeking for some twenty years or more. The answer to the question “WHY are so many organisations stuck around the median for effectiveness”? i.e. in the words of Steve McConnell: stuck “performing much closer to the worst practice than the best”.

The Key Piece of the Jigsaw

So many organisations get stuck on their journey to improved effectiveness because making progress through a transition zone (aka changing the prevailing collective mindset) is at least an order of magnitude more difficult than simple incremental improvement – and yet looks no different to the simple case, from the perspective of the managers and workers involved in attempting such a challenge (cf William Bridges’ book, “Managing Transitions”, and the Satir Change Model).

Conclusion

The creation of the Marshall Model has been a story of how a happy series of accidents led me to an answer to a question that had been bugging me for more than twenty years. If it’s a question that’s been bugging you, too, then I offer you the model in the hope that it might help you find your own answer, or explain it to others.

– Bob