Archive

Agile

Five Reasons Why Agile Coaching is Bullshit

By popular demand, here’s a short post expanding on a recent pithy tweet of mine:

“Agile coaching” is bullshit – for various reasons.”

1. Agile is a Means to an End, not the End In Itself

“Software development coach” might be a (slightly) less bullshit title. For many organisations, and people, quick and cheap software development is the goal. Setting aside why “software is the goal” in itself is a bullshit concept (see: #NoSoftware), “Agile coaching” implicitly excludes other approaches and other means to improving software development. Other approaches which have proven more effective than Agile. And other approaches which the players (coachees) might reasonably seek to explore or experiment with, yet find themselves unable so to do because those other approaches are deemed beyond the pale. Why not start down a road towards the goal that matters (better products, higher margins, more profits, to make money now and in the future or even – and most realistically – maximising the bosses’ well being), instead of driving into the Agile cul-de-sac?

2. Individual Technical Focus

As coaches, (in theory) Agile coaches follow the interests of the folks they’re coaching. In most coaching contexts (i.e. outside of the software domain) coaches have no agenda of their own beyond assisting their players (coachees) grow and develop their skills and abilities – as those players themselves see fit. In practice, technical folks generally seek to develop their individual technical skills and abilities – which hardly matter in the grander scheme of things, such as from the broader business perspective) – and recoil from any suggestion that other skills and abilities might also be important. Things like interpersonal skills, dialogue skills, business skills, serving the needs of the users and other folks that matter, etc..

3. Agile Coaching is an Imposition

I’ve never seen an Agile coach get hired at the request of the people they’ll be coaching. Nor selected by the folks they’ll be coaching. I hear it happens, but so rarely as to be an extreme anomaly.

4. Coach as Manager

There’s a lot of talk about (middle) managers becoming coaches to their people. In most practical scenarios, Agile coaches are expected by the people that appoint them to become managers of the people they’re coaching. I’d call that regressive. And bullshit.

5. Kaizen vs Kaikaku

In theory (for example, with Scrum), Agile coaching supports the team in reaching out across the organisation to address systemic issues affecting the team’s performance (kaikaku). In practice, for all the above reasons, this almost never happens. The Agile coaches, sensitive to not biting the hands that feed them, avoid raising issues that might disrupt other parts of the organisation, and limit their focus on improvements local to their team (kaizen). Which is entirely understandable, given the coaches’ brief and the dynamic of their position (who’s paying them and keeping them in a job). As Shakespeare wrote :

“To be [remain in a job, helping locally], or not to be [rocking the boat and being vilified and let go]: that is the question:
Whether ’tis nobler in the mind to suffer
The slings and arrows of outrageous fortune [refrain from raising thorny organisation-wide issues],
Or to take arms against a sea of troubles [raise those issues and thanklessly suffer the consequences],
And by opposing, end them? [’Tis a consummation devoutly to be wished.]“

– Bob

Beyond Command and Control – A Book Review

BeyondCommand&ControlCover

John Seddon of Vanguard Consulting Ltd. kindly shared an advance copy of his upcoming new book “Beyond Command and Control” with me recently. I am delighted to be able to share my impressions of the book with you, by way of this review.

I’ve known John and his work with e.g. the Vanguard Method for many years. The results his approach delivers are well known and widely lauded. But that approach is not widely taken up. I doubt whether this new book will move the needle much on that, but that’s not really the point. As he himself writes “change is a normative process”. That’s to say, folks have to go see for themselves how things really are, and experience the dysfunctions of the status quo for themselves, before becoming open to the possibilities of pursuing new ways of doing things.

Significant Improvement Demands a Shift in Thinking

The book starts out by explaining how significant improvement in services necessitates a fundamental shift in leaders’ thinking about the management of service operations. Having describe basic concepts such as command and control, and people-centred services, the book then moves on to explore the concept of the “management factory”. Here’s a flavour:

“In the management factory, initiatives are usually evaluated for being on-plan rather than actually working.”

(Where we might define “working” as “actually meeting the needs of the Folks that Matter”.)

Bottom line: the management factory is inextricable bound up with the philosophy of command and control – and it’s a primary cause of the many dysfunctions described throughout the book.

Putting Software and IT Last

One stand-out section of the book is the several chapters explaining the role of software and IT systems in the transformed service, or organisation. These chapters excoriate the software and IT industry, and in particular Agile methods, and caution against spending time and money on building or buying software and IT “solutions” before customer needs are fully understood.

“Start without IT. The first design has to be manual. Simple physical means, like pin-boards, T-cards and spreadsheet.”

