We’ll know for sure the Agile fad is over when more money is to be made by other means.
It’s close now.
We’ll know for sure the Agile fad is over when more money is to be made by other means.
It’s close now.
Are you an Agile Expert? Do your revenues depend on your Agile chops? Do you see the writing on the wall?
Newsflash: You’re as obsolete as a buggy-whip maker. Agile Main Street is closing. Your markets are shrinking. You’ll only be dealing with the laggards and bad-faith actors from now on.
As a player in technology markets, you know all about technology adoption curves. We’re fifteen years or more past the Chasm for Agile. And tech markets move much faster than FMCG, manufacturing and other such markets.
What’s the next technology curve where your existing cumulative assets can play best and earn the greatest margins? What legacy issues are holding you back? Are you another victim of the Sunk Cost fallacy? What new assets must you acquire to play well on the new curve? What actions must you take today to best position yourself for tomorrow? Times they are a’changing (as always). Are you changing with them?
And what resolutions do these questions bring to mind?
No, you can’t buy in to Agile without changing your thinking. Your OWN thinking. Can you buy that in?
Absent such change, any imagined or sought benefits must inevitably be foregone.
Apart from the benefits of theatre, that is.
(See other posts here for why the real benefits of buying in to Agile are not worth the candle, anyways).
I propose its the theatrical benefits which are the only benefits of interest, nowadays.
The software industry is not the only domain in which dogma and conservatism combine to defeat effectiveness. Here’s an article on how the US Army (and USMC) are using Mission-type Tactics (Auftragstaktik) in name only (MTTINO).
and a backgrounder on auftragstaktik:
And see also: Product Aikido for insight into (real) mission-type tactics for product development.
I’ll acknowledge that some software development endeavours have been “successful”. Some of those have “used Scrum”. And some haven’t.
Of those that have “used Scrum”, what proportion have actually being doing “real Scrum” e.g. “by the book”, and what proportion have been doing “Scrum in name only (SINO)”?
And of those that have been doing “real Scrum”, and have claimed “success”, what proportion have been successful because of Scrum, and what proportion (irrespective of self-reported or externally-reported success) have been successful because of other factors, some connected with Scrum, and others more or less totally disconnected from Scrum? Factors that may have been overlooked, ignored or discounted?
In other words, where’s the evidence that Scrum, itself, is the core element of success?
I’ve never seen Scrum advocates address this elephant in the room.
P.S. Much the same argument applies to Agile, in general. IME.
It often seems that folks automatically assume that all useful software development innovations come out of the United States. And innovations (and innovators) from places other than the US have little merit. Yet specific innovations have a tendency to pop up, more or less simultaneously, in various places:
“The concept of multiple discovery (also known as simultaneous invention) is the hypothesis that most scientific discoveries and inventions are made independently and more or less simultaneously by multiple scientists and inventors. The concept of multiple discovery opposes a traditional view—the “heroic theory” of invention and discovery.”
I rarely bother to mention Familiar’s independently inventing something very much like Scrum (we called it Jerid, now Javelin) back in the 1994-1996 time frame. Not inspired by Nonaka and Takeuchi’s New New Product Development Game, nevertheless Jerid featured:
I have no wish to tarnish or undermine Jeff and Ken’s achievements with Scrum. Nor the somewhat later accomplishments of the Snowbird folks. Just putting down a marker for us Brits. And other nations too.
Aside: The Lean manufacturing community has largely forgotten about Frank George Woolard, a Brit whose work preceded and some say inspired the Japanese, notably Eizi Toyoda.
How attractive as employers are companies that claim to be “post-Agile” or even “anti-Agile”?
I’ve rarely participated in, or observed, a useful daily standup. Oh, wait, actually that would be never. And in those teams where we’ve not had daily stand-ups, we’ve never missed them.
Daily stand-ups are a signal – a signal of latent dysfunctions in your development organisation. Of course, for many organisations coming from a highly dysfunctional environment, they can be a step forward. But like training wheels on a push-bike, daily stand-ups are a step we’d all like to be over with as soon as possible. Frankly, I think they’re unhelpful, time-wasting and what’s more, embarrassing.
A quick daily meeting to check the pulse of your project. Setting aside the raft of dysfunctions inherent is the idea of a project, let’s take a look at the origins of the idea:
“You want everyone to know what’s going on, even if they weren’t there when something interesting happened. You want to know who’s got a problem you can help with, you want to get help if you need it. You need a forum to announce interesting upcoming events.”
Every day at a specified time (C3′s is 10 AM), everyone on the team (developers, customers, people passing by) stands up in a circle. Go around the circle and briefly describe what you’re working on, how it’s going, anything interesting you have discovered, any problems you are having.
Here are some of the dysfunctions I have regularly observed in daily standup meetings, in practise:
Daily stand-ups are a signal of latent dysfunctions in your development organisation. Are you paying attention to the signal?
And they’re not concerned with providing you with value for your money. If they WERE so concerned, they wouldn’t be Agilists. After twenty years of dicking about with Agile, we can safely say that Agile per se provides ZERO value.
Oh, some folks and teams that say they’re Agile may achieve results greater than the norm (although the norm is itself so woefully inadequate that claiming results greater than the norm is saying very little). The Rightshifting chart (below) illustrates this point.
But the fact is, that the success of folks and teams that achieve and deliver up to and beyond expectations is not down to Agile. It’s down to other factors that people often mistakenly attribute to Agile.
Agilists will claim that they are doing these things, because they’re “core agile themes”. And yet, they’re paying lip-service to these themes, not actually doing them.
So, if you need predictable, on-time deliveries of solutions to support your business objectives, don’t be taken in by all the Agile bollocks. It’s all snake oil. Place your money wisely, find people who really know how to provide value (hint: not “Agilists”) – and caveat emptor!
The Complete Rook ~ Two Ronnies sketch
Scaled Agile – or scaling agile – seems like a hot potato at the moment. Here’s a few
Agile even at a small scale doesn’t work and scaling something that doesn’t work just leads to an even bigger mess that doesn’t work. Take a look at SAFe if you don’t believe it. Or just listen to Ackoff:
“The righter we do the wrong thing, the wronger we become. When we make a mistake doing the wrong thing and correct it, we become wronger. When we make a mistake doing the right thing and correct it, we become righter. Therefore, it is better to do the right thing wrong than the wrong thing right.”
Mindset (a.k.a. culture, memeplex) over methods, tools, etc.. What an organisation, collectively, believes and assumes has far more impact on e.g. productivity, quality, etc. than any methods or tools. See: Organisational Psychotherapy, the Marshall Model, and my new book, “Memeology“.
The only thing of real importance that leaders do is to create and manage culture.
~ Edgar Schein
The thing I have learned at IBM is that culture is everything. It took me to age fifty-five to figure that out.
~ Lou Gerstner, CEO, IBM
If you get the culture right, most of the other stuff will just take care of itself.
~Tony Hsieh, CEO, Zappos.com
And Schein also provides us with a definition for “the culture of an organisation”:
Culture is the deeper level of basic assumptions and beliefs that are shared by members of an organisation, that operate unconsciously and define in a basic ‘taken for granted’ fashion an organisation’s view of its self and its environment…
It’s a pattern of shared basic assumptions invented, discovered, or developed by a given group.
~ Edgar Schein
Goldratt wrote the book on Flow Efficiency (see “The Goal”, in case you’re interested).
Flow efficiency is miles better than resource efficiency (a.k.a. utilisation). What is flow efficiency? I’m sure you can look it up. But for the lazy: Flow efficiency suggest a focus on keeping work moving through its various value-adding steps, with minimal or zero queues and wait times, thereby attending to folks’ needs (value to the Folks That Matter) – and prompting feedback – as quickly as possible.
Formalise innovation, evolve into continuous organisational transformation.
What do I mean by “innovation”?
In the context of organisations, here are a few possible definitions of “innovation”:
Here’s my preferred definition:
Innovation: Delivering against an idea which meets a specific set of needs, for all the Folks That Matter.
And “formalise”? What the hell does that mean, exactly? In effect, institute trainings, standard work, measures, etc., around the whole innovation (and, a.s.a.p., organisational transformation) piece.
I’ve been brief here to avoid a rant. Do get in touch if you’d like me to elaborate on some of these themes.
By popular demand, here’s a short post expanding on a recent pithy tweet of mine:
“Agile coaching” is bullshit – for various reasons.”
“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?
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..
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.
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.
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.]“
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.
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.
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 spreadsheets.”
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.
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.
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 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).
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.
Organisational Cognitive Dissonance ~ Think Different blog post
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.
♥ 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.
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.
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.
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”.
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:
People work from the requirements. Always.
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”.
[Tl;Dr: I invented Agile in UK / Europe, independent of the USA / Snowbird folks, circa 1994].
I was running a project in Europe (Brussels, Belgium) 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.
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.
Key influences during this time included:
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”.
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”.
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.
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.
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.
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.
What outcomes do larger compares typically seek from “going Agile” in their software development teams? Here’s a partial list:
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 .
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.
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.
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.
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:
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).
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).
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?
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.
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.
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?:
“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.
Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)