What Veiled Magic Hath the Question?

Did you know that Indira Gandhi said:

“The power to question is the basis of all human progress.”?

What’s the most useful opening question in fostering understanding? How about “What would you like to have happen?”?

Have you tried using this question yourself, and under what circumstances?

What responses does it typically elicit? And how does it affect the dynamic of the relationships between the asker, the askees, and the (group’s, team’s, or organisation’s) “collective psyche”?

How would you feel if I told you about my recent experience with this and other “facilitative questions“?

When you ask questions, do folks see the answers as the goal, or do they appreciate the veiled magic of questions – that is, the mental state and reflection they induce in the person being asked the question? Did you realise, for example (as suggested by Patterson et al in Crucial Conversations) that when answering questions, the circulation of blood in the brain changes away from the Amygdala (fight-or-flight lizard brain) to the cerebellum (rational thinking part of the brain)?

– Did you realise Bob wrote this?

How About Some Other Related Things to Read?

What Are Questions For? ~ Sharon Drew Morgen
Is Less More? ~ Penny Tompkins and James Lawley
The Art of Powerful Questions – Article by Eric E. Vogt, Juanita Brown, and David Isaacs
The Interrogative Mood ~ Padgett Powell
This Question Could Change Many Of Your Habits ~ Dr Jeremy Dean

Retrospectives – Wronger and Righter

I have yet to see a development team get any real value out of a retrospective. Not that it seems impossible, just that it seems few to none understand how. In my opinion, the relative failure of retrospectives goes a long way towards explaining the superficial nature of so-called continuous improvement in most agile development shops.

Wronger

The fact that retrospectives are disassociated in time with the problems (and successes) with which they concern themselves is an issue. Andon, which gives workers the opportunity to stop the line as soon as a problem occurs, points the way to reducing or eliminating this temporal dislocation (and thus to tackling the rationale opposing a stop-the-line approach).

And I have seen few teams with any clear approach for converting the output of retrospectives (e.g. improvement suggestions) into actions for the next (or future) iterations, let alone prioritise these against (other) backlog items e.g. pending user stories or new features.

Righter

Anything that gives folks an opportunity, to talk, and reflect has got to be a good thing, in my book. So that, at least, is an entry in the “plus” column for retrospectives.

How to turn the ordinary retrospective into something extra-ordinary? Go back to its roots. Specifically, PDCA (the Shewhart Cycle). Many folks see the word “Plan” in the simple context of e.g. Sprint Planning and Release Planning (Scrum). But in PDCA proper, derived as it is from Francis Bacon’s original “Scientific Method”, “Plan” means hypothesise:

• “hypothesis” – plan
• “experiment” – do
• “evaluation” – check
• (Control – a later addition) – act

In this scheme of things, any retrospective is pointless unless it’s answering the question “did what we expect to happen – our hypothesis – actually happen?”. If so, why so. And if not, why not? Absent an initial hypothesis, we can never ask ourselves this question.

OODA (Observe-Orient-Decide-Act; Boyd) and LAMDA (Look-Ask-Model-Decide-Act) – close cousins of PDCA – both add emphasis on the context for formulating such hypotheses.

So, next time you start a Sprint, Cycle, or such like, get your hypothetical ducks lined up for the benefit of the ensuing retrospective.

And let us know how it goes?

– Bob

Focus

Most business have far more things to attend to than they have time or energy. The simple question then arises: where to focus? Where to focus people’s attention. Where to focus limited resources. Where to focus for maximum return? As Goldratt says in Theory of Constraints:

What to change?

What to change to?

How to effect the Change?

Of course, this is not a new problem. Many businesses have come up with ways to address this challenge – some ad-hoc, some in the context of solving or dissolving problems local to some limited part of the business, some encompassing the whole business, and some taking in the grand sweep of an entire value chain (i.e. involving numerous connected businesses). Business gurus, pundits and scientists have also much studied the issue and produced a wide range of techniques.

Some of the better-known of these include:

