Archive

Lamentation

Little Islands

Trawling the seas of knowledge

Note: This is one of those rare posts (for me) where I have few to no suggestions as to how to proceed.

Islands of Ignorance

In my travels, I have seen many organisations from the inside, and many more from the outside. 

In almost all cases, these organisations strike me as like little islands of ignorance in a huge sea of knowledge. As a mariner myself, I’m well aware of the bounty of these seas. So, maybe better placed than most to see the shortfalls in our organisations’ uptake of this bounty.

Seas of Knowledge

It’s never been easier to keep up with developments (sic) in praxis – in whatever fields of human endeavour interest us. And that’s probably even more true for the fields of collaborative knowledge work, software development and product development than for any other.

And yet, almost every organisation I see operates on principles – from the executive management suite to the workers at the coal face – utterly disconnected from the seas of knowledge surrounding them. Principles grown stale and musty with the dust of ages past.

Some organisations, having an inkling of their disconnection, make token efforts to bring outside knowledge in – with brown bag sessions, encouraging folks to attend meet-ups and conferences, hiring consultants from time to time, and so on. But like fishermen on the shore with fishing poles and spears hooking the occasional fish, this ain’t so effective. Few indeed are the organisations that build trawlers and send them out with nets, sonar, radar and the like to harvest the plenty of the seas.

Why is This?

What makes organisations so inept at finding and using the huge repositories of knowledge out there – in books, on the internet, in people’s heads, and so on?

Beats me. 

I have some suspicions that the education system is partly to blame. I’ve seen many graduates who, upon doing the workforce, act as if their learning days are behind them. 

And short-termism, the bane of UK industry in particular, contributes. With the implicit idea that learning, being more valuable in the longer term, has little or no value in meeting next week’s delivery schedules, or this month’s financial targets.

I guess, too, that like navigating our planet’s vast oceans, the seas of knowledge are so vast now that special navigation equipment is necessary to tackle the challenge. And whilst a fish is a fish, a idea or item of know-how is a much more slippery thing. How to sort the wheat from the chaff? Maybe systematic experimentation can help (see e.g. Toyota Kata, or Popcorn Flow from Claudio Perrone)

Appeal

So. There you have it. No elegant ideas for addressing the situation. Just an appeal to you, dear readers, to share your experiences, perspectives, and maybe a hint or tip or two for the rest of us.

– Bob

Further Reading

The Fifth Discipline ~ Peter M. Senge
Peter Senge and the Learning Organization ~ Infed article
On Dialogue ~ David Bohm

Wants, Needs

My previous post seems to have struck a chord, judging by the number of retweets on Twitter. It also presents an opportunity to explore a perennial challenge of building things for other people: teasing out real needs from expressed wants.

Have you ever worked with business folks who articulate their wants in the form of solutions, rather than as solution-free “requirements”? As means rather than ends?

Let’s take another look at the list of desired outcomes (wants) appearing in the aforementioned post:

  • 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

Business Analysis for the Way the Work Works

From my days as a Business Analyst, I’ve learned that uncovering needs means having an ongoing dialogue with the people that matter. A dialogue in which we dig down, together, into the things they say they want, so as to uncover their real needs. Once we’ve teased apart the wants from the needs, we’re in a better place to choose effective strategies (solutions) for addressing those needs. Going with the superficial wants tends to box us in to the strategies (means) they provide. Strategies which often fall short of being effective.

I suspect what I’m talking about will become clearer as we examine in turn each item from the above list…

Item: A more coherent, disciplined approach to software development

This looks to me like a solution masquerading as a need. That’s to say “a more coherent, disciplined approach” seems like more like means to other ends, than and end in itself. What might those ends be? What might be the underlying needs driving this proposed solution? A dialogue with the people that matter seems in order here. A dialogue that could prove challenging, absent a degree of trust and willing collaboration. And even assuming we are all able to dig down towards the underlying needs, just as in building software there’s no guarantee we’ve identified those needs accurately, until we’ve built and delivered something and seen it “in production” long enough to gather some feedback. Active feedback, which also implies iteration and evolution: “Is this really meeting the needs of everyone that matters? Is it good enough yet? What else do we need to do to improve it further?” etc..

For illustration, I’ll take a stab at the needs which might underlie this want. Maybe some folks suppose that “a more coherent, disciplined approach” will bring order to the present chaos (a need for order). Maybe some folks suppose that “a more coherent, disciplined approach” will make delivery of e.g. features or product increments more predictable (a need for predictability).

