Archive

Agile

The Future Of Software-Intensive Product Development

March 12, 2016
Agile, Culture change, Organisational effectiveness, Organisational Therapy, Product development, Rightshifting, Software development
6 Comments

The Future Of Software-Intensive Product Development

A little while ago I wrote a post posing some questions about what ways of working we might look to, After Agile. Fewer folks engaged with this post compared to some others I have written. So I’m assuming that few are thinking about what we might see as the natural – or even unnatural – successor to Agile.

It is, however, a topic that occupies me regularly. Not least because of the intrinsic flaws in the whole Agile idea. We can, and eventually must, do much better.

Recently, some folks have been asking me about what I see as the future for software- and software-intensive product development (SIPD). Of course, I’ve been answering this question, on and off, for at least the past few years.

In a Nutshell

To sum up my take: In a nutshell, the issues that plague SIPD seem obvious. They’re mostly the same issues that plague all forms of collaborative knowledge work. Issues compounded by the gulf between conventional or traditional work and the new world of work (i.e. the world of collaborative knowledge work) – a new world distinctly unfamiliar to most in the world of work today.

We are faced with various collections of pathogenic beliefs (management, traditional business, Agile, etc.), none of which provide us with a context for EFFECTIVELY tackling the challenges we face in the new world of work – i.e. the world of collaborative knowledge work.

I’m choosing here to list these challenges in terms of needs, and in terms of the strategies – conventional and unconventional – for meeting those needs.

Developers’ Needs

Agile came into being driven by developers attempting to see their needs better met. These include:

  • Less working time “wasted” on mindless bureaucracy and distractions, such as meetings, reports, documentation, etc..
  • More time to focus on making great software, and stuff that delights customers.
  • Improved relationships with co-workers, business folks, customers, and the like.
  • More flexibility to adapt to emerging information, to changing needs, and to things learned along the way.
  • More say in what they work on, the tools they work with, and how they do their work.
  • Approval of one’s peers (including a sense of belonging and community re: the “technical” tribe)
  • And simply, the leeway to just “do a better job” and make a positive difference in the world.

Bottom line: Many developers need to feel valued, purposeful, that they’re making progress (learning) and are recognised for their abilities. Put another way: Autonomy, Mastery and Purpose.

Business Folks’ Needs

Secondarily, but still important in the Agile approach, is better outcomes for “the business”. Agilists have come to recognise the following needs (even though common forms of Agile do not address them).

  • Approval of one’s peers (including a sense of belonging and community re: the “management” tribe).
  • Empathy (meaningful connection with other human beings).
  • A positive self-image.
  • Stability (folks have families to support).
  • Acclaim/fame (folks have careers to pursue).
  • Warmth (of human relationships) – most business folks are just normal people, too.
  • Peace (i.e. an absence of distress). Even better, eustress, where possible.
  • Purpose.

Users’ / Customers’ Needs

Businesses ultimately stand or fall on revenues. Revenues which depend on their products and services meeting the needs of their customers. These needs include:

  • Approval of one’s peers (including a sense of belonging and community re: the “brand” or “XYZ customer” tribe).
  • A positive self-image (what being a user or owner of a certain product says about you, in your own mind).
  • Stability (folks don’t like to think too hard, or continually learn new stuff for no good reason).
  • Warmth (of human relationships) – Most customers, being humans, value interactions with other human beings.
  • Low fuss (i.e. being able to get their jobs done with minimal distress).

Shareholders’ Needs

Shareholders also have needs which they seek to get met. These include:

  • Approval of one’s peers (including a sense of belonging and community re: the “investor” tribe).
  • Contribution to society (e.g. ethical investments) and communities.
  • Financial returns (investors have families and/or lifestyles to support).

In a future post I’ll be looking at the strategies that people use to get these needs met, including those strategies implicit in Agile methods – and some alternative strategies that might prove

– Bob

 

The Simplest Thing That Could Possibly Work

January 27, 2016
Agile, Flow, Flowchain, Product development
1 Comment

The Simplest Thing That Could Possibly Work

Here’s an excerpt (pp 206) from “Birth Of the Chaordic Age” by Dee Hock, about “an odd project management scheme” they adopted in the early days – circa 1974:

“Swiftly, self-organisation emerged. An entire wall became a pinboard with every remaining day calendared across the top. Someone grabbed an unwashed coffee cup and suspended it on a long piece of string pinned to the current date. Every element of work to be done was listed on scraps of paper with the required completion date and the name of the person who had accepted the work. Anyone could revise the elements, adding tasks or revising dates, providing they coordinated with others affected. Everyone, at any time, could see the picture emerge and evolve. They could see how the whole depended on their work, and how their work was connected to every other part of the effort. Groups constantly assembled in front of the board as need and inclination arose, discussing and deciding in continuous flow; then dissolving as needs were met. As each task was completed its scrap of paper would be removed. Each day, the cup and string moved inexorably ahead.”

I’m struck by the similarities with FlowChain, and as with FlowChain, it seems an exemplar of simplicity and flow. I also note the implicit “Advice Process” vibe, and the emphasis on “making the work visible” (Cf Personal Kanban).

– Bob

Further Reading

Birth of the Chaordic Age ~ Dee Hock

The Twelfth Principle

December 14, 2015
Agile, Antimatter principle, Community, Culture change, Product development, Software development
7 Comments

The Twelfth Principle

There are four values and twelve principles connected with the Agile Manifesto. As the folks at 12thPrinciple say,

“the four values and eleven of the twelve Agile principles do not address the wider organization at all.”

This is one of the key reasons why so many Agile adoptions (circa 80%) fail to deliver on the Agile promise.

I have this weeks added my name to the list of signatories at 12thprinciple.org.  Not because I totally and wholeheartedly embrace the “Twelfth Principle” in its current form. But because I wish to lend support to the idea that it’s the wider organisational context that utterly determines whether any kind of progressive change effort or initiative succeeds or fails.

The Twelfth Principle (n.b. actually appearing fifth in the list of Principles behind the Agile Manifesto) reads:

“Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.”

I see some basic flaws in this, but it does serve to highlight (at least, implicitly) the role of the wider organisation.

Here’s my take on these “flaws”:

  • Projects. I see little point in using projects to frame development efforts. Personally, I subscribe to #NoProjects, and FlowChain as a practical means to replace the whole idea of projects, in favour of product development flow.
  • Individuals. Yes, teams consist of individuals. But Man is a social animal, and collaborative knowledge work – such as software and product development requires society, not individuals. I get the idea that we’re really taking about a focus on people, here. As opposed to say structure, hierarchy, process, or what have you.
  • Give. Not so much give as in charity or largesse, but give as in make available, enable.
  • Them. Shades of them and us? Unfortunate choice of pronoun.