• Theory of Constraints – Goldratt – specifically the Five Focusing Steps and Current/Future Reality Trees
• Reference Projection (Interactive Planning) – Ackoff
• Business Decision Mapping
• Value Stream Mapping
• Business Process Mapping
• Business Process Reengineering
• Strategic planning
• Leverage Point Modelling

There are also any number of supporting techniques and concepts, including:

• Evaporating cloud (from Theory of Constraints) – to help resolve conflicting assumptions
• Scenario Planning (Kahane, etc).
• Systems Thinking (Senge) – in particular “system archetypes“
• Mind-mapping (popularised by Tony Buzan)
• Twelve Leverage Points (Donella Meadows)
• System dynamics (Jay Forrester)
• TRIZ (Genrich Altshuller) a.k.a. “the theory of inventive problem solving”
• Wicked Problems (Horst Rittel), Messes (Ackoff)
• Delphi method – for arriving at a consensus amongst e.g. experts.
• Semantic Networks
• Kaizen
• Kaikaku
• Root Cause Analysis
• 5 Whys
• A3 (Problem-solving technique)
• Hoshin Kanri (Policy Deployment)
• Value Disciplines Model (Treacy & Wiersema)
• BHAGs (Big Hairy Audacious Goals)

Most of the above techniques implicitly or explicitly reference some kind of looping or interactive approach, whereby once the object (issue, problem, challenge, opportunity) has been dealt-with, the technique is applied to the next object, and then the next,.. and so on, ad infinitum. Here we cross over into the realm of continuous improvement. Such looping techniques include:

• PDCA (The Shewhart Cycle)
• OODA Loop (Boyd)
• LAMDA
• IDEF0 (antiquated?)
• DMAIC (Define, Measure, Analyze, Improve and Control) from e.g. SIx Sigma)
• etc.

How many approaches to focusing have you employed? Which do you favour? Which do you know to work well, and in which context(s)? Which other techniques complement your chosen focusing approach?

Choosing the Right Approach

Well, of course, there is no one “right” approach to deciding where to focus in a business. But I posit that there is value in finding one right approach for your business. If nothing else, it means folks across the whole business can participate in e.g. planning sessions without having to repeatedly learn new vocabularies and concepts.

Absent clarity of purpose for the business, choosing any approach will likely only provide a means to do the wrong things righter. As Lewis Caroll once wrote:

If you don’t know where you are going, any road will get you there.

In other words, if your business as a whole has no focus, then there doesn’t seem much point in focusing on what exactly it might be best to do next.

As for which approach(es) to choose, I’d say it depends. Not least, it depends on the prevailing mindset in your business (see: Rightshifting and the Marshall Model).

For Ad-hoc-minded businesses, the question is essentially moot, as everyone will have their own ways of focusing on what’s important, even assuming that any such focusing ever happens.

For the Analytic-minded businesses, it’s most likely that some approach that helps optimise parts of the business will find most favour. I’m not going to say more about these businesses here.

For Synergistic-minded businesses, folks will generally look to a focusing approach that caters to a system-wide viewpoint.

Having used Theory of Constraints, and in particular Current Reality Trees and Future Reality Trees, for the past fifteen years and more, I’m more than comfortable that this can do the job. I can also vouch for the unsuitability of this kind of approach in Analytic-minded businesses!

For the very rare Chaordic-minded businesses, I suspect that any suitable approach would have to cater to the highly dynamic nature of such businesses, and allow for rapid identification of areas of focus, in the order of seconds or minutes within which each new focus can be identified and acted-upon.

– Bob

Further Reading

Solving Tough Problems ~ Adam Kahane
Systemantics ~ John Gall
Statistical Process Control ~ Deming et al – Distinguish between purposeful change and “tinkering”
LAMDA: A Leadership Principle for Lean Product Development ~ Kennedy & Sobek (PDF Slide deck)
The Life We Are Given ~ Leonard – Lest we forget the human dimension

So You Really Want to be an Agile Developer?