Maybe productive and effective dialogue will uncover other latent needs implicit in this want.

Item: Improved governance and oversight

This also looks to me like a solution masquerading as a need.

Maybe some folks choose “Improved governance and oversight” as their automatic, default solution (strategy) for bring order to the present chaos (a need for order).

Item: Improved estimates

This again looks to me like a solution masquerading as a need.The No Estimates movement and debate has just about done this one to death. What might the supposed need for “improved estimates” imply. What’s really need here?

Item: Better due-date performance (reliable on-time delivery)

Whilst we could imagine this as yet another solution masquerading as a need, in this case I find this want more interesting, maybe closer to a real need than the previous two items.

I suspect some folks that matter may suppose that “better due date performance” is the obvious means to improve (external) customer satisfaction, and thereby revenue, repeat business, profit, market demand, market share, and other business metrics. Maybe those involved in the way the work works, armed with an explicit, agreed need to satisfy one or more specific business metrics, would be able to come up with ways of working which effectively address those metrics. In other words, valuable innovations.

Item: More visibility into project roadmaps

This again looks to me like a solution masquerading as a need. What might be the underlying need here? Maybe it’s something born of a feeling of powerlessness in the absence of information about what’s happening. Maybe it comes from a sense of frustration or embarrassment when having to face customers and investors expecting information about product release schedules, feature sets, and road maps. Whatever the case, an effective, productive dialogue may flush out some of those underlying feelings, and thereby lead to a better understanding of the needs we’re all trying to address.

Item: Common standards

Yet again this looks to me like a solution masquerading as a need. I’ve heard this want many times in numerous companies. This looks to me like an implicit solution to the question “how do we become more flexible, how can we cost-effectively deploy and redeploy our developers between projects and project teams as business priorities change?” I guess the people that matter suppose that “common standards” is the obvious answer. But it’s our job to understand the underlying need and come up with the most effective solution (strategy) for addressing it, not just the most common solution.

But I could be barking up the wrong tree about the presumed underlying need here, so I’d want to have conversations with the people that matter so as to really understand what they might be trying to achieve through addressing this want.

Item: Better project organisation

Another solution masquerading as a need. What might “better project organisation” bring us? Better due date performance? More visibility into project roadmaps and current status? See explanations, above, for the needs which might underlie *those* wants.

Item: People working “in sync”

Solution masquerading as a need. What might “people working in sync” bring us? Reduction in friction and waste? Improved flow (of products and features into the market)? Better due date performance? By digging down, though dialogue, we may uncover candidates for the underlying needs, which we can proceed to validate through delivering a way the work works, and getting feedback on the degree to which that way of working effectively addresses folks’ real needs.

Item: Senior management confidence (in e.g. the teams’ ability to deliver)

This is probably the one item in our list of sought outcomes that’s closest to a real need. We can intuit the scale of the problem (shortfall in senior management confidence) by looking at all the solutions they’re helpfully trying to provide us with, via the other items here. Solutions (masquerading as needs) that they believe will improve things and thereby deliver the boost in confidence they seek (and need). Ironically, the solutions they provide – being very much less effective solutions than those we can come up with for them, as experts – often undermine the very outcomes they seek.

Item: Higher staff motivation and engagement

Very laudable. But let’s not let the humanity of this want blind us to its nature as (yet another) solution masquerading as a need. What’s the end in mind? Why might the people that matter seek “higher staff motivation and engagement”?

So they can feel better about the culture for which they they feel responsible? As a means to increased throughput and thus improved revenues and profits? Again, until we know what they really need, any solutions we provide will likely fall well short of the mark. In other words, wasted effort.

Summary

So, we can see that taking “sought outcomes” at face value can lead us into sleepwalking into addressing superficial wants, and adopting other people’s (non-expert, relatively ineffective) solutions. Solutions which rate poorly on the effectiveness scale, and which in any case may well be addreessin the wrong needs. I find it ironic just how much non-expert interference and micromanagement goes unnoticed, unchallenged and unlamented. Plenty of time for lamentation a year or two later.

Bottom line: When building software, the biggest risk lies in building the wrong thing (getting the requirements wrong), and it’s not any less of a risk when “building” – we might choose to call it “evolving” or even “engineering” – the way the work works.

– Bob

Parlour Tricks

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

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

Oooh, Shiny!

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

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

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