If there is an existing IT system, treat it as a constraint, or turn it off. Only build or buy IT once the new service design is up and running and stable. Aside: This reflects my position on #NoSoftware.

John echoes a now-common view in the software community regarding Agile software development and the wider application of Agile principles:

“We soon came to regard this phenomenon [Agile] as possibly the most dysfunctional management fad we have ever come cross.”

I invite you to read this section for an insight into the progressive business perspective on the use of software and IT in business, and the track record of Agile in the field. You may take some issue with the description of Agile development methods as described here – as did I – but the minor discrepancies and pejorative tone pale into insignificance compared to the broader point: there’s no point automating the wrong service design, or investing in software or IT not grounded in meeting folks’ real needs.

Summary

I found Beyond Command and Control uplifting and depressing in equal measure.

Uplifting because it describes real-world experiences of the benefits of fundamentally shifting thinking from command and control to e.g. systems thinking (a.k.a. “Synergistic thinking” Cf. the Marshall Model).

And depressing because it illustrates how rare and difficult is this shift, and how far our organisations have yet to travel to become places which deliver us the joy in work that Bill Deming says we’re entitled to. Not to mention the services that we as customers desperately need but do not receive. It resonates with my work in the Marshall Model, with command-and-control being a universal characteristic of Analytic-minded organisations, and systems thinking being reserved to the Synergistic– and Chaordic-minded.

– Bob

Further Reading

I Want You To Cheat! ~ John Seddon
Freedom From Command and Control ~ John Seddon
The Whitehall Effect ~ John Seddon
Systems Thinking in the Public Sector ~ John Seddon

The Big Shift

Let’s get real for a moment. Why would ANYONE set about disrupting the fundamental beliefs and assumptions of their whole organisation just to make their software and product development more effective?

It’s not for the sake of increased profit – Deming’s First Theorem states:

“Nobody gives a hoot about profits”.

If we believe Russell Ackoff, executives’ motivation primarily stems from maximising their own personal well being a.k.a. their own quality of work life.

Is There a Connection?

Is there any connection between increased software and product development effectiveness, and increased quality of work life for executives? Between the needs of ALL the Folks That Matter and the smaller subset of those Folks That Matter that we label “executives”? Absent such a connection, it seems unrealistic (understatement!) to expect executives to diminish their own quality of work life for little or no gain (to them personally).

Note: Goldratt suggests that for the idea of effectiveness to gain traction, it’s necessary for the executives of an organisation to build a True Consensus – a jointly agreed and shared action plan for change (shift).

Is Disruption Avoidable?

So, the question becomes:

Can we see major improvements in the effectiveness (performance, cost, quality, predictability, etc.) of our organisation, without disrupting the fundamental beliefs and assumptions of our whole organisation?

My studies and experiences both suggest the answer is “No”. That collaborative knowledge work (as in software and product development) is sufficiently different from the forms of work for which (Analytic-minded) organisations have been built as to necessitate a fundamentally different set of beliefs and assumptions about how work must work (the Synergistic memeplex). If the work is to be effective, that is.

In support of this assertion I cite the widely reported failure rates in Agile adoptions (greater than 80%), Lean Manufacturing transformations (at least 90%) and in Digital Transformations (at least 95%).

I’d love to hear your viewpoint.

– Bob

Further Reading

Organisational Cognitive Dissonance ~ Think Different blog post

Congruence

What if the last twenty years has been another classic example of software developers solving the wrong problem?♥

What if “agility” was never the issue as far as business was and is concerned? What if business agility is NOT the most useful response to, or strategy for, life in a VUCA world?

We hear so much about the need for agility. It’s now a given, an unchallenged assumption. Maybe even an undiscussable assumption? Well, I’m challenging it. And in the spirit of this blog – always having an alternative to offer – I propose congruence as a more useful response to the challenges of a VUCA business environment.

Agility: the power of moving quickly and easily; nimbleness.

Congruence: Similarity between self-image and actual experience.

Carl Rogers stated that the personality is like a triangle made up of the real [or actual] self, the perceived self, and ideal self. According to Rogers, when there is a good fit between all three components, the person has congruence. This is a healthy state of being and helps people continue to progress toward self-actualisation.

Applied to organisations, we can say that an organisation is made up of the real [or actual] organisation, the organisation as it perceives itself, and its ideal self. When there is a good fit between all three components, the organisation has congruence. This is a healthy state of being and helps the organisation progress toward being all it can be.

Without congruence, organisations won’t know what to do with agility, or how to get it. Without congruence, a VUCA environment presents challenges which incongruent organisations are poorly equipped to meet.

So, forget the past twenty years and the search for agility. Congruence is the thing.