What does it mean to be an Agile Developer? Where does that path lead? I’m wondering how many developers out there have ever had the opportunity to find out. And for those – few, I suggest – who have, did they like it?

Faux Agile

By now I think many folks are aware of “faux Agile”. Groups of people, rarely even worthy of the title “teams”, where folks go through the motions of “doing agile”, typically at the behest of managers who want “productivity” or some other – often imagined and nebulous – agile benefits, but who remain unwilling to allow the groups to adopt many, if any, of the core Agile behaviours.

Agile as the Manifesto Intended

For the rarer case, where circumstances are more favourable, folks can indeed feel happier to have the opportunity to “do Agile” – to some extent “as the Agile Manifesto authors intended”. But even for these folks, and yes we can assume many of them will be more like teams than mere groups, many will not have the opportunity to experience “full-on” agile development.

Full-On Agile

What is full-on Agile? Do we need it?

For me, full-on Agile is “Agile as the manifesto authors intended”, but with the knobs turned-up to 11.

Maybe it’s going to be easier to explain by listing what full-on Agile isn’t:

• It’s not having Business Analysts responsible for the requirements.
• It’s not having a Scrum Master, Agile coach, or some other functionary who doesn’t “do development”.
• It’s not having Architects responsible for the product’s features, interfaces or internal structure.
• It’s not having Product Owners between customers and the development team.
• It’s not having developers producing software separate from authors writing product manuals, separate from business folks designing a service on top of the software, separate from sales and marketing folks wondering how to sell the final product.
• It’s not having managers hiring new team members, shifting folks between teams, stipulating tools and methods.
• It’s not having Project Managers doing budgets, tracking costs, maintaining risk registers and issues lists, negotiating with customers.
• It’s not have a test team checking the outputs of the development team.
• It’s not even having testers working with developers to create tests before or during development of a feature.
• It’s not having a Quality Manager stipulating coding standards, test coverage targets, or processes to conform to.
• It’s not having metrics people (or Scrum Masters, or Project Managers) tracking velocity, burn-down, value delivered, or whatever.

It’s not that all the above activities are unnecessary. Far from it. It’s a matter of who does them, who takes responsibility for them. As I see it, “full-on Agile” means that the development team (collectively)  makes sure all these things get done (and decides which of them need to be done, which actually add value).

This has at least one major consequence – developers find themselves doing many things other than those they traditionally love, other than those they might feel are “the developers’ job”. (And, incidentally, other specialists on the team finding themselves doing many things outside their established specialisms).

Hence my opening question: Do you really want to be a full-on Agile Developer?

– Bob

Shifting and Drifting – Some Measures

I’m not a great fan of metrics and measurement, preferring instead to mostly intuit the state of play inside a business, through e.g. MBWA, going to the Gemba,  and other ways of just talking with folks to get knowledge. I know some other folks have a different view, so this post is for them.

The above chart shows the amount of effort organisations typically put into their metrics (measurement) programmes, overlaid against the basic Rightshifting (blue) curve.

“It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth”

~ WE Deming “The New Economics” 1994 – Ch. 2, page 35

“…management by numerical goal is an attempt to manage without knowledge of what to do, and in fact is usually management by fear.”

~ WE Deming “Out of the Crisis” 1982 – Ch.2, page 76

“the most important figures that one needs for management are unknown or unknowable”

~ WE Deming “Out of the Crisis” 1982 – Ch. 3, page 121

My late colleague, Grant Rule, being one of the foremost Software Metrics specialists in the world, had a different perspective, and we used to enjoy our regular discussions on the subject over many a pint. Happy days.

Aside: I’m not suggesting that MBWA is the sole prerogative of managers – I’d suggest that any organisation can benefit from folks of all stripes just wandering around to get knowledge. See also: Lay Off the Managers (blog post).

Following on from my previous blog post “Swimming Against the Tide“, this post provides some ideas to those folks who might wish to measure things in the context of a Rightshifting effort. Note: from the above chart, we can see that highly effective organisations do measure some things, just nowhere near as many things, or with as much effort, as their less effective cousins.