Passing Off

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

– Bob

Further Reading

Why Do People Conform To The Herd? ~ Adi Gaskell

Agile Competency Is A Crock

LearBookOfNonsense

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

Agile Consultancies Aren’t

Why not? Well, at the very root is the the Myth of Redemptive Violence, which gives power to both the Domination System within which we as humans are for the most part emprisoned, and to the Analytic Mindset with its anachronistic and oppressive (Theory-X) view of human beings as e.g. cogs in a machine. More specifically, there’s a whole passle of “failure modes” which I’ve seen in numerous self-styled Agile Consultancies:

The Path Of Mammon

  • Consulting teams in name only. Consultancies like to supply teams. Many times, these teams are selected by managers, and run by Project Managers or Account Managers. And from there, it’s managers all the way up (down). Even whilst espousing the benefits of Agile, these consultancies fail to walk the talk.
  • Analytic Mindset. Consultancies, not wishing to look too alien to their largely Analytic-minded client base, and perhaps lacking the imagination to see beyond conventional management models, most often adhere to the hierarchical management models now beginning to look very dated.
  • Theory-X. At the beating heart of Agile lies the Theory-Y disposition. How many Agile consultancies have Theory-Y type relationships with their staffers, as opposed to the more traditional Theory-X stance?
  • Play. Innovation. Creativity. All espoused values of Agile, and all conspicuous by the absence in many consulting engagements, where margins, revenues and milking the client for as much money as possible seem to take precedence. And where things have to be done “by the book”, both by the consultants and the client’s staff they’re supposedly “helping”?
  • Delivering value. This. How many consultancies do you know that offer an unequivocal value-for-money guarantee?
  • Incremental delivery. Another core value of the Agile approach. How often do contracts with clients reflect this? How often do contracts (do you remember “Customer collaboration over contract negotiation?) stipulate fixed terms for the consulting engagement?
  • Agility. How many consultancies do you know that start an engagement with a plan of campaign, or agenda, vs sensing the clients evolving needs and responding to those changing needs as they flex and unfurl?
  • Agile is about human relationships. How many Agile Consultancies do you know that major on that? On building long-term relationships between their company and their clients’ companies? (Much more that just relationships between individual consultants and individuals in the client company). On becoming a trusted parter at the heart of clients’ businesses?

I could go on, but I think I’ve listed the main points of my argument.

Two-Way Street

It’s a two-way street, of course. Agile Consultancies follow the Path of Mammon mostly because that’s what their clients expect, or demand. That’s what many imagine it takes to survive and thrive in a Market for Lemons. It looks risky to buck that demand in favour of another way. But another way there is.

Another Way

There is another way. A way which eschews short-term revenues, and skipping from one unsatisfactory engagement to the next, in favour of helping clients in the longer-term. With non-dogmatic advice and help that attends to the needs of everyone involved, not just the consulting company’s big-wigs. This Other Way is the path I myself have chosen to follow. It’s not as easy nor well-travelled a path as the Path of Mammon. But I find it immeasurably more satisfying, all-in-all.

“Two roads diverged in a wood, and I, I took the one less traveled by, And that has made all the difference.“

~ Robert Frost, The Road Not Taken

– Bob

Further Reading

Joy, Inc. ~ Richard Sheridan Why Familiar Was Europe’s First 100% Agile Software House ~ FlowChainSensei

This Rotten Edifice

deadend

I see the rotten edifice we have constructed, and I weep.

I see people labouring to buy things under the misapprehension it will make them happy. Things which then own them.

From top to bottom, I see people who have no faith, no joy in what they do. Yet feel obliged to act as if they did.

I see people worshipping at the temple of Mammon, knowing he is a false god.

I see people going through the motions, putting on a brave face, pretending that what they’re doing matters, that there’s some point to it all.

I see people in thrall to the delusion that if they just stick at it, things will be better one day.

I see people making themselves and everyone around them miserable because they’re bought into, bet their farm on, this rotten edifice.

I see people full of resentment, playing the game and hating it all at the same time.

I see people take refuge in friendships, family, pets, hobbies – unable or unwilling to address the core issues of being part of this rotten edifice.

I see people capable of so much more, resigned to settle for so little.

I see people, each suffering in silence, not talking about what matters to them, how they feel, what they need.

Such beauty in the world. Such a rotten edifice obscuring our view. Where’s the joy?

– Bob

%d bloggers like this: