[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

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).

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

[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

[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

[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

[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…

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

– Bob

[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

[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.

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

[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

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

• 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

[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:

– Bob

[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

[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

[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

[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?