Goal, Question, Metric

Victor Basili et al conceived of a framework for deciding what to measure in software organisations in their work known as “GQM“. The basis of GQM is that (M)etrics should derive from certain (Q)uestions to which we want answers, and those questions, in turn, should concern the (G)oals we’re trying to achieve. In other words:

Goals ➡ Questions ➡ Metrics

GQM for the Rightshifting Organisation

Following the GQM theme, I posit that the goals of an organisation engaged in becoming more effective might include:

• The basic objective of becoming more effective.
• An understanding of the volatility (entropy) of the business’ operating context.
• Scheduling the investments in the drive for more effectiveness.
• Limiting the impact of organisational (internal) changes on customers and other stakeholders.

Consequently, Rightshifting proposes the following questions:

• How well are we doing in becoming more effective?
• What’s the strength of the change-related “tide” we’re swimming against as a business?
• How much do we have to spend (net, gross) to become more effective (i.e. to move one unit to the right)?
• How much are our efforts disrupting or otherwise impacting our customers and other stakeholders?

And, in search of answers to these questions, the following four general areas of measure:

• Gross rightshifting velocity (progress to the rights, per unit of time) (Rightshift).
• Velocity of the prevailing Left-drift (the effects of entropy, per unit of time) (Left drift).
• Cost to move one unit (say, 0.1 of a rightshifting index point) to the right (Drag).
• Impact on stakeholders from our rightshifting efforts (Turbulence).

We also have some symbols for these:

Do these four general areas of measure address all aspects of key interest for a Rightshifting organisation? What specific (i.e. quantifiable) measures would you derive in each of these general areas? What other goals, questions and metric can you think of?

– Bob

Further Reading

Competitive Engineering – Tom Gilb
Software Metrics: A Rigorous and Practical Approach – Fenton and Bieman
Goal/Question/Metric Method: A Practical Guide for Quality Improvement of Software Development – Van Solingen &and Berhout (pricey!)

Swimming Against the Tide

Organisations do not exist in a vacuum. All around them, and through them, every day, things are changing. Market tastes change and morph. Competitors invent and discover. Technology itself changes – and makes many other changes possible. Society, from whence the workforce is drawn, changes. People within the company come and go. Legislation makes new demands.

The Swirling Sea

Most organisations pay little conscious attention to the sea of change swirling around them, in which they swim. That’s life, after all, is it not? Many corporate ‘change’ initiatives are born in response to one particular swirl or another. Maybe one initiative or another will bear fruit before the swirl passes, maybe some initiatives actually deal with their particular swirl.

The Flowing River

If we adjust our analogy from swirling sea to flowing – oftentimes turbulent – river, we can say that organisations finds themselves swimming against a constant flow. Upstream lies higher margins, improved revenues, lower costs, and a generally more effective business. Downstream lies dissolution, waste, low margins, low sales, high costs, and a generally ineffective business.

Rightshifting characterises this river as flowing from right (upstream) to left (downstream). And organisations working to improve their effectiveness as swimming from left to right – i.e. against the flow. Any organisation that fails to respond adequately to change, any organisation which does not swim at least as fast as the flow of the river, will drift downstream (to the left – aka ‘left-drifting’).

Stasis – or Progress?

Many organisations barely manage to keep their heads above water, remaining essential stationary in the flowing river (i.e. relative to some fixed landmark on the river bank). Even though expending much effort, neither left-drifting nor right-shifting. Many of these organisations have little in the way of ambition to improve, to become more effective at what they do, and so regard their stasis, their lack of left-drift, as a great “achievement”.

A few, more ambitious, organisations however see such stasis as failure. Absent any net progress to the right, towards becoming more effective, all the time, money and effort invested in “improvement” just to stand still seems like a huge waste. Surely the aim of of “improvement” is actually to get better?

Just swimming is like busywork – without a reference point, energetic swimming can appear productive without ever being so.

