I despair of the boatloads of naive advice, misinformation, and just pure tosh that so-called “Agile” people spout on a daily basis. (Not limited to just “Agile” people, of course.)

Caveat lector!

And just in case you’d like a sanity check on anything suspect or dubious, I’m always happy to support your natural scepticism. Just get in touch for non-partisan help.

Ineffectiveness is the norm (in particular in the software and collaborative knowledge work fields).

Therefore the less effective someone appears to e.g. hiring managers, the more employable they are. The ineffective fit right in, don’t challenge norms or ruffle feathers, and appear a competent “good hire” even as they join in with sustaining and compounding the organisation’s prevailing ineffectiveness.

Simple Truth

This simple truth explains why some many organisations are so poor at developing tech products, and software more generally. They unwittingly hire “good fits’ i.e. the profoundly ineffective. And never realise the productivity improvments, etc., that they’re leaving on the table.

The (modified) Marshall Model chart (below) illustrates the situation:

How might we help these organisations appreciate their dire situation? Is that even possible?

– Bob

Further Reading

Peters, T.J. and Waterman, R.H. (1982). In Search of Excellence: Lessons from America’s Best-run Companies.  Profile Books.

Marshall, R.W. (2021). Quintessence: An Acme for Software Development Organisations. Falling Blossoms (LeanPub).

Agile Development Doesn’t Work

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.

Things like:

• thriving and joyful humane relationships
• attending to folks’ needs
• treating they way the work works – across the whole organisation – as a system
• collective assumptions and beliefs – across the whole organisation
• and yes, even, sometimes, to effective engineering practices. 

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!

– Bob

Further Reading

The Complete Rook ~ Two Ronnies sketch

Part 1 – The Lede

The Agile Manifesto set out to make developers’ (and others’) live richer, saner and more fulfilling.

A true irony of the legacy of that Manifesto is that finding a fulfilling job or role “in Agile” is nowadays next to impossible.

Competency is not something valued by hirers and their gatekeepers. Being a “safe hire” is all.

Part 2 – The Background Story

My dear friend, the late Grant Rule, had many compelling stories to tell.

One of these concerned a large insurance company in the home counties. Let’s call them InsCo. For some reason, the powers that be became interested in the reasons why they were not doing as well as they thought they should be, business-wise.

Some number of investigations were commissioned. One concerned the type of people they were hiring, versus the type of people needed for business success.

To cut a long story short, it became revealed to them that not only were they hiring people with little to contribute in the way of the organisation’s business goals, they were actually hiring people whose general style actively undermined those goals.

In other words, their hiring practices were expressly filtering out those people best suited to make a positive contribution inside the business. And this had been going on for years, if not decades.

I always found the story fascinating, not least for its compelling ring of truth.

In todays’s business world, I see many of the organisation I visit or work with making exactly the same error.

Organisations whose hiring practices filter OUT exactly those candidates who would best contribute to the espoused goals of the organisation.

Guided by the heuristic of POSIWID, I assume that organisations – or more exactly the core group within an organisation – are not much interested in the organisation’s espoused goals. Deming said as much fifty years ago, with his First Theorem:

“Nobody gives a hoot about profit”

~ W Edwards Deming

I find this particularly noticeable in hiring for so-calle Agile positions and roles. […]

Now, I’m not about to criticise folks – senior executives and middle managers in this case – for acting in their own individual and collective (core group) best interests.

It’s what humans do – acting to get needs met.

I’m just inviting you, like the executives at InsCo did, to take a look at the consequences of your current hiring and staffing policies and processes.

And consider how those staffing policies and processes play against the things that matter to you.

Oh, and maybe consider what those things that matter to you are, too.

Part 3 – The Dilemma

For me, struggling as I am to find gainful and meaningful employment, the questions aired in part 2 raise an interesting question for all of us in the Agile field:

Do we concentrate on appearing competent, and on our abilities to help the organisation achieve its espoused goals? Or do we focus on getting a well-paid job – which demands a very different strategy and “personal brand image”?