– Bob

Footnote

♥ It was a bunch of software developers that invented and promoted the idea of agility (for software development) some twenty years ago now. Businesses everywhere have seized on this prior art in their attempts to cope with the upswing in perceived volatility, uncertainty, complexity and ambiguity in the business environment.

PS

The same argument also applies to the birthplace of the agility meme: the software development silo. Forget the past twenty years and the search for development agility. Congruence is the thing.

Management Must Manage

Years ago, when I was starting out in my study of management methods, I came across ITT and its then president, Harold S. Geneen. Setting aside his connection with Phil Crosby and the ZeeDee (Zero Defects) quality movement, Geneen was famous for many things, including one quote which has stuck with me ever since I first heard it:

“Management must manage.”

What a soundbite!

Taken at face value, it’s a homily. Management must manage. Those with management responsibilities must execute those responsibilities (rather than dicking around with other things). “Well, of course. What else would they do?”

But there’s another meaning I choose to also find within. Management must manage: when we have people appointed to management positions, those people are the ones that must manage, not some others.

The whole Agile shambles, most often labelled AINO (Agile In Name Only), stems largely from ignoring this second interpretation of Geneen’s admonition.

Early Agilists, wanting to escape from the oversight of managers who had different opinions about how to manage software development, created Agile to wrest de-facto management responsibility from those managers. Thus grew the lame-assed version of self-organisation and self-managed teams so widespread today. I say lame-assed because almost no Agile team is self-managed. How could they be, when managers still have the authority and positional power to manage?

So we have instead a festering conflict of responsibilities, causing confusion and resentment all around, and dragging down engagement and productivity. Agile can “work” when the split of management responsibilities are made crystal clear for all concerned. And when that split has the blessing of management. This is almost never the case.

So, management must manage. Not developers. Not dev teams.

That sucks. Until we realise that it can be no other way. And even then, it still sucks, unless dev teams themselves have the responsibility and authority to manage. Where the dev teams are the management. Then we have the best of both worlds. A world of autonomy, mastery and purpose. A world of engaged people aligned to a common purpose and a common approach.

– Bob

Random Walks

How well does the almost universal Agile practice of “build it and see if they come” serve us (as developers, as customers)?

I suggest it’s time to rethink our belief that customers (and developers, for the most part) “don’t know what they want until they see it”.

My late, great colleague and friend Grant Rule used to refer to the practice, common in the Agile domain, of building (a portion of) something to see if the customer likes it as “random walks through the problems-solution space”.

Quality Demands Requirements

Philip Crosby, a widely acclaimed “guru” of Quality Management, defined quality as “conformance to requirements”. As simple and blunt as that.

Recently, I’ve been reflecting on my experiences with software product development, especially the development of “quality” products that customers love. In Javelin, we place special emphasis on de-risking delivery through explicitly defining the customers and their respective requirements. Not big-bang, up-front stylee, but incrementally, just enough each couple of days to build a little more of the product and deliver it to the customer(s) for their delight, confidence, and feedback.

But in our approach, requirements (in the frame of the Antimatter Principle we call these needs) precedes building anything. Agile shops these days seems to major in building something before discussing requirements (if they ever get discussed at all). BDD offers an exception, but how many shops do BDD?

Aside: In Javelin, we identify all stakeholders (a.k.a. all the Folks That Matter), discuss their needs (“Stakeholders’ Needs”, in Javelin parlance) and quantify them (a la Gilb – see: Competitive Engineering) in the form of Quantified Quality Objectives. Although:

  • This all generally proceeds incrementally, rather than in a big batch up front.
  • The information is always to hand by the time someone gets around to building the relevant part of the thing in question.
  • The requirements come from dialogue(s) with the relevant Folks That Matter.
  • The requirements need not get written down (documented) unless there are some Folks That Matter that need them to be.

People work from the requirements. Always.

Random Walks are not Our Bag

Random walks are not our bag.

By cleaving to the belief that customers “don’t know what they want until they see it”, and structuring the whole approach to development around this belief, Agile shops have no incentive to improve the way they work with customers to understand their needs. No incentive to improve requirements elicitation and capture. No incentive – or means – to prevent defects and deliver zero-defects quality. Indeed, this belief and its associated practices blocks us from working to continually find better ways to create useful requirements (formal statements of folks’ needs) from which to drive quality (cf Crosby) and the improving of relationships with each other (developers, ops) and with customers.

Is this emphasis on working-from-clearly-stated-and-agreed-requirements better? Well, in my experience it makes for happier customers, happier developers, and more successful products. I’ll leave it to you to decide whether and how that’s “better”.

– Bob