Is your organisation actually making real progress upstream – or is it simply ever-busier swimming against the tide?

– Bob

Mea Culpa

Marcin (@mfloryan) asked me a while ago if I could ‘balance’ (or complement) my posts about Lemon Agile Consultants and the problems of having managers. He suggested another post exploring how some developers seem unwilling to adopt or engage with Agile development methods, or appear disinterested in the whole idea of improvement – either of themselves or the working practices in which they participate.

The Peg

I’ve since been struggling to find a ‘peg’ upon which to hang this idea, and thus, hopefully, make it interesting and relevant. So here it is: mea culpa, mea maxima culpa. My mistake – it’s all my fault.

Assumptions, Assumptions

It seems to me that implicit in the general question of “why do some developers seem uninterested in Agile – or the wider issues of improvement” lies the assumption that anyone in their right mind should be so interested.

Most of the folks that I know, talk with regularly, identify with are so interested.

Thus a lack of interest seems an aberration, a deviation from the norm. I seem to have succumbed to the fundamental attribution error – attributing the behaviour of others (the disinterested developers) to dispositional factors. Factors such as; they can’t be bothered, they’re unimaginative, they have poor a sense of social responsibility, they lack a sense of teamsmanship, and so on.

Are We Learning Yet?

How about we learn from the fundamental attribution error and admit the possibility of situational factors playing the key role? I’m not trying to deny the widely-reported observation that some developers do behave as if they have little interest in raising their personal skills, or the capabilities of their group, team or organisation. But how about considering why this should appear so?

Awareness

Number one on my list of possible reasons why, is that no one ever told them that it’s even possible to spend time on, invest effort in, self-improvement and/or group improvement. (The A.R.C. coaching mnemonic reminds us that Awareness is at the root of commitment to e.g. action). I mean, it’s not like this possibility is taught in schools or Universities, is it? The capacity for “divergent thinking” is actively degraded by our educational systems, according to @SirKenRobinson. Nor is the possibility for intentional improvement taught or experienced in the workplace, either, by and large.

Absent any such information or awareness, is it reasonable to expect folks to have some kind of natural, inborn predisposition towards self-improvement or group improvement? In the general case, I think not. (I’d be delighted if anyone can share any research or findings on the presence or absence of such a predisposition).

Other Factors

And then there’s a whole bunch of other situational factors which can come into play in any given set of circumstances. Can you think of some that might apply in your context, in your team or organisation? (If yes, might you like to share them, here?) .

So yes, I’ve fallen foul of an unwitting assumption about these developers’ dispositions. But maybe, just maybe you could find it in your heart to pray for me? And maybe have a chat with them about their perspectives – on the issues of both self-improvement, and improvement more generally?

Thanks. :}

– Bob

Further Reading

The Three Ingredients of Commitment (Agile Studio Blog post)
Coaching For Performance ~ Sir John Whitmore

What is Value?

A simple enough question. But one that seems to have occupied many folks for countless hours, on Twitter, in blog posts and other media, and in person, over the past couple of years.

Background

Some years ago now, my late esteemed colleague Grant Rule, and I were both working on our own respective models for how software development organisations could work more effectively. His approach, suited in the main to Adhoc and Analytic-minded organisations, he referred-to as “SlamIT”. Mine, as you may know by now, focuses on Synergistic-minded organisations, and goes by the name of “FlowChain”.

Both of us saw the uptick in interest amongst the software development community for a workable means to prioritise e.g. backlog items. If one is delivering software in one “big-bang” – often referred-to as the “Waterfall” approach – then the priorities of the various elements, features, stories, use-cases within that one indivisible set of deliverables is essentially moot. As many people have asserted over the years, with Waterfall a.k.a. “Batch and Queue”, “EVERYTHING is a priority!”.

Grant and I felt that by working together, using his skills and knowledge of metrics and measurement, and my experience in the business of Agile development, we could come up with a teachable method of assessing business value, useful in ranking (prioritising) the incremental delivery of software solutions. And applicable for both SlamIT and FlowChain adoptions/transitions alike.