The former strategy suggests we list our experience, results and contributions to the success of the organisations we have worked with. That we take hiring organisations’ espoused goals at face value and play to those declared goals.

The latter strategy suggests we present ourselves in terms that appeal to the needs we imagine the hirers – and their gatekeepers – have.

Needs rarely articulated and only determinable through observation of these folks’ actions. Needs which in most cases means portraying ourselves as conventional, conservative, and status-quo loving. As “safe hires”.

I’ve discovered – unsurprisingly, to me – that I just CAN’T bring myself to do the latter.

I’m NOT a safe hire, not do I ever wish to be. My value proposition is other.

Outwith the emotional consequences of pretending to be something I’m not, and setting myself up at work to live a life that’s a bald-faced lie, I just don’t want to find myself in any more jobs or roles that, in essence, are just another stupid punt.

How about you?

– Bob

Many will be familiar with the epithet:

“A foolish consistency is the hobgoblin of little minds.”

~ Ralph Waldo Emerson

Fewer will know that it comes from Emerson’s essay, “Self-Reliance“, first published in 1841. Or that the text continues:

“…adored by little statesmen and philosophers and divines. With consistency a great soul has simply nothing to do. He may as well concern himself with his shadow on the wall. Speak what you think now in hard words, and tomorrow speak what tomorrow thinks in hard words again, though it contradict everything you said today. — ‘Ah, so you shall be sure to be misunderstood.’ — Is it so bad, then, to be misunderstood? Pythagoras was misunderstood, and Socrates, and Jesus, and Luther, and Copernicus, and Galileo, and Newton, and every pure and wise spirit that ever took flesh. To be great is to be misunderstood.”.

In the essay, Emerson is advocating the advantages of thinking for oneself, rather than meekly accepting the ideas of others.

Many other notable figures have railed against the foolishness of consistency. In such august company, i think we can pass on further such railings.

I’d like instead to raise and rail against a related foolishness:

“A foolish craving for certainty is the hobgoblin of the fearful, who when obtaining become the tearful.”

By which I mean those who rush to secure certainty in their world, should they achieve their wish, often end up lamenting the outcome.

“Be careful what you wish for” is another apt proverb that comes to mind.

Recent (neuro) scientific research has illuminated the human brain’s innate hunger for certainty:

“A sense of uncertainty about the future generates a strong threat or ‘alert’ response in your limbic system. Your brain detects something is wrong, and your ability to focus on other issues diminishes. Your brain doesn’t like uncertainty – it’s like a type of pain, something to be avoided. Certainty on the other hand feels rewarding, and we tend to steer toward it, even when it might be better for us to remain uncertain.”

So, just as Emerson noted our “foolish” hunger for consistency, neuroscience notes our “foolish” hunger for certainty.

A Topical Example

We might be forgiven for being surprised that a “progressive software startup” which, presumably, understand the perils of trying to tie down every little detail of requirements before embarking on the development of a product, should fail to grasp the perils of attempting to tie down every little detail of a job specification before embarking on recruiting for that position.

It’s like, the more important the position, the more certainty the hirers seek to assuage their hungry brains’ demand for certainty. Blind to the perilous implications.

Just as with Big Analysis Up Front for software development, BAUF for recruiting can lead to some unfortunate consequences:

• Exclusion of the best candidates
• Delays in finding even fairly-suitable candidates
• Assumption that the eventual new hire is actually fit for the job
• inclination to pigeon-hole the new hire, thereby demotivating him or her over time.
• A job (position, role) not well-suited to the actual – as opposed to imagined – needs of the hiring organisation
• De-emphasis on adaptability and flexibility as desirable new hire characteristics
• Increased likelihood of hiring a narrow specialist (speciation, decrease in memetic diversity)
• Unreasonable (stress-inducing) expectations of the new hire (cf Deming’s 95/5)
• Lost opportunities for building mutual trust
• Demotivation of the recruiters