With a free hand, and the awesome benefit of hindsight, I might represent this principle thusly:

“We accept that collaborative knowledge-work proceeds best when we place people at the core of our focus.
We recognise that people do best within a supportive environment,
where needs are shared and attended to by all.”

How might you rephrase this principle?

– Bob

 

 

The Organisational Psychotherapy Approach To Agile Coaching

November 27, 2015
Agile, Coaching, Organisational effectiveness, Organisational Therapy, Software development
2 Comments

The Organisational Psychotherapy Approach To Agile Coaching

What’s the point of an Agile Coach? I guess the most common answer would be “to make development teams more productive”. After all, Agile Coaches cost money, and they don’t do much in the way of development work themselves. If they’re not a “force multiplier” for one or more dev teams, then where’s the cost-benefit justification?

Personally, I’d suggest the most common reason, although rarely articulated as such, is “to raise the pace of improvement”. Or, worst case, to reduce the pace of degradation of performance (given that things are always changing, and some teams may not be able to even keep abreast of change).

There are two essential problems with seeing the appointment of an Agile Coach as a means to improve a development team’s productivity: The Motivation Fallacy and the Local Optimisation Fallacy.

The Motivation Fallacy

Many development teams have little to no manifest interest in improving, nor therefore in the pace of any improvement. This is often compounded or aggravated by the appointment (a.k.a. imposition) of a coach to “encourage” them. An iron first of coercion, even in a velvet glove of a smiling, happy coach, often offends. And rarely is the agenda for improvement part of any joined-up initiative. Much more often it occurs at the behest of one or two people looking to secure their personal bonus or make a name for themselves as innovative go-getters. Such personal agendas also serves to alienate people further, both the folks in the development teams and those folks up-stream and downstream on whose cooperation any joined-up approach would depend.

The Local Optimisation Fallacy

Unless the development team is the current constraint limiting the throughput of the whole organisation, improving the team’s productivity has little to zero effect on the productivity of the whole organisation. Some authorities on the subject go further and suggest that in these (non-bottleneck) cases, improving the team’s productivity will actually make the performance of the organisation as a whole worse. (Cf. Ackoff)

Even when the development team IS the current bottleneck, improving it soon moves that bottleneck elsewhere in the organisation. Agile Coaches and other folks in the development function rarely have the remit or authority to follow that moving constraint. And so rarely if ever does the improvement initiative continue in the newly-constraining area of the business.

Where Organisational Psychotherapy Comes In

Both of the aforementioned fallacies arise in organisations with low levels of congruence. Such organisations have a gulf between how they perceive themselves (self-image), their ideal self, and how they actually experience life. To paraphrase Carl Rogers:

“Organisations behave as they do because of the way they perceive themselves and their situation.”

Where an organisation’s self-image and actual experience are consistent or very similar, a state of congruence exists. Rarely, if ever, does a total state of congruence exist; all organisations experience a certain amount of incongruence.

Organisational therapy serves to help willing organisations reduce the gulf between their self-image and their actual experience. In other words, to improve congruence. Agile Coaches could do this, given the brief (remit) and skills – and some of the more effective ones likely do already. Albeit intuitively rather than with an explicit understand of what’s happening. Oh so rarely is this remit conferred, or sought, however.

The practical side to Roger’s Theory of Self states that being in a condition of incongruence is uncomfortable; therefore each organisation seeks to become more congruent. When the distance between the self-image and actual experience becomes too great, the organisation is more likely to exhibit both distress and anxiety. Likewise the people within it.

Thus organisational therapy helps to:

  • Increase congruence.
  • Reduce stress and anxiety levels.
  • Broadly improve cognitive function (through e.g. lower levels of stress and anxiety).
  • Indirectly, address a wide range of pathogenic beliefs, which in turn may lead to…
    • Improved motivation.
    • Increased collaboration across silos.
    • More joined-up initiatives (fewer local optimisations).

The Therapist’s Stance

All the above is predicated on the Agile Coach – if indeed it is he or she who becomes the agent in this kind of intervention – adopting more of a therapist’s stance:

– Bob

 

A Deliberate Approach

November 11, 2015
Advice sought, Agile, Community, Dialogue
1 Comment

A Deliberate Approach

“Take time to deliberate, but when the time for action has arrived, stop thinking and go in.”

~ Napoleon Bonaparte

In response to your kind questions and comments regarding my previous post, I mentioned that I would be writing a post to address some of those questions and comments. This is not that post (I’m still in the middle of that).

In the meantime, and hopefully to preserve some sense of momentum, might I invite you to advise me on your feelings about approaching the journey ahead (e.g. building a thing we may come to refer to as a community of principle) with a modicum of deliberate intention? Specifically, it has been my habit to follow an approach evolved over many years for this sort of thing. Presently this bears the name “Javelin”. There’s a paper on Javelin which you might care to read. Please accept my apologies in advance for labelling it a process, and for its anachronisms.

In a nutshell, the approach entails, at its heart:

  • Choosing a name, for easy referencing of “this thing which we have come together to build/grow” (Name).
  • Discussing our various perspectives re: our (common) purpose, leading to a Statement of Purpose.
  • Listing key stakeholders and their respective needs (what they say they need, not what we’d like them to need).

The approach aims to address a bunch of risks inherent in this kind of endeavour, including the risk of spending precious time and effort on building the wrong thing(s).

Put another way, what’s the minimum amount of structure that will serve us in approaching our joint endeavour?

How does this sit with you? What advice can you offer me? Upon receipt of this advice I will be better placed to decide whether this kind of  approach might fly, and what else to do instead or in addition.

– Bob

Further Reading

Our Javelin Process ~ Bob Marshall

 

A Second Open Letter to the Project Management Community

October 30, 2015
Agile, Antimatter principle, Community, Fellowship, Open letter, Organisational effectiveness, Product development
Leave a comment

A Second Open Letter to the Project Management Community

Since my first open letter to the Project Management community, some three years ago now, not much has changed. Not that I expected a single blog post to have much impact.

After Agile. What now?

The rising dissatisfaction with the Agile approach – even amongst the Agile community – and the rumblings around the question “After Agile. What now?”, leads me to update my earlier letter, and broaden its scope to address the Agile Community, too.

Dear All

Dear Project Managers and Agilists everywhere,

I hear you continue to have mixed views about the ongoing, er, “developments”, in the field of Software Development. I won’t call them “advances” as we may not be able to agree that they are, in fact, advancing anything. Incidentally, I share some of your likely skepticism on that front.

I am writing to you today to share some opinions and observations about the changes in train in the software development field, globally. Whilst patchy in their uptake, with many a mis-step, changes are afoot. I can relate to your professional concerns that we retain the best of what we have learned from decades of successful project management (this also, we have to admit, being very patchy, too).

Many who look to advance the field of software development also have concerns. Concerns that some of the received wisdom of project management professionals has been rendered redundant or even dysfunctional by recent advances in fields such as psychology, neuroscience, sociology and evidence-based management.

These bilateral concerns have lead to understandable, yet vexing, tensions and misunderstandings between the various communities. Nowhere have these been more evident, perhaps, than between ‘traditional’ project managers and the Agile crowd.

And now, a third faction has also entered the debate. I’ll call these the After Agilists.

I find it helpful to characterise this conflict as a clash of world-views. In a nutshell, a clash between what McGregor has called “Theory X” and “Theory Y”, compounded by the clash between those who believe Agile is all we need for success, and those who recognise the flaws in both “traditional” project management and “conventional Agile” and wish to move on, correcting them as we go

I hope I’m right in thinking that we all share a common objective – a desire to see better outcomes for everyone involved, to see the needs of all stakeholders much better met than has been the case to date. Oh, and maybe improving the levels effectiveness of the organisations within which we work, too (another need, for many).

Whilst it may appear the arguments and contentions arise from our different ways and means for achieving this objective, I’d like to suggest that the conflict – as a product of conflicting world-views – is more deep-seated, and all the more pernicious for that. We can hardly expect folks, of any persuasion, to change their world-views overnight, if at all. Nor blame them for that aspect of their humanity.

And given the fundamental differences between these various world-views, it seems overly optimistic to expect these world-views ever to coexist peacefully and productively.

All we might hope for is a little more understanding, a little less fractiousness, and a future where we can all at least agree to disagree.

More optimistically, we might also realise that everyone has much to learn – and unlearn – from each other. That, perhaps, is something we can all work on together.

Thanks for listening,

– Bob

Further Reading

Power And Love ~ Adam Kahane
Power and Love – RSA video

After Agile

October 21, 2015
Agile, Culture change, Marshall Model, Organisational effectiveness, Organisational Therapy, Rightshifting
2 Comments

After Agile

In recent workshops and conferences I’ve been inviting people to explore the question of “After Agile, DevOps, what now?”

There’s a line of argument, and of exploration, that goes something like this:

Idealised Design

What does the Ideal software development organisation / business look like and work like? If our existing organisation / company / business was totally destroyed last night, what would we choose today in rebuilding it? What are the key concepts and principles that we would choose to focus on in creating our ideal organisation? Cf. Idealised Design, Russell L. Ackoff.

The Role of Mindset

We may find “culture” or “mindset” amongst our idealised key concepts. By which I mean organisational mindset (Cf. Rightshifting and the Marshall Model). If so, then we may want to discover means to “shift” our present organisational mindset towards our ideal model.

Organisational Psychotherapy

How to shift an organisation’s mindset? I propose Organisational Psychotherapy as a means for approaching that in a structured way. What are the issues involves in such a shift? What does therapy have to offer? What does therapy feel like? And what kinds of therapy might suit?

If you’d like to explore these ideas in your own organisation and context, via a workshop or similar, I’d be happy to oblige. Please get in touch.

– Bob

Rightshifting In A Nutshell

October 20, 2015
Agile, Marshall Model, Organisational effectiveness, Rightshifting
2 Comments

Rightshifting In A Nutshell

Folks’ different perspectives can seem very alien to each other.

Whilst in Sweden and Finland last week, I twice had the occasion to present this short (around ten minutes) set of slides, both times in the context of “After Agile”, explaining the very basics of Rightshifting and the Marshall Model. My friend Magnus suggested I turn them into a blog post with some supporting narrative. So here it is.

After Agile, DevOps. What Now?

The Agile approach to software and product development has been around for something like fifteen years now. Its roots go back at least another fifteen years before that. In all that time, more and more folks have tried it out, and more and more of those folks have found it wanting in some degree. This presentation explains where Agile fits in the broader scope of organisation-wide effectiveness, and suggests what needs to change to move on from the Agile approach.

Effectiveness vs Efficiency

Rightshifting observes that most organisations are much less effective than they believe themselves to be, and much less effective than they could be. Let’s not confuse effectiveness with efficiency:

Effectiveness

Doing the right thing.
(creating & deploying value)

Efficiency

Doing the thing right.
(maximising the gain, minimising the cost)

Normal Distribution Assumed

In the chart below, we see a distribution of all the world’s knowledge-work organisations, with respect to their relative effectiveness (horizontal axis). Most folks assume that it’s a normal bell-curve distribution, with some few ineffective organisations (to the left), some few highly-effective organisations (to the right), and the bulk of organisations somewhere in the “average” effectiveness centre ground:

What most folks assume

In actuality, though, the distribution is highly skewed and looks like this:

In actuality

Here (above) we see that fully half of all organisations have a relative effectiveness of less than one (the median), while there’s a long thin tail of increasingly effective organisations stretching out to the right (hence, “Rightshifting”). The most effective (rightmost) organisations are something like 5 times (500%!) more effective than the average (median).

Aside: For those interested in evidence, ISBSG data and NPS data correlate well to this distribution.

Waste (Non-Value Add) And Productivity

Overlaying lines for waste (a.k.a. muda: non-value-adding activities) and productivity on the above chart illustrates the consequences of such ineffectiveness. Median organisations for example are wasting around 75-80% of their time, effort, money and resources on doing things that add zero value from the perspective of any stakeholder:

Where Does Agile Fit?

So, how effective are those organisations that are using Agile (as intended)? Let’s look at where Agile fits on this chart:

As we can see, organisations using the Agile approach span the range circa 1.2 through 2.0. And that’s for organisations in which Agile being done well. (There’s not much point talking about AINO – Agile in Name Only. That buys us nothing in the effectiveness stakes.) The exact position in this range of Agile’s effectiveness depends, in part, on how well the rest of the organisation is aligned to the Agile practices in e.g. the development, ops or DevOps groups within the organisation. Closer alignment = a more effective organisation as a whole.