Inventing Agile

[Tl;Dr: I invented Agile in UK / Europe, independent of the USA / Snowbird folks, circa 1994].

I was running a project in Europe when I first woke up to the value of “process” in delivering working software. It wasn’t the first project I’d been managing, but it was the first time in a corporate environment, with many stakeholders, and with developers and methods not of my own choosing. I have to say that the project was not an unalloyed success.

Upon completing my assignment and returning to England, spurred by my dissatisfaction, I explored the existing literature for ideas about how to do things better. And in my next few assignments I experimented with some of these ideas and began to evolve a coherent approach to software development.

Motivation

I had already long been motivated by a need to see folks able to realise their innate potential. I had often been appalled by the waste of human potential I had seen time and again in places I had worked. I was convinced there must be a better way, and set about finding it.

Influences

Key influences during this time included:

  • RAD (Rapid Application Development – James Martin, etc.)
  • JAD (Joint Application Development)
  • Evolutionary Development (Gilb)
  • Rapid Iterative Development
  • Risk Management (Capers Jones, etc.)
  • TQM (Crosby, Juran, Shingo et al)
  • NextSTEP
  • Modula-2 (Wirth)
  • Eiffel (Meyer)
  • Objective-C (Cox)

The Roots of European Agile

By the time I came to work with the CFO of Barclays, running some internal projects at Barclays head office, I had the kernel of an approach that today we’d label “Agile”. This was 1994.

As you may see from the influences listed above, I was already leaving the waterfall / V-model camp and beginning to favour iterative and incremental approaches.

Even in these early days, the results were outstanding.

Continuing to apply and evolve the ways of working I discovered at Barclays, I then did a tour of some of the major merchant banks in the City, where proven ideas for improving their software development results found some favour.

A couple of years later found me at Sun Microsystems’ UK Java Center, bringing these development approaches to Sun’s major corporate clients looking to transition their development teams into the Java ecosystem.

At this time I began referring to my now well-formed approach as “Jerid”.

Note on the Name

Jerid grew out of two complementary initiatives I had been running for some years named “SPEAR” and “BEAR” – Software Process Engineering And Reengineering, and Business process Engineering And Reengineering. SPEAR consisted of many of the techniques I had found useful through years of experimentation and application, packaged into a coherent whole. But SPEAR was more an umbrella concept, with different flavours of specific development approaches underneath – most notably Jerid.

In case you’re wondering, “Jerid” is a kind of javelin (throwing spear) used in games played on horseback in certain Muslim countries in the Middle East. It was also a somewhat convoluted acronym for “Java Enterprise Rapid Iterative Development”. Jerid later evolved into “Javelin”.

The Heart of Jerid

Jerid was founded primarily on ideas from risk management and rapid and evolutionary iterative development. By 1997 it had evolved to a point where, with hindsight, it looked circa 80% like Scrum was to look some years later. Two-week iterations (time boxed), sprints, sprint goals, sprint planning, retrospectives, etc.. I had independently invented “Agile” software development in Europe some years before the name itself was chosen at Snowbird, USA in 2001.

The core difference between Jerid and e.g. USA Agile/Scrum was Jerid’s emphasis on risk management. Jerid projects ensured that the major risks were identified and controlled. For me, this is the essence of any Agile approach – managing and controlling the major risks – both those common to all software development projects and those specific to each individual project.

We continued to apply and evolve Jerid during the late ’90s, at Familiar and its clients, until my departure from Familiar circa 2000.

Since then I have worked with a large number of different companies, large and small, helping them discover the fundamental principles underpinning iterative and agile approaches, and evolving practices and ways of working from those principles.

Acknowledgements

I’m very pleased to be able to acknowledge the contributions made to SPEAR and Jerid by many folks along the way. Although none of this would have happened without my input, their help and support was invaluable to me in evolving my understanding of software development, and later, the intersection of software development and general business.

Disclaimer

I’m pretty sure other folks also invented their own takes on the Agile theme before it became known by that name. Maybe even before I did. I’d be delighted to hear from anyone who believes they fall into that category.

Also please note that many of the strands of the thing that has become known as “Agile” existed long before I even got started in the field of software development methods. We all owe a debt to those many pioneers who were pushing the envelope and challenging accepted wisdom back as far as the 1960s and 1970s, if not before.

– Bob

A Hiding To Nothing

Most large companies are on a hiding to nothing if and when they decide they’re “going Agile” for software development. “Going Agile” can only ever deliver the outcomes these companies seek if the whole organisation is prepared to change some of its fundamental beliefs about how organisations should be run.

Sought Outcomes