Just as the world of software development has adapted to the brain’s cravings by e.g. adopting and evolving agile development principles, a more effective approach to recruitment might be to adapt, again. I’m thinking simple story cards, as placeholders for dialogue; I’m thinking making things visible; I’m thinking a focus on value; I’m thinking tests. Sounds familiar?

I’ve written on a similar theme previously, with the post Make Bad Hires!

This post has been brought to you by Lemons, and the wish to make lemonade.

– Bob

Further Reading

A Hunger for Certainty ~ Dr. David Rock
Thinking, Fast and Slow ~ Daniel Kahneman

Conventional wisdom, oft repeated on the intarwebs, cautions us to take great care when hiring people. Some folks go to the trouble of quantifying the costs of just one bad hire. But what about the costs of such caution? Here’s a few (sincere) arguments in favour of making bad hires:

• However much of a misfit someone may seem at the outset, most people have the ability to learn, grow and develop. Recognising this can send a warm, reassuring and respectful message to everyone in the organisation – including the new hire.
• Sticking with a new hire – even when recognising that the hire was “questionable” – can earn much loyalty and commitment from the person in question.
• Finding bad hires is a lot quicker and a lot simpler than finding good hires.
• Who’s to say that someone that looks like a bad hire will in fact turn out to be such? Kahneman cautions against the cognitive biases that makes us think we can predict people’s performance in advance. (This also reminds me of the Zen story “Farmer’s Luck”).
• If we accept making bad hires as policy, our organisation can gear up for it and streamline the procedures for taking people on and letting people go. Much like the agile policy of “deliver early, deliver often, get feedback.” (See also: Zappos). The increased frequency can help us learn faster.
• The stigma associated with making ‘bad hires’ decreases or disappears, reducing the delays inherent in people (well, managers, really) avoiding taking “risky” decisions.
• People other than managers can be “entrusted” with making hiring decisions.
• If you subscribe to the idea of “Deming’s 95%” – that 95% or the performance of any employee is down to the system (the way the work works), not to their own innate skills, experience or talent, then any gap between “good” and “bad” hires will be minimal (5% of overall performance) in any case.
• Seemingly “bad hires” will bring diverse perspectives into the organisation, perhaps much more so than “good hires” might.

Note: I would advise retaining one “good hiring” filter: the “No assholes” rule (including filtering-out of folks with sociopathic and/or psychopathic tendencies).

Can you think of any more good reasons for making bad hires?

– Bob

Further Reading

Thinking, Fast and Slow ~ Daniel Kahneman
7 Reasons Why Not Making Mistakes Is The Biggest Mistake ~ Blog post from PurposeFairy
Everyone sucks at Interviewing ~ Blog Post from Jason Freedman
“Why Good People Can’t Get Jobs” ~ Online article by Dr. Peter Cappelli
“Bad Hires Have Cost Zappos Over $100 Million” ~ Tony Hsieh
“What’s Wrong with Job Interviews, and How to Fix Them” ~ Adam Grant

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

The Peg

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

Assumptions, Assumptions

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

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

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

Are We Learning Yet?

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

Awareness

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

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

Other Factors

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

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

Thanks. :}

– Bob

Further Reading

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

Good Home Cooking

My maternal Grandmother was a wonderful cook. And when she and my mother were running the family business – a seaside guest house – when I was a wee lad, she used to cook all the meals for the guests (and the family and staff too). She really cared about her cooking, selecting quality ingredients from local fishermen, farmers and grocers, and lovingly crafting the best meals she could – within the budget allowed by the business.

Most of the guests loved the food, many paying compliments and returning year after year. Locals would also dine-in regularly. But there were always some, a very few, for whom the food did not meet their expectations, or more likely, suit their palates. In her consummate, inimitable style, when faced with a particularly unreasonable complaint, she would say “…pearls before swine”. Meaning, she knew her food was excellent, and if some folks didn’t like it, then they probably didn’t know how to appreciate it.