From the above chart, we can see there’s a whole swathe of effectiveness (from circa 2.0 rightwards) not open to us through the application of the Agile approach. Organisations must find other approaches to access these higher levels of organisational effectiveness.

Explaining Effectiveness

So just what is it that accounts for any given organisation’s position on the Rightshifting Chart? What do the highly ineffective organisations to the left do differently from the average? What do the highly effective (Rightshifted) organisations do differently from the rest? What explains any and every organisation’s effectiveness? It’s very, very simple:

Effectiveness = f(Collective mindset)

That’s to say, any organisation’s effectiveness is a function of its collective, organisational mindset. A function of the assumptions and beliefs it holds in common about work, and how work should work. We can characterise the spectrum of organisation mindsets (a.k.a. memeplexes) into four basic categories: Adhoc, Analytic, Synergistic and Chaordic. This forms the essence of the Marshall Model.

The Adhoc Mindset

Least effective of all the mindsets is the Adhoc mindset. This is characterised by a near-complete absence of organisational structures and disciplines.

Adhoc-minded organisations have no managers, no processes, no standards and no accepted ways of doing things. Every day is more or less a new day, a clean slate, as far as running the business is concerned. In these organisations, the value of discipline has not yet been discovered. I like to think of these organisations in terms of the typical Mom-and-Pop family business.

Some of these organisations, of course – if they, for example, find a profitable niche in which to do their business – can grow despite their ineffectiveness. And with that growth, sooner or later, comes the realisation of the need for some discipline. At this time these organisations will likely start appointing managers, splitting the business into departments (silos) and thereby begin transitioning into the next mindset.

The Analytic Mindset

More effective than the Adhoc-minded organisations, those organisations with an Analytic mindset are typified by the corporates, large and small, that we have come to know and love(?) over the past one hundred years or so.

Central to the Analytic mindset is the belief that organisations are machines, and that just as with machines, if they are broken into parts, with each part performing well, then the whole will perform well. As Russell L. Ackoff (source for this sense of the term “analytic”) points out, this is a fallacy, although one very widely held in businesses everywhere.

Other common beliefs in the Analytic mindset include:

  • Theory X (Douglas McGregor) – people are idle and shiftless and have to be beaten with a stick in order to get any work out of them.
  • Extrinsic motivators such as perks and bonuses enhance performance (demonstrably false in knowledge-work).
  • Managers do the thinking and workers do the doing.
  • Check your humanity, emotions and passion at the door.

Eventually, a few organisations in pursuit of effectiveness may stumble – for it’s rarely intentional – out of the Analytic mindset and into the next mindset – Synergistic.

The Synergistic Mindset

The real uplift in effectiveness starts with an organisation’s transition into the Synergistic mindset. We’ve been hearing about some exemplars of this mindset for years (W.L. Gore, Semco) and others, more recently (Morning Star, Buurtzorg, et al.).

At the heart (sic) of the Synergistic mindset is the belief that organisations are much more like communities than machines. Complex adaptive social systems rather than complicated yet predictable “mechanical” systems. The term “Synergistic” comes from R. Buckminster Fuller, and his statement that the performance of synergistic (synergetic) systems can never be predicted from an examination of their parts considered separately. This is not a comfortable concept for many of those more traditional business people.

Other common beliefs in the Synergistic mindset include:

  • Theory Y (Douglas MgGregor) – people are keen to do a good job, if only they have the opportunity.
  • Intrinsic motivation enhances performance (demonstrably true in knowledge-work).
  • The people doing the work must decide how the work works.
  • Alignment – and effectiveness – is a consequence of a shared, common (and emergent) purpose.
  • Management  – the social technology invented around one hundred years ago – is dead.
  • Bring your humanity, emotions and passion with you into work, every day.

Eventually, a few organisations in pursuit of effectiveness may stumble – for, again, it’s rarely intentional – out of the Synergistic mindset and into the fourth and most effective organisational mindset – Chaordic.

The Chaordic Mindset

Most effective of all are those very few organisations embracing the Chaordic mindset.

Key to the Chaordic mindset is the continual, active, systematic searching for new business opportunities. The term “Chaordic” comes from Dee Hock – the originator of the Visa organisation back in the 1960’s.

The Chaordic mindset inherits from the Synergistic, with some additional common beliefs, including:

  • Dynamic market sweet spots – tracking and exploiting the ever-changing high-margin sweet spots in the market.
  • Instability – always teetering on the cusp between stability (order) and chaos (disorder).
  • Inevitable collapse – occasionally, the organisation will collapse into (temporary) chaos and disorder.

Transitions

Even more interesting than the four mindsets, though, are the three transitions (shown in orange, below). Each transition is an enormous wrench for most organisations.

The Adhoc to Analytic transition is relatively easy, going with the flow, as it were, in that wider society and most people in work mostly believe organisations should be run along the lines suggested by the Analytic mindset. Much more challenging are the other two transitions, being very counter-intuitive for most people.

Where Does Agile Fit In Terms Of Mindsets?

So, where does Agile fit amongst these four mindsets?

Here we can see how Agile straddles the Analytic-Synergistic transition. This explains just why sustainable Agile adoption is so difficult for most organisations. If part of the organisation makes the transition and the remaining parts do not, then Organisational Cognitive Dissonance ensues, and its eventual, inevitable resolution rarely results in the whole organisation shifting its mindset. Much more likely is either a) the now-synergistic part is dragged back, kicking and screaming, into the (old) Analytic ways of doing things or b) the (newly) synergistic folks find they cannot or will not go back, and thus quickly quit for pastures new.

From the above chart we can also see what is to come After Agile: More Synergistic thinking, more of an approach embracing the beliefs of the Synergistic mindset, and for some brave few, Chaordism.

– Bob

 

What If #8 – Agile Never Happened

October 10, 2015
Agile, Organisational effectiveness, Software development, WhatIf
Leave a comment

What If #8 – Agile Never Happened

Alternate realities are a staple of many science fiction series. Exploring what our world might be like if this or that had or hadn’t happened can help shed light on the significance of a particular event.

The Agile approach to software development, although neither conceived nor born at Snowbird in 2001, coalesced and started to gain traction from around then.

What if the Snowbird gathering had never happened? What if the seeds which led to Snowbird had not been planted, or had fallen on barren ground?

Here’s a few hypotheses, or scenarios, to consider:

The Business Hypothesis

Maybe, in the absence of developers trying to wrangle some effectiveness into the work they were obliged to do, business folks might have got a grip. Unlikely, I grant you. But absent some existing movement to suborn or seize upon, maybe the pain of software and product development might have persuaded the “business side” to find better ways of creating and delivering products.