What outcomes do larger compares typically seek from “going Agile” in their software development teams? Here’s a partial list:

  • A more coherent, disciplined approach to software development
  • Improved governance and oversight
  • Improved estimates
  • Better due-date performance (reliable on-time delivery)
  • More visibility into project roadmaps
  • Common standards
  • Better project organisation
  • People working “in sync”
  • Senior management confidence (in e.g. the teams’ ability to deliver)
  • Higher staff motivation and engagement
  • Shorter timescales (i.e. “from concept to cash”)

Why These Outcomes Are Unrealisable

What’s not to like in the outcomes these companies seek by “going Agile”? Although maybe not comprehensive – they lack, for example, outcomes like “joy in work”, “folks getting their needs met”, “improved flow” and “customer delight” – there’s a bunch of stuff here I could get behind.

Setting aside the observation that some of the above “outcomes” – such as “common standards” and “people working in sync” – are more solutions than needs, “going Agile”, per se, is not the answer for delivering these outcomes. At least, not within the Analytic mindset world view.

Why the Analytic Mindset is the Blocker

With an implicit Theory-X, local optima (manage the parts separately) perspective, any and all solutions attempting to deiver these outcomes through “going Agile” are doomed to undermine the very outcomes sought.

It’s likely to start well, with much interest and hope expressed by the staff. After all, who wouldn’t want more autonomy, more mastery, more purpose in their work? But as things progress, existing company policies, rules, attitudes, etc. will begin to assert themselves. To the detriment of staff morale, motivation and engagement. Pretty soon, staff will begin to question the sincerity of the management in their support for “going Agile”. Pretty soon, it will start to become apparent to anyone who’s paying attention that existing policies, rules, etc., have to change fundamentally to see the outcomes sought begin to happen.

And with declining staff engagement in “going Agile”, and reducing enthusiasm for understanding the principles necessary for making Agile successful, progress will slow to a crawl. At this point, middle-management, who have to carry the burden of making “going Agile” happen will also begin, quietly, to question the wisdom of the senior management direction. This will lead to their more often reverting to orthodox, “tried and tested” (and less personally burdensome) ways of working. And more often baulking at the effort needed to push through adoption of more Agile practices.

What To Do?

So, what’s a company to do? Most companies will not realise, or want to hear, that the Analytic mindset is fundamentally incompatible with successfully “going Agile”. So, another Agile adoption failure is in the making.

Personally, having helped various companies face up to this challenge, I’d say:

“It’s extremely unlikely that you’ll want – or even be able – to give up your existing world view. At least in the short term. So something’s got to give. And it’s probably better that you give up on “going Agile”. But DON’T give up on wanting things to be better. Park your Agile aspirations, and try another path, another solution. After all, it’s the OUTCOMES you seek that matter, not some specific – and cargo-culted – solution.”

So what might that alternative solution look like? What can an unrepentantly Analytic-minded organisation do to improve its software development outcomes?

My recommendation would be to focus on the interpersonal relationships within and between departments. Help developers understand and relate to customers (both internal and external) better. Help other folks within the organisation better understand and relate to developers.

Leveraging these improving relationships, encourage multi-party, cross-function dialogue about the outcomes sought, and what folks of every stripe can do, every day, to begin to shift the organisation’s rules, policies, structures and assumptions.

In a nutshell, be less autocratic, directive and strategic, and more democratic, collegiate and opportunistic.

And remember, I’m here to help.

– Bob

Antimatter Evo

Tom Gilb has long been known for his “Evo”(evolutionary) approach to software engineering, and more recently for his sharp criticisms of the Agile Manifesto (99% of which I agree with).

In a recent (February 2018) PPI Systems Engineering Newsletter, he authors the feature article “How Well Does the Agile Manifesto Align with Principles that Lead to Success in Product Development?”, describing in some depth his issues with the Agile Manifesto, its Four Values and Twelve Principles.

Apropos the latter, Tom comments at length on each, providing for each a “reformulation”. I repeat each of these twelve reformulations here, along with a translation to the vocabulary (and frame) of the Antimatter Principle:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Tom’s reformulation: Development efforts should attempt to deliver, measurably and cost-effectively, a well-defined set of prioritized stakeholder value-levels, as early as possible.

Antimatter translation: As early and frequently as possible, in the course of developing e.g. a new product or service, we (the development team) will identify, quantify, and subsequently measure, a well-defined set of the needs of all the people that matter, and deliver, as early and frequently as possible, stuff that we believe meets those needs.

Antimatter simplification: Our highest priority is to continually attend to the needs of everyone that matters.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Tom’s reformulation: Development processes must be able to discover and incorporate changes in stakeholder requirements, as soon as possible, and to understand their priority, their consequences to other stakeholders, to system architecture plans, to project plans, and contracts.