Grant passed away suddenly and unexpectedly October, 2011. Since then I have been wondering how to tie up the loose ends of our collaboration on this “teachable method of assessing business value”, and make it useful to a wider community. I have not actually tied up the loose ends, but I publish here the core ideas underpinning our work, in the hope that others might find it useful, wish to dig deeper, or even collaborate to add some polish and further depth.

Incremental Delivery

Central to the Agile proposition is the notion of delivery of software – into production and earning its keep – early and often. Implicit in this notion is the need to choose features, stories or such elements for delivery according to some kind of priority. We can imagine many different prioritisation schemes, but one that seems to make sense is prioritisating according to the goal(s) of the people who will be paying for, and using, the software. Let’s call them the “immediate customers”.

Note: The remainder of this post assumes that money (e.g. “throughput-dollar-days”) is the unit of measure for the customer’s goal(s). This may not be the case for some kinds of organisation, such as various not-for-profits, charities, etc.

Customers Do Not Normally Know What is Valuable to Them

Goldratt has show us, through his work with the Theory of Constraints, that people are fairly poor at understanding their collective (organisational) goals, and even worse at understanding what things (bottlenecks, constraints) are preventing their organisation from realising more of these goal(s). Theory of Constraints furnishes us with a number of “Thinking Tools” by which to identify the goals, and then identify and deal with the constraint(s).

Aside: Even though customers can be very articulate, voluble and even convincing about what they want, what they want rarely coincides with what they need to address their current (organisation-wide) constraint. And I do appreciate that few indeed are the suppliers who have a sufficiently trusted status to dissuade a customer from the (widespread) practise of commissioning work of no actual, practical value to them (see more on this, below).

A Teachable Method of Assessing Value

Goldratt asserts that there is only ever one constraint in operation, in any given organisation, at any one point in time. Extending this, we assert that there is only one thing that is of immediate value to any given organisation (customer) at any given point in time.

If we undertake to deliver some feature or story which does not directly address this active constraint, then we are failing to deliver anything of (immediate) value. If it’s not of immediate value, then it has no utility, and in fact it’s a negative effort – in that it is simply adding to Inventory (assuming it has some redeemable value in the future) or becomes a write-off as an Operating Expense (assuming it turns out to have no redeemable value).

Thus, the most valuable thing to deliver to a customer is only, ever, something that addresses their current constraint. Actually, not only the most valuable thing to deliver, but the only valuable thing we can deliver.

It may not be immediately obvious, but a moment’s thought along this line of reasoning will also show that many constraints in an organisation will never be addressed or addressable by software. In which case it’s better to suspend work on – and delivery of – all stories until such time as the current constraint shifts and the software does address the (new) current constraint.

I believe this is in line with what John Seddon refers to when he says “Agile is just doing the wrong things, righter”.

Summary

In summary, if you are a software supplier, software house, or in-house software development shop, unless and until you understand your customer’s organisation well enough to know where its current constraint lies, you will never be in a position to deliver real value, except by sheer chance.

And given that few suppliers will ever be in a position to understand the internal working of another organisation, the prospect of finding their (shifting) constraint hinges on either:

1. Becoming a “Jonah” (see “The Goal”) and accepting the limitations of that role – including the need to teach the customer how to identify their own constraints (and appreciate when a constraint can be addresses by a software solution, and when it cannot) – hence “A Teachable Method of Assessing Business Value”), or
2. Becoming such an intimate partner with the customer that you can identify the customer’s constraint for them (and continue doing so, as their constraint moves and shifts).

Any other approach is simply an invitation to waste your time – and the customer’s money.

– Bob

Further Reading

The Goal ~ Eliyahu M Goldratt
Necessary But Not Sufficient ~ Eliyahu M Goldratt
It’s Not Luck ~ Eliyahu M Goldratt
Systems Thinking and IT ~ John Seddon (pdf)
Throughput Accounting ~ Thomas Corbett