The Together Hypothesis

Maybe everyone involved in software and product development might have got together and pursued the finding of a joint solution. Also unlikely, I guess.

The More Of The Same Hypothesis

Another possibility is that nothing much would have changed. Developers would have continued, more or less frustrated, in prevailing waterfall or ad-hoc projects and ways of working. Outcomes would have continued to be poor for all concerned. Some may say that this is really what did happen, only the names have been changed.

The Extrapolation Of Prevailing Trends Hypothesis

Maybe trends prevailing circa Y2K would have continued to evolve. Organisations seeking to improve might have embrace and evolved things like project management, CMMI, and so on. I can’t see this as effecting significant change or improvement, but maybe things might have improved slowly, in the order of a percentage point or two annually.

The Radical Hypothesis

Finally – in the list of alternate realities I’m presenting here – we might have seen a (more) radical alternative to Agile arise. Without convenient, ready-made, and packaged “Agile solutions” to adopt, maybe folks who cared might have studied their problems for themselves. Maybe this study might have found the root conditions. Maybe it might have surfaced more radical, more fundamental solutions. Solutions explicitly directed at communities of collaborative knowledge work, at the core role of collective mindsets, people and relationships, and at a system (business) wide approach to both adoption of new approaches and the ongoing use of those approaches.

What do you imagine might have happened if Agile had never been?

– Bob

Other Posts In This Occasional Series

What If #1 – No Management
What If #2 – No Process
What If #3 – No Telling
What If #4 – No Answers
What If #5 – Continuous Improvement Is Useless
What If #6 ~ Agile Nirvana
What If #7 – No Work

What If #6 – Agile Nirvana

September 30, 2015
Agile, Organisational effectiveness, WhatIf
Leave a comment

What If #6 – Agile Nirvana

Let’s assume, for one wonderful moment, that Agile has delivered on all its promises. 100%. For everyone that’s tried it. Everywhere. In all its infinite variety of hues and flavours.

Is it enough? Is better quality software, delivered faster, at lower cost, and with happier developers, testers, users, sponsors and management all, enough?

If true, would we be in heaven? In nirvana? In Jannah? In Shamayim?

Would we then stop trying to improve, and be happy with our eternally blissful Agile state? Would we just, then, stop fussing and discussing about better ways of doing things, and get down to forever more just cranking out the code?

What say you?

– Bob

Other Posts In This Occasional Series

What If #1 – No Management
What If #2 – No Process
What If #3 – No Telling
What If #4 – No Answers
What If #5 – Continuous Improvement Is Useless
What If #7 – No Work
What If #8 – Agile Never Happened

 

My Definition Of Agile

September 25, 2015
Agile
4 Comments

My Definition of Agile

I have seen many people define “agile” (or, more often, “Agile” with a capital A). I wonder why this is such a common topic. I suspect it’s because we see such a wide range of definitions, and, by implication, a huge variety of imagined purposes for “Agile”.

Purpose

What’s spurred me to offer my own definition, here? What purpose might this post serve?

I offer it to pique your interest. Maybe my definition is so different from yours that you might wonder why the gulf. And to serve as a future reference, in case someone might ask me “What do you mean by Agile?”.

Definition

Fundamentally, “Agile” is a label characterising a certain self-consistent collection of beliefs(1). Beliefs about what matters in being effective in developing software and software-intensive products(2). Each person, team and organisation will have their own collection of beliefs under the “Agile” label. Setting aside the varies differences between each of these sets, in toto these beliefs are sufficiently different from the norm (the collection of beliefs about work prevailing in most workplaces) to warrant a distinguishing label(3).

(1)This collection of beliefs generally includes some or all of the following memes:

  • Continuous Improvement.
  • Theory Y (McGregor).
  • People and their human relationships are the engine of productivity.
  • Diversity.
  • Learning.
  • Trust.
  • We can only know if we’ve built something that meets folks’ need by letting them experience it.
  • Early and frequent feedback (implies e.g. small units of work, high availability of customer proxies)
  • Iteration.
  • Collaborative knowledge work.
  • Inspect and adapt.
  • Eagerness to anticipate and embrace changes of direction.
  • Self-organisation.

(2)Although on the face of it Agile is about software development, that in itself is a tad misleading, as software development itself is really about creating experiences for folks, and, more fundamentally, about meeting folks’ emotional needs.

(3)In the Marshall Model, the collection of beliefs generically labelled “Agile” situates approximately at rightshifting index 1.2-1.8, and thus straddles the boundary, or transition zone, between the broader collections of beliefs labelled “Analytic” (roughly, 0.5-1.5) and “Synergistic” (roughly, 1.2-3.5).

In A Nutshell

In a nutshell:

“Agile labels a certain way of people relating to each other, rooted in a collection of more-or-less shared beliefs – beliefs more suited (than the norm) to effective collaborative knowledge work”

– Bob

I’ve Done It So It Works

September 9, 2015
Agile
1 Comment

I’ve Done It So It Works

“I’ve done it so it works” and its close cousin “I’ve seen It so it works” are two arguments that often form the first line of defence from supporters of a particular approach to doing a thing. I appreciate people trying to help others with stories about what worked for them – although proselytising, not so much.

And as a defence, it bears little scrutiny, for the following reasons at least:

  • Even if it worked for you, in your context, there’s no reason to suppose it will work for others, in their context.
  • That was then, this is now. Time moves on, as does knowledge.
  • The thing you were doing may have been a success despite the way you were doing it, not because of it. Can you really state cause and effect unequivocally? Especially in a Complex Adaptive System?
  • You may not have been doing X at all, despite your belief that that was what you were doing.

And why be defensive anyways? It’s not like your ego or worth as a human being is on trial. Even though it can often feel like that.

“All defensiveness and emotional tumult is a fear response because of your need for acceptance and ruthless control of the territory of your safe fantasy world.”

~ Bryant McGill

– Bob

The Cold Wet Nose Of Reality

September 8, 2015
Agile, DevOps, Organisational effectiveness, Product development, Software development
1 Comment

The Cold Wet Nose Of Reality

If you’re in the business of supplying IT services, especially software and product development, to your clients, you may be getting uneasy (again). Agile software development, and its close cousin, DevOps, are the latest in a long line of approaches promising to solve the “software crisis”. And like the many approaches that have gone before, their faults are beginning to show, and the chickens are coming home to roost.

As they say:

“…you can’t fool all of the people all of the time.”

I don’t doubt that many solutions providers and consultancies have the best interests of both their clients and their own staff at heart, and are not just focused on their revenues. And just like their antecedents, Agile and DevOps did look promising. But just as with those antecedents, time has shown the core ideas wanting. Or, more accurately, insufficient in the majority of cases.

Why Early Adopters Have Good News

Whatever the approach, its early adopters generally have good stories to tell, about good outcomes. And why not? These folks had the enthusiasm, the curiosity, the drive, and the grasp of the principles to make the approach work. Later adopters, absent some or all of these advantages, have struggled to see useful benefits. No matter what the approach.

That Nose

Truly, the cold wet nose of reality has been sniffing out the latent flaws implicit in Agile and DevOps from the outset.

Smarter Now

I’d like to hope that we’re collectively smarter now. That having seen so many promising approaches come and go, we might be on the verge of seeing beyond the superficial attractions of each new approach. That we may be, finally, developing the deeper lore that will show us why all our approaches to date have sooner or later failed us. I’d like to hope that, But in general, I see precious little evidence of it happening.

“A new type of thinking is essential if mankind is to survive and move toward higher levels.”
~ Albert Einstein

– Bob

The Agile Enterprise Is A Thing But Not THE Thing

September 6, 2015
Agile, Marshall Model, Organisational effectiveness, Rightshifting
3 Comments

The Agile Enterprise Is A Thing But Not THE Thing

A Thing

Many proponents of Agile in the field of software development suggest that the whole enterprise (company, firm, organisation, business) could benefit from adopting Agile – i.e. the principles set out in the Agile Manifesto – across the board. I suspect that most of these proponents have little to no clue about the realities of running a business.

For sure, the idea of a whole business – including e.g. Sales, Legal, HR, Finance, and more again – becoming “agile” sounds attractive. The fourth item of the Agile Manifesto seems most relevant here:

“[We have come to value] Responding to change over following a plan.”

In today’s business climate, who would not wish for a business that could better respond to the vicissitudes of the market, technology and people? That could better adapt its plans in the face of change? That could duck, dive and spin on a dime to keep in the “sweet spot” of maximum customer satisfaction, sales, revenues, costs, quality and profits?

Agility with a small “a” – and the agile enterprise – that’s a thing.

THE Thing

Few indeed are the Agile adoptions – even in the limited confines of the software development business unit – that succeed in a sustainable way. Jeff Sutherland, one of the originators of Scrum, suggests that less than 25% of Scrum adoptions succeed, longer term.

Aside: I use the term “succeed” here to mean “realise the benefits or beneficial outcomes that people were seeking”.

To understand why the Agile Enterprise is not THE thing, we might do well to understand the implications of adopting e.g. Agile principles.

I have written much about this here in this blog, but to sum up:

Successfully and sustainably adopting Agile ways of working means adopting Agile ways of thinking and being – ways diametrically at odds with the ways of thinking and being typically seen in most organisations.

I describe those ways of thinking and being – ways congruent with Agile – as “Synergistic”, and those ways typical of most organisations as “Analytic”.

These two ways of thinking and being CANNOT exist for long in the same organisation. Sooner or later (with a half-life of circa nine months) something has to give. Most often, it’s the Agile ways of thinking and being that have to go, not least because those who hold the whip hand (shareholders, senior management, the Core Group) cleave so firmly to the Analytic mindset.

Synergism – that’s THE thing.

Hints

Whilst Agile hints coquettishly at the Synergistic, Agile memes comprise a very small subset of the Synergistic memeplex. For example, Synergism as a memeplex (a.k.a. mindset) contains many memes concerning people and their relationships with each other, memes barely hinted at in the Agile memes.

The Synergistic Enterprise

So when we see the advantages of Agile and wish to see those advantages conferred on our long-suffering businesses (and shared with their long-suffering people) we may leap to labelling that “the Agile Enterprise”, but in fact we’re really talking and thinking about something else – the Synergistic Enterprise.

Why does what we call it matter at all? Well, for me it matters because attempting an Agile adoption across the Enterprise, couched in those terms, is bound to fail. Whereas, if we understand what we’re actually trying to achieve – a wholesale adoption of the Synergistic mindset – we may just have a chance of pulling it off.

– Bob

Further Reading

Rightshifting Transitions (Part 2 – Analytic to Synergistic) ~ FlowchainSensei

Meeting Folks’ Needs At Scale

August 20, 2015
Agile, Antimatter principle, Flowchain, Product development, Software development
Leave a comment

Meeting Folks’ Needs At Scale

Scaling Agile is one of those oxymorons that has, nevertheless, consumed endless column-inches and hours of debate. I have no time for it. Agile was meant for development-in-the-small. For teams of five to seven people, give or take. Even at that “scale”, I have serious reservations about its efficacy and effectiveness. The idea of scaling it up to multiple dependent teams, or even to whole development departments or groups of hundreds or thousands of people, seems just crazy.

The Demand

Yes. There are organisations with hundreds or thousands of developers working on more or less dependent things. Huge systems. Ginormous products. And these organisations have problems. Boy, do they have problems. They’ve had the same kind of problems for decades now. Advances in tech and tools seems to have made little dent in those problems. Similarly, advances in methods and processes have barely scratched the surface.

So there is a demand. A demand for something better. A demand for a packaged solution that can be simply (ha!) “installed” and run with. And the folks with the problems have money. Lots of money. Bags of moolah.

No wonder it looks like an interesting problem to solve. The thing is, I don’t see many people, either on the demand or the supply side, that actually understand the nature of the problem.

Absent an understanding of the problem, and given their desperation, the demand side will embrace any and all solutions that bear even a vague whiff of credibility. And the “Agile” label these days confers that smell.

Needs

All product development is, in essence, an exercise in attending to folks’ needs. The more kinds of folks with needs, the more of their needs we bring into scope, and the quicker we want to see those needs met, the more people we might choose to commit. The question of agile (or not) is a huge irrelevance. Things like communications overheads, coordination, partitioning of needs, a regular cadence, flow, and effective use of resources (time, money, equipment) hold sway. TPDS had these issues sorted out (mostly) years ago with e.g. the Obeya or “big room” concept, set-based concurrent engineering, etc.

I have suggested that something like FlowChain might afford an effective model for organising to meet folks’ needs at scale. I have yet to hear anyone suggest why this model is flawed. Until that day, I will continue to invite you to consider its merits.