Antimatter translation: Our approach to developing new products or services enables the development team to discover and incorporate changes in the needs of anyone that matters, and the members of the community of “everyone that matters”, as soon as possible. The development team has means to quantify, share and compare priorities, and means to both understand and communicate the impact of such changes to the community of “everyone that matters”.

Antimatter simplification: Handle changing needs, and changing membership of the “everyone that matters” community, in ways that meet the needs of the people that matter.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Tom’s reformulation: Plan to deliver some measurable degree of improvement, to planned and prioritized stakeholder value requirements, as soon, and as frequently, as resources permit.

Antimatter translation: Plan to deliver some measurable degree of improvement to the planned and prioritised set of needs (of the people that matter) as soon, and as frequently, as needed.

Antimatter simplification: Deliver stuff as often as, and by means that, meets the needs of everyone that matters.

4. Business people and developers must work together daily throughout the project

Tom’s reformulation: All parties to a development effort (stakeholders), need to have a relevant voice for their interests (requirements), and an insight into the parts of the effort that they will potentially impact, or which can impact them, on a continuous basis, including into operations and decommissioning of a system.

Antimatter translation: Have established means through which we continually solicits the needs of the people that matter, means that are well-defined and well-understood by everyone that matters. These means provide: an ear for the feelings and needs of the people that matter, and feedback on the consequences (impact) of attending to those needs.

Antimatter simplification: Share needs and solutions as often as, and by means that, meets the needs of everyone that matters.

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

Tom’s reformulation: Motivate stakeholders and developers, by agreeing on their high-level priority objectives, and give them freedom to find the most cost-effective solutions.

Antimatter translation: Motivate everyone that matters by agreeing on everyone’s needs, and give everyone, as a group, the freedom to collaborate in negotiating the trade-offs, priorities, and most cost-effective solutions.

Antimatter simplification: Motivate people to the degree that, and by means that, meets the needs of everyone that matters.

6. Enable face-to-face interactions.

Tom’s reformulation: Enable clear communication, in writing, in a common project database. Enable collection and prioritization, and continuous updates, of all considerations about requirements, designs, economics, constraints, risks, issues, dependencies, and prioritization.

Antimatter translation: Provide communications that meet the needs of everyone that matters. Manage these needs, including negotiated solutions, just as all the other needs in the endeavour.

Antimatter simplification: Facilitate sharing of information, feelings, needs, etc. to the degree that, and by means that, meets the needs of everyone that matters.

7. Working software is the primary measure of progress.

Tom’s reformulation: The primary measure of development progress is the ‘degree of actual stakeholder-delivered planned value levels’ with respect to planned resources, such as budgets and deadlines.

Antimatter translation: The primary measure of development progress is the ‘degree of actual needs met’ with respect to the planned, prioritised and quantified set of needs of everyone the matters. Note: Assuming end-users or customers are amongst the set of people that matter, this demands the product or service in question is in active service with those people, such that we can measure how well (the degree to which) their needs are actually being met. And don’t forget the needs pertaining to how the endeavour is being conducted!

Antimatter simplification: Choose a primary measure of progress that meets the needs of everyone that matters.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Tom’s reformulation: We believe that a wide variety of strategies, adapted to current local cultures, can be used to maintain a reasonable workload for developers, and other stakeholders; so that stress and pressures, which result in failed systems, need not occur.

Antimatter translation: Proceed at a pace that meets the needs of everyone that matters. Manage these (dynamic and potentially conflicting) needs, including negotiated solutions, just as all the other needs in the endeavour.

Antimatter simplification: Choose a pace that meets the needs of everyone that matters.

9. Continuous attention to technical excellence and good design enhances agility.

Tom’s reformulation: Technical excellence in products, services, systems and organizations, can and should be quantified, for any serious discussion or application. The suggested strategies or architectures, for reaching these ‘quantified excellence requirements’, should be estimated, using Value Decision Tables [45, 1, 2], and then measured in early small incremental delivery steps.

Antimatter translation: Aim for a level of technical excellence and good design – and any other quality-related attributes – that meet the needs of everyone that matters. Manage these (dynamic and potentially conflicting) needs, including negotiated solutions, just as all the other needs in the endeavour.

Antimatter simplification: Agree on attributes of quality, and levels of quality, with respect to the means of the endeavour, that meets the needs of everyone that matters.

10. Simplicity – the art of maximizing the amount of work not done – is essential.

Tom’s reformulation: We need to learn and apply methods, of which there are many available, to help us understand complex systems and complex relations. [1, 2, 46, 47, 48, 49] and succeed in meeting our goals in spite of them.