“Give not that which is holy unto the dogs, neither cast ye your pearls before swine, lest they trample them under their feet, and turn again and rend you.”

~ Matthew 7:6

Software Pearls

Do you believe that great knowledge-work will be recognised by the folks paying for it? Some teams may be lucky and find a good customer that appreciates what they’ve achieved, the quality they’re delivered, the efforts they have made – many times, above and beyond the call of duty (or the terms of the contract). But very often, customers receive excellently-crafted products with absolutely no clue as to the quality of the things they’ve just received. Unlike a great plate of food, they have no means to evaluate what they’ve just been served. The converse is also all-too-frequently true; oftentimes customers get delivered a real dog of a product, and have no clue that they’ve just been completely rooked.

Thankless

Of course, some customers don’t feel that suppliers should be especially thanked, recognised or otherwise noted for simply delivering what was asked-for, regardless of any unforeseen difficulties or outstanding innovations that may have occurred along the way. I would not regard these as desirable customers.

In Japan, for example, in the Keiretsu – the supplier networks of the major manufacturers – suppliers are appreciated, helped and long-term relationships fostered, with the understanding the the supplier-customer relationship thrives with long-term commitment and mutual effort.

Keiretsu member companies own small portions of the shares in each other’s companies…; this system helps insulate each company from stock market fluctuations and takeover attempts, thus enabling long-term planning in innovative projects. It is a key element of the automotive industry in Japan.

Few indeed are the Western companies that see value in this kind of arrangement, and fewer still the companies that act to cement long-term relationships with software suppliers.

Market for Lemons

What this means in practice is that the market for software services (e.g. custom software development) is effectively a Market for Lemons.

And what that means, is that software suppliers will rarely receive a fair price for their labours. Lacking appreciation of quality, buyers will automatically assume that whatever they are buying is a Lemon, and discount the price accordingly.

This is as much true for software supplied in-house by e.g. the IT department to the rest of the organisation as it is for software supplied by external commercial software development services (e.g. software houses)

Finally, the Point

So why am I writing this post? For three main reasons, really:

• To invite those organisations buying software services, either from external third parties or internal e.g. IT departments, to focus some effort on better understanding good service / quality software from the dross. A Market for Lemons affords benefits to no one.
• To remind suppliers to choose their customers carefully, and where that is infeasible, to pay some attention to managing customers’ expectations and educating them as to the quality aspects of what they’re receiving.
• [TBD – Can you guess?]

– Bob

A Lorra, Lorra Lemons

In my time I have seen a lot of lemons. And I have seen a lot of companies hire or engage with lemons – almost always unwittingly. Actually, I can’t believe how ineffective some of these folks and suppliers have been. And let’s face it, there’s a lorra, lorra lemons out there.

Following on from my recent “Better Customers” post, I thought it might offer some value to share some tips on how to spot these lemons.

The Lemon Consultant

Description

The Lemon Consultant is most often a pinstripe- or blue-suited individual – through its colouration and demeanour attempting to appear native amongst the local dominant fauna.

The Lemon Consultant strides purposefully from place to place, exuding faux-charm and confidence in an effort to attract its prey. Juveniles are similar to adults except the suits are cheaper and the veneer of confidence thinner, with a tinge of bluster.

Lemon Consultants prefer to congregate in flocks, for security and mutual support, although solitary individuals are also sometimes seen in the wild.

Range and Habitat

Lemon Consultants prefer surrounding of glass, steel and laminate, and favour smaller, private spaces over the open savannah. They are common in urban and suburban areas especially where large budgets are predominant.

Throughout the summer Lemon Consultants can be found in most of the major conurbations across the Northern Hemisphere. In North America: from southern Canada, down through the United States to the Mexican border. There are small pockets of Lemon Consultants as far west as Washington State. In Europe: preferring temperate climes, they are fewer in Scandinavia and Mediterranean  countries, with a significant population in the British Isles.