The demand side continues to have needs that are not being well-met (due to e.g. a host of pathological beliefs). The supply side has needs that are being more-or-less well met by selling solutions largely disconnected from the real problem. Scaling agile seems to me a very one-sided, cynical and exploitative bargain.

– Bob

Further Reading

Moving Past the Scaling Myth ~ Michael Feathers
Lean Product and Process Development ~ Allen Ward

What If #5 – Continuous Improvement Is Useless

August 14, 2015
Agile, Antimatter principle, Community, Organisational effectiveness, WhatIf
6 Comments

What If #5 – Continuous Improvement Is Useless

What if our faith in continuous improvement is misplaced? What if one of the central tenets of Lean and Agile ways of working is just a delusion? Cargo culting? What if knowledge work is sufficiently unlike manufacturing that the whole idea of continuously and incrementally improving the way the work works has no payback? No point? What if, indeed, it’s useless – or even actually harmful?

Definition

For the avoidance of confusion, let me define what I mean here by “continuous improvement”. In general, I mean any change to the way we work, collectively, that makes us in any way more effective. That is, any change to a certain kind of task, or practice, which reduces the time and effort we take to get a certain kind of thing done.

For example, I saw one team swap out Planning Poker in favour of Silent Grouping, saving maybe 30 minutes * 10 team members = 5 hours for every fortnightly sprint planning session. On the face of it, this seems a small, but useful, improvement to the way the work works. But was it, really?

Some Of The Issues

Stepwiseness

If the working domain is merely complicated, as is largely true for production lines in a factory, then a standard process might make sense. Assembling e.g. a car has many steps, but those steps are largely definable. Improving any single step is fairly straightforward. Shorten the bolt to reduce the number of turns required to reach the necessary torque setting. Redesign the part(s), replacing the bolt and nut, or threaded hole, with a snap or push-fit fastener, thus speeding the operation (step) and maybe saving on parts costs too. Work in a complex domain, such as much of knowledge work, whether collaborative or not, does not much resemble this scenario.

Experimentability

In manufacturing, a standard process is relatively straightforward to sustain. Jobs (steps) are pretty much self-contained, and simple for new workers to pick up. Experiments (with e.g. improvements) are fairly simple to conduct. Cause and effect are fairly obvious. Change a thing. See (objectively) if that change makes a positive different. Again, knowledge work, particularly collaborative knowledge work, is not much like this. Change a thing. And guess whether the thing you changed made any kind of difference. Or did the difference (if detectable) come from a myriad of other uncontrolled – and uncontrollable – factors?

Distraction

All the time we buy into the assumption that continuous improvement is something we want, we’ll naturally spend time on trying to make it happen. Time which might perhaps be better spent on other aspects of making ourselves, or team and our organisations more effective. How many teams, organisations have any idea what continuous improvement is doing for them and their relative effectiveness? And even for those few that do, how often is continuous improvement a delusional frame, obscuring other reasons for the improvements they track?

Marginality

Even when a change does bring some positive uplift to effectiveness (or even efficiency), that uplift is most often marginal. Maybe we could better use our time, effort and focus on seeking out changes that bring a significant uplift to effectiveness. These may be rarer and more difficult to find, but maybe the payback is, overall, more worth having.

Irrelevance

Often, I’ve seen folks make a change which does bring some notional benefit, but not a benefit that translates to the better meeting of anyone’s needs. This is called out in e.g. Theory Of Constraints as “improving a non-bottleneck” and is a total waste of time, and money. The need to be seen to be improving something every day is a need in itself, of course. <wry smile>

Sustainability

For me, this is the biggest issue. If “process” is indeed “one of those concepts from manual work a.k.a. manufacturing that has no place or value in knowledge work“ then even if we find an improvement that looks worthwhile, by what means do we “lock it in” for the future? The core premise of continuous improvement is that we build effectiveness, improvement upon small improvement, over time. By this path we become ever more effective. As a team, as a group, as an organisation, as an industry, as a society. I now question this assumption. I’ve never seen it work in practice. Not over the long haul. Humans, individually and collectively, are just too fickle, inattentive, capricious and random, Yes, we can continuously improve a machine. Continuously swapping out less effective parts for upgrades, like with an F1 car. But a complex adaptive social system is NOT a machine. Nothing like. And not much like a process, either.

Alternative Frames

Can we imagine an alternative to continuous improvement, as we generally understand it? How might we possibly become more effective without improving this step or that practice in the way our work works?

Just by way of an example, how about we focus instead on improving the quality of relationships in the workplace, both within teams and across teams? How about we focus on introspection and mindfulness in the hope of becoming “better” (more capable, more effective) people? How about we work on being more skilled at dialogue? How about we apply ourselves to (better) understanding some (more) of the principles underpinning the way the work works? How about we work on improving the healthy functioning of the complex adaptive systems we call “work”? How about we continuously examine our collective assumptions and their fitness to our shared goals?

These are all ways to improve, ways which lie outside the traditional scope of what we call “continuous (process) improvement”.

What if our unexamined assumptions around the value of continuous improvement are in fact a major blocker? For those of us who seek more effective knowledge-work organisations, maybe continuous improvement isn’t the most effective way to get there. I leave you with the following timeless wisdom:

“The unexamined life is not worth living.”

~ Socrates

– Bob

Further Reading

Why Continuous Improvement May Need To Be Discontinued ~ Ron Ashkenas
What’s the Problem with Continuous Improvement? ~ LeanCor article
How Continuous Improvement Went Horribly Wrong, for Some ~ Alan Nicol

Other Posts In This Occasional Series

What If #1 – No Management
What If #2 – No Process
What If #3 – No Telling
What If #4 – No Answers
What If #6 ~ Agile Nirvana
What If #7 – No Work
What If #8 – Agile Never Happened

 

Are You Just Another Adjunct Of A Unimatrix?

August 3, 2015
Agile, Antimatter principle, Organisational effectiveness, Psychology
Leave a comment

Are You Just Another Adjunct Of A Unimatrix?

Are you a drone? Are you amenable to being programmed and reprogrammed? Can someone change your behaviours by simply uploading a different code package? Or by swapping out your knowledge database for another one?

Yet how often do you find yourself being treated as if this were true? As if you were no more than a tiny, swiftly replaceable cog in some faceless bureaucratic machine?

What About Adoption?