Antimatter translation: Aim for a level of simplicity – and any other quality-related attributes -that meet the needs of everyone that matters. Manage these (dynamic and potentially conflicting) needs, including negotiated solutions, just as all the other needs in the endeavour.

Antimatter simplification: Spend effort only where it directly attends to some need of someone that matters.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

Tom’s reformulation (A): The most useful value and quality requirements will be quantified, and will use other mechanisms, including careful corresponding stakeholder analysis [1, 51, and 52], to facilitate understanding.

Tom’s reformulation (B): The most cost-effective designs/architecture, with respect to our quantified value and resource requirements, will be estimated and progress tracked, utilizing a Value Decision Table with its evidence, sources, and uncertainty. They will be prioritized by values/resources with respect to risks [45].

Tom’s reformulation (Simplified, combined): We will use engineering quantification for all variable requirements, and for all architecture.

Antimatter translation: Choose organisational structures and methods (teams, heroes, feature teams, self-organisation, quantification, etc.) for the endeavour that meet the needs of everyone that matters. Manage these (dynamic and potentially conflicting) needs, including negotiated solutions, just as all the other needs in the endeavour.

Antimatter simplification: Agree on attributes of quality, and levels of quality, with respect to the organisation of the endeavour, that meets the needs of everyone that matters.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Tom’s reformulation: A process like the Defect Prevention Process (DPP), or another more-suitable for current culture, which delegates power to analyze and cure organizational weaknesses, will be applied: using participation from small self-organized teams to define and prove more cost-effective work environments, tools, methods, and processes.

Antimatter translation: Aim to learn as much from our work as meets the needs of everyone that matters. Manage these needs, including negotiated solutions, just as all the other needs in the endeavour. 

Antimatter simplification: Pursue improvement, with respect to the means and organisation of the endeavour, that meets the needs of everyone that matters.

Summary

The key insight that emerges from this exercise in translation is this:

Once we have a more-or-less formal and established approach for identifying who matters and their needs, with respect to the endeavour at hand – and then tracking, negotiating and managing the evolving community of “everyone that matters” and their needs – much of the minutiae of the Twelve Principles, and debates thereon, evaporates.

In a nutshell: we must attend not only to the needs in the context of the particular product or service under development, but also to the needs of everyone that matters in the context of the means (conduct, organisation) of that development effort.

– Bob

Innovation ALWAYS Demands We Change the Rules

How do you feel about the proposition:

“Innovation can bring benefits if and ONLY if it diminishes a limitation”

Let’s examine this proposition. Do you agree with it? Don’t be too hasty in coming to agree with it. Once we agree, you’re hooked! So, let me explain a little more, starting with some definitions:

Innovations

We’re talking here about all kinds of innovations. Not just tech innovations (new materials, new languages and tools, new industrial processes, new scientific discoveries) but other innovations too (new ways of doing things, new ways of structuring and managing organisations, new ways of developing products and software, plus many others).

Limitations

What do we mean by “limitation”? A limitation here is anything that restricts us from getting our needs met to the maximum possible extent. (And btw that maximum is, itself, a limitation).

Limitations can be “recognised” (for example, a speed limit on a motorway) or unrecognised (for example the physical speed limit for a given curve, with a given vehicle, in specific road conditions).

Examining the Proposition

So, back to the proposition: “Innovation can bring benefits if and ONLY if it diminishes a limitation.”

Do you agree?

We were alive and functioning even before the innovation became available. Correct? It must be, then, that long before the new innovation, we developed modes of operation, modes of behaviour, policies, rules, to accommodate the limitation. I’ll refer to all these as simply “rules”.

We were able to operate. Rather than run smack into the limitation and die. That’s obvious.

Before the innovation, we created certain rules to cope with the limitation (recognised or unrecognised, known to us or unknown).

Suppose, then that we make a very good job of implementing an innovation, and thereby diminish the associated limitation totally. Still, the question is:

What benefits will any innovation bring, if we neglect to change the rules? The rules that helped us to accommodate the limitation, before the innovation was available? What benefits will we see if we neglect to change the rules?

Do you start to see the answer?

The Old Rules Block Any Benefits

What benefits will we see if we neglect to change the rules? Basically, no benefits. None. Why? Because as long as we obey the old rules – the rules that were there to bypass the limitation – for as long as we obey these rules, for all practical purposes we will continue to behave as if the limitation is still there.

Can it be that we’re so stupid that we continue to adhere to our old rules, the rules we originally invented to bypass or cope with the limitation? You know the answer.