They are partially migratory with some migrating and others not. Some Lemon Consultants migrate quarterly, but always preferring to stay in one place for as long as their food source remains plentiful.

Nesting Habits

Like Mourning Doves, Lemon Consultants often take over other’s nests, at least temporarily. Failing that, and like the Black-headed Grosbeak, Lemon Consultants are known to steal parts and pieces of others’ nests to construct their own. In settled (non-migratory) situations, Lemon Consultant prefer a burrow or other cosy corner where they can keep out of sight whilst preening.

Feeding and Watering

Whilst Lemon Consultants are omnivorous, they prefer hard cash up front. When such pickings are scarce, they often settle for an hourly rate. They have been known to travel incredible distances from their breeding grounds to their preferred feeding sites. Avaricious and self-serving, the Lemon Consultant concerns itself predominantly with feeding.

Lemon Consultants do a wonderful job of regurgitating ideas from other sources, although generally poisoning the seeds and causing the resulting crop of ideas to be stunted and malodorous.

Song

The Lemon Consultant is a very vocal bird. It often has a strident, even whining note, although some few have a lilting, musical overtone. They make a number of different calls including its distinctive “deliver-cost-urgency”. It growls when it’s irritated, and chatters when it’s not. The Lemon Consultants has whistles and gurgling sounds in its repertoire as well.

Behaviour

The Lemon Consultant is often both aggressive and territorial. Group of Lemon Consultants will attack intruders and other Consultants that move into their territory, although they take great pains to avoid overt conflicts, preferring stealth and subversion to direct assaults.

If the weather is mild and the food plentiful, Lemon Consultants may winter over in their breeding grounds. But when they do migrate, they form loose flocks of around 3 to 12 traveling only during hours of darkness.

Sub-species

The lesser-known Lemon Agile Consultant can be distinguished from its more common brethren by its naivety, good-naturedness, and a fondness for making grandiose claims about the benefits of Agile software development whilst making no mention of the risks, costs, or the scale of changes required throughout adopting organisations.

The Lemon Agile Consultant is also very fond of Powerpoint presentations featuring cutesy child-like artwork and banal, empty platitudes; specious and tiresome “games”; often carries copious amounts of Lego; and repeats words like “fun”, “fairies” and “the power of stories” ad-nauseam.

Their song varies subtly from their common cousins, their most distinctive calls including “fun-clap-fun”, “more-value-less-waste” and “time-to-market”. Listen to the song of the Lemon Agile Consultant: Sound Bites: Lemon Agile Consultant, National Twat Service

Lemon Agile Consultants frequently borrow ideas from primary sources, but often out of context, and having grasped the wrong end of the stick. Their attribution of sources is rare to non-existant.

The Lemon Agile Consultant enjoys playing, and wants to play in your sandpit, with your money and your resources. Their gregarious nature means they love to rope-in as many of your people as possible, regardless of the distraction and disruption this causes. Outcomes rarely hold their interest for long, if at all.

Recognition

Recognising Lemon Agile Consultants amongst the general fauna is relatively simple. Ask direct questions like:

• What’s most likely to happen when we roll agile out across the whole development group?
• How will adopting Agile impact on other groups within the organisation?
• What will we have to do to realise the promised benefits of Agile over the longer term (i.e. beyond 9-15 months)?
• What are the key elements for ensuring our investment in Agile is sustainable and does not dissipate when e.g. early sponsors and champions leave the organisation?
• How have Agile adoptions turned-out in other organisations? Well? Badly? What’s the typical success rate, longer-term? What are the likely pitfalls?
• Is Agile suited here? Are there approaches other than Agile that can meet our needs as well or better?

Further Resources

Summary

Avoiding Lemon Consultants may seem like a difficult challenge, and for the uninitiated it can be. But with just a little awareness, a little patience to pass them by, and a few simple rules of thumb, it gets much easier.  And if life throws you one or more of these Lemon Consultants? Don’t bother even trying to made lemonade. Lemon squash, maybe.

– Bob