Methodologists of all stripes seem to behave as if adoption of their shiny method, process or tool were a given. Create a method that promises to “deliver value to customers faster” and then just believe people will find a way to adopt it. Ideally with lots of expensive consultancy as part of the deal. Or, more naively still, believe that people can be reprogrammed through e.g. training, presentations, documentation, change programmes, extrinsic motivators and managerial edicts to change the way they behave.

I have yet to see even a single method that pays any attention at all to the issues of adoption. Uptake. Transition. Let alone to the sustainability of such adoptions.

It’s About Psychology

I posit this blindness to the issues of adoption arises because, even though a method is seen as largely a process issue, adoption is seen as largely a psychology issue. And process wonks don’t grok psychology. Not at all.

The Antimatter Transformation Model

My previous post introduced a series of transformative questions. Questions which can lead to fundamental transformation of an organisation – the way it works, and the way it thinks. And a consequent fundamental transformation in its effectiveness, too.

What We Now Know About People

What the scientific community “knows” about people, how they relate, socialise and work together, how the brain works, what motivates people, and so on, has changed markedly in recent times. What the general population believes about these topics now lags way behind the science. The Antimatter Transformation Model’s questions emerge from a background of more than a hundred years of Mankind’s directed research into people and how they tick. Specifically:

  • People naturally form ingroups around a sense of shared common purpose.
  • People are almost entirely driven by emotions (primarily seated in the amygdala), rather than logic (the neocortex). Cf. Kahneman, Ariely, Goleman, Lindstrom, et al.
  • People like to have a sense of agency.
  • Folks’ behaviours stem from trying to get their needs met (in the best ways they know how). Cf Nonviolent Communication
  • Collaborative work stands or falls on the quality of the interpersonal relationships between the folks involved.
  • Folks rarely examine their personal or collective assumptions.
  • Collective assumptions limit the strategies available to folks for getting their needs met.
  • Changing folks’ strategies for getting their needs met requires normative learning (learning by doing) and support with e.g. meta-strategies. Cf Seddon, Schwartz-Hebron.
  • Effective cognitive function depends on low distress, high eustress and intrinsic motivation.

– Bob

Further Reading

Watch Out For The Toolheads ~ John Seddon

Tech Folks Don’t Grok People Things

June 9, 2015
Agile, Antimatter principle, Psychology, Software development
4 Comments

Tech Folks Don’t Grok People Things

Nor do they often grok the connection between attending to their own and others’ needs, and the grokking of people things.

Tech Folks Focus On Tech

Let’s face it, most folks in IT (a.k.a. software development) made it their career choice because they like tech. Personally, I started programming way back when because I liked making little coloured lights flash on and off at my command.

And although liking tech doesn’t necessarily preclude grokking people things, in practice it generally does.

People Things Trump Tech

Yet it’s the people things that make all the difference when it comes to non-trivial, collaborative knowledge work. Such as teams building software systems and solutions. Questions like “What accounts for the way folks behave?”, “How can we work together?” and “Why is everything so borked round here?”.

Some tech folks wake up to the primacy of people things sooner or later. And it’s rarely a pleasant awakening.

Of course, this is not a phenomenon limited to tech people. Most managers I’ve met haven’t grokked people things either. Nor politicians. Nor scientists. Nor intellectuals. Nor…, etc.

Maybe the truest irony is that people, in general, don’t grok people things.

– Bob

Some Homos

June 5, 2015
Agile, Ethics, Philosophy
Leave a comment

Some Homos

What is Man?

“There are depths in Man that go down to the lowest hell, and heights that reach the highest heaven.”

~ Martin Luther King, Jr.

I’ve come across various takes on the question of “What is Man?” These include:

Homo Sapiens

More specifically, Homo Sapiens sapiens. Homo meaning man, and Sapiens meaning wise. I find a certain irony in this name.

Homo Economicus

Man as a species of rational and narrowly self-interested actors who have the ability to make judgments toward their subjectively defined ends. A.k.a. Homo Averiticus. I don’t buy this one at all.

Homo Biologicus

Man as a species shaped by biological processes such as natural and sexual selection.

Homo Narrans

Man as a species of story-tellers (and listeners). A collection of “individuals that develop a group consciousness around a problematic situation and act to solve the problematic situation”.

Yes, we tell and listen to stories. But as a defining characteristic? Hmmm.

Homo Evolutis

Man as a species that is taking control of its own evolution. See this article and related TED talk.

Homo Empathicus

Man as species predicated on empathy. Cf. Theory of Mind.

Homo Becoming

When Heraclitus looked at Nature he saw not stability or permanence, but incessant flux and transformation. This is a perspective in which I find much comfort. Man as a species forever part of Nature, of the Cosmos or wider universe, forever becoming something. Not a human being, but a human becoming.

I also like the implication that everyone is capable of becoming more than they are. A species of Infinite potential. A species with a growth mindset (cf. Dweck).

So What?

Would you be willing to consider how you see Man as a species? And how that colours your world, your relationships and your life?

– Bob

Further Reading

What Is Man? ~ Martin Luther King, Jr.
The Empathic Civilisation ~ Jeremy Rifkin (RSAnimate video)
Mindset ~ Carol Dweck

 

Parlour Tricks

May 27, 2015
Agile, Lamentation
11 Comments

Parlour Tricks

A “parlour trick” is another name for a simple magic trick, something folks used to entertain their family and friends on those long winter evenings back in the day.

“Because a parlour trick is simple and easy to learn, a parlour trick often spreads quickly through a community, with people picking it up at gatherings and introducing it to new groups.”

Oooh, Shiny!

Here’s some parlour tricks that have been doing the rounds over the past few years:

  • Agile
  • Scrum / Scrumban / Etc.
  • Cynefin
  • Options – real or otherwise
  • Management 3.0
  • Rightshifting & the Marshall Model
  • TDD
  • BDD
  • Retrospectives
  • Brainstorming
  • Standups
  • Kanban & the Kanban Method
  • Scaled Agile (SAFe, LeSS, EssUP, SEMAT, etc.)
  • Organisational Psychotherapy
  • Person Kanban
  • XP and the 12 practices
  • Argyris (Action Science etc.)
  • Clean Language
  • Solutions Focus

Note: I provide this list by way of illustration, rather than as an exhaustive catalog.

Passing Off

What’s wrong with entertainment? Not a thing. Excepting when it’s passed off as something else. When the gullible don’t realise it’s a cheap trick and believe it e.g. reveals some essential truth about the nature of reality. Or get gulled into believing it could be of practical use to them. A bit like the difference between a Clown Car and a real car.

– Bob

Further Reading

Why Do People Conform To The Herd? ~ Adi Gaskell