This is what is happening every day, for the vast majority of organisations, and for the vast majority of innovations they adopt. For a long time after adopting the innovation we still obey the old rules. And because of this, for a long time we don’t get any of the real benefits from our investment in the innovation.

Four Not So Frequently Asked Question

So, how might we proceed if we need to ensure that innovations really do bring us the promised bottom-line benefits? We might choose to ask ourselves the following sequence of four questions:

Q1: What is the POWER of the innovation? (Just ask the inventors, they’ll be more than glad to explain, and explain, and explain…).

Q2: What limitation does this innovation diminish? (We must find a specific and precise answer, here).

Q3: What existing rules served to help us accommodate that limitation (i.e. what obsoleted rules we must get rid of)? Here we can for the first time evaluate the tangible bottom-line benefits from removing those old rules). (Note: As long as the old rules remain in force, we will never see the promised benefits from the innovation). Ch1 11:10

Q4: What (new) rules must we use now (in place of the old rules which the innovation has obsoleted)?

Let me give you an example. Let’s take Agile Software Development as our innovation.

Q1: What is the POWER of Agile Software Development?
A1: Agile Software Development increases the likelihood that we’re developing software that meets our customers’ real needs.

Q2: What limitation does Agile Software Development diminish?
A2:  Risk of misunderstanding customers’ real needs, both now and as they evolve.

Q3: What existing rules served to help us accommodate that limitation?
A3: Contractual terms. Big up-front specifications. Rigorous plan-driven project management. Change control. Specific duration projects. Formal V&V.  One-off or infrequent release into production.

Q4: What (new) rules must we use now?
A4: Development and delivery as experiments. Short, tight feedback loops. Constant collaboration between customers and developers. Constantly evolving specifications and solutions. Multiple “stop/continue” checkpoints. Incremental and frequent release into production.

Try It For Yourself

Here’s some other innovations we see introduced in e.g. software development organisations. May I invite you to run through the above four questions for one or more items on this list?:

  • Teams / team-based development.
  • Obeya (big-room).
  • TPDS (Toyota Product Development System).
  • Lean Product Development.
  • Cost of Delay.
  • Flow.
  • Python, ELM, or some other new language or tool you may be considering adopting.
  • Self-organisation / self-management.
  • Servant Leadership.
  • Holacracy.
  • Serious Play.
  • Continuous Improvement.
  • [Your own favourite innovation].

We Must Change the Rules

“Human beings cannot progress unless somehow they do things differently today from the way they did them yesterday.”

~ Shigeo Shingo

So now we can see that the real effort we must make is NOT in adopting new innovations, but in changing the rules. And these rules are manifest in the assumptions-in-action, the collective mindset, the culture, of an organisation. This, btw, is the central message of Rightshifting and the Marshall Model.

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)

Learn Through Delivering

In my previous post I talked a little about the role of language and vocabulary in shifting focus – from being busy, to attending to folks’ needs. The word ‘deliverable’ emphasises, unsurprisingly, delivery. But what does it mean to “deliver” in the context of i.e. software development?

Inspect and Adapt

For me, delivery is the opportunity to close the feedback loop. To gain some insight into whether what we’ve been working on has been useful to our stakeholders. And to adjust our sights – and ways of doing things – in the light of that information.  So the defining aspect of any and all “deliverables” is that deliverables, by this definition, must be delivered to stakeholders and they must be able to try them out in as near as possible to real-world situations so as to provide meaningful feedback.

Cadence

Just how often might we deliver something for our stakeholders to provide feedback on? That depends on how short we want our feedback loops to be. Myself, I prefer a maximum feedback loop length of two to three days. Whether your teams are in a position to dance to this rhythm, or something slower, kind of depends on your stakeholders and how quickly they can look at, and respond to, each delivery. Keeping deliveries small can help here, by keeping what they have to look at, and their responses, small too.

Artefacts

Of course, there will be things we create, produce – things for our own consumption, like documents, design artefacts, intermediate transformations leading to deliverables, and so on. I choose to call these non-deliverables “artefacts” (or even “non-deliverables”) – to distinguish them from the deliverables on which we intend to seek feedback.

May I invite you to trial a change of perspective – from learning through doing, to learning through delivering – as soon as you have the opportunity?

– Bob

 

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

TinCup

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

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

GroupTherapy

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:

Tweet20151124

– Bob

 

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

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

AfterAgileBlue

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

rnut1

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:

rnut2

What most folks assume

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

rnut3

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:

rnut4

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:

rnut5

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.

rnut6

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.

rnut7

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

rnut8

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.

rnut9

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.

rnut10

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?

rnut11

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

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

%d bloggers like this: