Objectives, Proclaimed vs Practised

Tl; Dr: Most organisations do software development not for the outputs, but to satisfy the members of the core group, whose needs are pretty much entirely disconnected from both software quality and the evolution of an effective development organisation.

Mistaken Beliefs

“Discrepancies between objective proclaimed and objective practiced can be observed in most organizations. For example, one could mistakenly believe that the principal objective of universities is to educate students. What a myth! The principal objective of a university is to provide job security and increase the standard of living and quality of life of those members of the faculty and administration who make the critical decisions. Teaching is a price faculty members must pay to share in the benefits provided. Like any price, they try to minimize it. Note that the more senior and politically powerful teaching members of the faculty are, the less teaching they do.”

~ Russell L. Ackoff

So To Software Development

One could mistakenly believe that the principle objective of e.g. software houses and other software-producing organisations is “working software”. What a myth! The principle objective of such businesses is to to provide job security and increase the standard of living, positive self-image and quality of life of those in the core group of these organisations, and provide sufficient (read: minimum) income, entertainment and other such “attractions” necessary to retain the continued attendance of the rest of the workforce. “Frontline” work such as coding, testing, designing, decision-making, etc. is a price core group members must occasionally pay to share in the benefits provided. Like any price, they try to minimise it. Note that the more senior and politically powerful the core group member, the less frontline work they do.

The Core Reason For Lameness

Here we have one answer to the question “Why are software products generally so lame?”. Note: we could also phrase this as “why does the practice of software development generally result in outputs (software, products) with such limited positive impacts (outcomes) for anyone but members of the core group?”. Or more bluntly: “Why does no one ever seem to care that we’re just continually churning out crap?”.

Just like universities, where the positive outcomes for students are more or less limited to a handy, albeit increasingly expensive qualification, in software development positive outcomes for customers and workers are more or less in the lap of the Gods (or the members of the core group, which we may choose to regards as synonymous).

- Bob

Further Reading

Who Really Matters ~ Art Kleiner

Can You Use A Scrum Master?

A giant tied down by little people

I don’t mean “do you have an opening for a Scrum Master right now?”. I mean, “if you hired a Scrum Master today, would you, your development teams and your organisation be able to get any real value out of him or her?”.

There’s a whole bunch of pathologies I see time and again in Agile adoptions. One set of such pathologies is around the role of Scrum Master. These pathologies, unchecked, result in situations which demoralise the new hires and the development teams alike, and rob the organisation of any value from having a Scrum Master, and even from the Agile adoption itself.

Fools Rush In…

The line of so-called reasoning which leads to this particular group of pathologies generally runs like this:

“I’ve just heard about this thing called Agile. Could we use it?”

“We need to do something about our software development around here. It costs too much / takes too long / is not predictable enough / produces low quality resulting in a poor customer experience / insert your gripe here.”

“I know, this new-fangled Agile thing looks like it solves all our problem. I read as much in an inflight magazine last week. Let’s get our tech folks to adopt agile.”

“What flavour of Agile?”

“Um. There are flavours? I’ve heard of something called Scrum. Seems quite common. Let’s go for that.”

“Right! The development teams will start using Scrum next Monday.”

“But they don’t know anything about Scrum. It’s quite different to how they’re working now, I guess. They’ll need someone to show them the ropes and train them in the whole thing. The Scrum book says so. That person is called the Scrum Master.”

“Ok. We’ll hire one of those, then. Now they can jolly well get on with it. It’ll be great. Problem solved – at last. Golf this afternoon?”

And so the scene is set for another train-wreck. Here’s an explanation of some of the pathologies implicit in this dialogue:

Scrum is a Thing

It’s not. It’s an entry point, an on-ramp, a way to get started. The sooner a team becomes comfortable with the basic principles of Agile, the sooner Scrum-By-The-Book can fall away, and the team can continue its journey in whatever directions it deems best, according to the unfolding and evolving situation.

Scrum Can be Mandated

It can’t. If the development teams have no choice but to adopt Scrum, are not involved in the decision, they will likely resent it from the very outset. And resentment breeds opposition.

The Scrum Master is a Management Appointee

They’re not. Or rather, all too often they are – which only compounds the issue of the involvement of the development team in key decisions. Lack of autonomy is not a good foot upon which to get started with e.g. Scrum. Giving a development team little or no say in who gets to be their Scrum Master will again exacerbate their sense of learned helplessness, and breed dissatisfaction and disengagement.

The Scrum Master Is a Trainer

They’re not. Maybe they have some Scrum knowledge, maybe not. (And no, certification will not provide you with any assurances about that, one way or the other). The Scrum Master is no policeman, either, despite some opinions to the contrary. Primarily, the Scrum Master is someone who speaks for the “improvement” of the way the work works, offering some counter-balance to the daily pressure to get stuff shipped. (See also: Two Masters). If they do bring some Scrum expertise to the party, that can afford some short-term acceleration for the team, but often at the cost of longer-term progress – delaying the onset of a team’s confidence in itself and in its ability to learn.

Change is Bounded to the Dev Teams

It’s not. Most of the issues impacting development teams will lie outside the control of the development teams themselves. The Scrum Master will act as a catalyst for the team to bring these issues to the attention of senior management – the only folks in typical organisations that have the scope of authority to get these issues sorted out. This means that the Scrum Master and/or Team will be a regular – and demanding – visitor to the executive suite. Have you space in you schedule for this?

The Problems are Known Beforehand

They’re not. Scrum was created to shine a light on each dysfunction in the organisation. Many of these dysfunctions will have been around for years, if not decades, hiding in plain sight. Managers may think they know what the problems are, Scrum will say something different. Are you prepared to revisit your fondest assumptions?

Hire and Forget

Many folks hiring Scrum Masters assume they can just hire and then leave the Scrum Master to just get on with “fixing the team”. Any Scrum Master worth their salt will demand much time from the senior managers outside the development function. Do you have the time to commit?

All Scrum Masters Are Much of Muchness

Certification can make it seem that all Scrum Masters offer much the same level of skill, experience, and ability to contribute. Not so. Scrum Masters, being human beings, are just as variable as other humans. Do you know the kind of person that will best suit where you want the organisation to be in three, six, twelve months from now?

The Individual Can Trump the System

Many organisations look to the Scrum Master hire to come in and “fix” the dev team, with little understanding of how the existing assumptions, policies, structures, etc., of the organisation can cripple even the best Scrum Master. Deming’s 95% applies here as much as elsewhere. Are you ready to change such things, to enable the Scrum Master to add real value?

The Scrum Master is an Interim Hire

If you believe that the Scrum Master is there to “kick-start” the team, then you’ll miss the key value-add of any Scrum Master (or Agile Coach, or Organisational Therapist, for that matter). Every dev team can improve faster, feel better, and produce better software with the full-time, long-term availability of a competent coach. If it works for e.g. sports teams, why not for dev teams?

The Scrum Master is a Management Patsy, Stooge or Dupe

There are undoubtedly some Scrum Masters out there that are just doing it for the money, willingly toeing the management line, caring little for real improvement or the well-being of their teams. Most, however, will push against the status quo. Which kind do you want to hire?

Scrum Masters Are Selfless

They’re not. They’re just human beings too. They have needs. Most often, the need to make a difference is strong in them. Stronger than the need to conform. Or the need to make money. Making a difference is what you’re hiring them for? But they’re not super-men and -women, able to wave a magic wand to make things happen. So are you prepared to see the changes they propose regularly get actioned? Or is their morale and continued engagement not so important to you?


Most times, those appointing a Scrum Master find themselves in a Market for Lemons – being unable to discern a good candidate from the rest. Making a “good hire” then becomes largely a matter of pot-luck. (See: Make Bad Hires).

And once a hire IS made, the challenges, far from being over, are only just beginning. Are you creating the kind of conditions in which your new hire can thrive and add real value to your development efforts, or are you just tossing them into a maelstrom and letting them sink or swim unaided?

Good luck!

- Bob

Further Reading

The Perfect Scrum Master ~ Agile Scout


“I have taught one thing and one thing only, dukkha and the cessation of dukkha.”

~ The Buddha

Buddhists regard The Truth of Dukkha as the first of the Four Noble Truths, and often explain it in terms of three categories:

  • The obvious physical and mental suffering associated with birth, growing old, illness and dying.
  • The anxiety or stress of trying to hold onto things that are constantly changing.
  • A basic unsatisfactoriness pervading all forms of existence, because all forms of life are changing, impermanent and without any inner core or substance. On this level, the term dukkha indicates a lack of satisfaction, a sense that things never do and never will entirely measure up to our expectations or standards.

In my journeys through organisations large and small, I have seen much dukkha. Many organisations ill-at-ease with themselves, and with their situations. I guess it’s part of the human condition, as expressed through life in organisations. In other words, dukkha is part of the fundamental nature of our phenomenal world, including our organisational “worlds”.

“Such is dukkha. It can be fully known. It has been fully known.

Such is craving. It can be let go of. It has been let go of.

Such is cessation. It can be experienced. It has been experienced.

Such is the path. It can be cultivated. It has been cultivated…

Only when my knowledge and vision was clear in all these ways did I claim to have had such an awakening.”

~ Gautama Buddha

We can read this presentation of the Four Noble Truths  as a series of cause-effect relationships. By fully knowing dukkha, we can release craving. By releasing craving, we can experience the cessation of craving. And when we are no longer in the grip of craving, we have the freedom to cultivate the Path.

I might explain dukkha from the organisation’s perspective in terms of three categories also:

  • The obvious physical and mental suffering associated with start-ups, growth, crises, mergers, downsizings, and death (of the organisation).
  • The anxiety or stress that folks in the organisation collectively feel when trying to hold onto things that are constantly changing (a near-universal phenomenon in most organisations).
  • A basic unsatisfactoriness pervading “the organisation”, because everything is in some way always changing, impermanent and without any inner core or substance. People come and go. Product lines and products change. Methods and tools evolve. Priorities and markets change. And so on.

“Buddha Dharma does not teach that everything is suffering. What Buddhism does say is that life, by its nature, is difficult, flawed, and imperfect. From the Buddhist point of view, this is not a judgement of life’s joys and sorrows; this is a simple, down-to-earth, matter-of-fact observation.”

~ Surya Das

Maybe if you’re stressed at work, some consideration of the Truth of Dukkha, and the Buddhist approach to addressing dukkha, may offer some insights, and those, in turn, some comfort?

Aside: Not attending to one’s needs is also dukkha. As is attending to folks’ needs.

“What ordinary folk call happiness, the enlightened ones call dukkha.”

~ The Buddha

- Bob

Further Reading

Zen and the Art of Organisational Enlightenment ~ Think Different blog post

I Don’t Want Agile Back


Agile was always just a step on a path to better things. For many, it has become a destination. Get to Agile (whatever you decide that means), and… rest. In peace.

It’s Time to Kill Agile

Dave Thomas, one of the original Snowbirders, writes: “Agile is Dead”. For me, it’s been a dead man walking, for many years now.

Let’s Not Abandon All Hope, Though

Tim Ottinger writes: “I want my agile back”. I don’t.

I can sympathise with all those folks who have invested so much hope in agile, Agile, agility, etc.. For many I’m sure it looked like a way out of the soulless machine organisations that frustrate and depress so many smart folks on a daily basis. A new hope for peace in the galaxy.

But I believe it’s better to move on, rather than back.

I’d prefer we move forward, recognise the contribution that agile has made, and start dealing with some of the more fundamental aspects of writing software, running software businesses, and so on, that the ten plus years of Agile brouhaha has largely obscured.

I’d prefer we started attending to folks’ needs, and encouraging and supporting folks in sharing, discussing and meeting those needs, rather than adopt some set of vanilla assumptions about what folks need, however well-meaning.

I don’t want agile back. I want a world where we’re not all wasting 90% of our time – our lives – every day, A world where people matter. I haven’t abandoned the hope that we can build such a world, together. Let’s just not call it ‘agile’?

“Let’s abandon the word ‘agile’ to the people who don’t do things.”

~ Dave Thomas

- Bob

Further Reading

Different Worlds, Different Roads ~ Think Different

We Have The Technology…

Did you know that some companies have applied development/engineering principles to their organisations as a whole? Very few, granted. But it does happen. I mean, they intentionally design their organisation, its structures, processes, systems (human- and technology- both), interactions, the way the work works, etc. to better meet certain business goals.

And the resulting organisational “operating systems” look very different to the copycat, zombified, cargo-culted, grow’d-like-topsy majority.

The general idea gained some attention – and then notoriety – under the label Business Process Reengineering, circa the late nineteen nineties. Of course, like many ideas before then – and e.g. Agile, Lean, etc. since – those folks of the Analytic mindset bought into the reported benefits, without realising the change in mindset that successful adoption/application of BPR required. When the expected benefits failed to appear, they both canned and vilified the idea. It wasn’t long before the whole shebang was consigned to the trashcan of history.

Why bring up the whole sorry tale once again?

I’ve been musing on what it means to be a world-class software (software) engineering organisation. What happens when we happily apply engineering principles to the development of products, but ignore those principles when it comes to how the organisation operates across the board? To the development of the organisation itself? Is that a sure-fire recipe for Organisational Cognitive Dissonance?

And if we have a cadre of folks who understand and embrace engineering disciplines and principles in the building (development) of products, why not put those talents to good use in the service of building an organisation with world-class operational capabilities? In all aspects of running the business?

Although, there’s always the possibility that an organisation espouses becoming a world-class engineering company, yet has insufficient grasp of what “world-class engineering” means to be able – or willing – to apply it in the whole-business context.

Would you be willing to share your thoughts?

- Bob



For this, my three hundredth blog post, I thought I’d mark the occasion by proposing something so irrational, so preposterous, so unbelievable that you might think I’ve lost my marbles.

Here it is:

“In knowledge-work, people work with their brains. So nurturing brain function is central to effective knowledge-work.”

And, in situations involving collaborative knowledge-work – as opposed to simply one or more individuals working with their individual brains:

“In collaborative knowledge-work, people work in concert with other people, all using their brains to some common purpose, or end. So not only is individual brain function central to effective knowledge-work, but nurturing collective brain function is central to effective collaborative knowledge-work.”

I see, time and again, organisations ignorant of this. Or, if not expressly ignorant, then wilfully choosing to ignore it. I can’t say for certain why this is. I suspect some number of different reasons are involved.

The Challenge

In any case, if you accept my basic premises stated above, then it follows that if organisations want to get the best out of their people, never mind doing the best for their people, then the real challenge is to create environments, situations, circumstances in which people can liberate and apply the enormous (untapped) potential of their creative minds, and of their innate social skills.

If you’re now wondering just how we might go about aligning our organisations to these new premises, how we might go about creating suitable conditions, you may like to check out some of my previous posts, including e.g. the Antimatter Principle.


And through our creating such conditions, people working in these organisations may also come to feel better about both themselves, and their work. More appreciated, less distressed, and generally happier. We might call this a win-win scenario. A virtuous circle, even.

Is this something you’ve ever given thought to? Discussed with colleagues? Taken steps to do something about? Or is it so unbelievable you’d feel an idiot for even mentioning it? I’d love to hear.

- Bob

Engineering Excellence


Is your business going to fail because your product development (engineering) capability is in the toilet? Probably not. Are you leaving much success (value) on the table? Definitely.

Maybe you don’t really want or need awesome “success” – however you define that. Growth, profits, fun, kudos, whatever. In which case no worries. Move along. Nothing to see here.

Maybe you’re satisfied – or simply resigned – to being a one-product company, with no real plans for developing any more products in the future. That can work. Even in the long term.

And there are other paths to a “successful” business than engineering excellence. You probably work in such a business, even now. One that has chosen another path, that is. How’s that working out for you? I mean, how’s it meeting your needs?

“People simply feel better about themselves when they’re good at something.”

~ Stephen R. Covey,The 8th Habit: From Effectiveness to Greatness

Even if your business (more specifically, the folks in charge) wanted to take the engineering excellence path, it’s just so damned hard, isn’t it? Easier by far to pay lip service to the idea, delude yourselves and others – like customers and investors – that you’re serious, while actually just futzing around making it look like some progress is being made.

And let’s not forget, engineering excellence doesn’t just apply to your business’ products and services. It’s arguably even more relevant to the way you run your business (the way the work works).

Do I have any advice for those very few folks with the horn for actually doing something about engineering excellence in their knowledge-work business? Yes. It’s spread across the nearly three hundred blog posts I’ve written here over the past five years. Not that anyone’s listening. Which kinda demonstrates my point.

- Bob

The Longer View

The Long View

I accept that few and far between are the companies and organisations that take any kind of long term view regarding their capability to develop software systems and products. Between short-term financial pressures, peripatetic middle and senior managers, demotivated staff and ever-changing technologies and tools, the long term seems to get short shrift in most places.

But I have occasionally bumped into some companies that have a longer term view.

Given that, in the longer term, staff will be changing – if not actually leaving the company, then at least changing jobs internally – what are the implication of a longer term view? Particularly in knowledge-work businesses, where people, their relationships and what they believe, are the key factor? How might we go about creating – never mind continually rightshifting – a sustainable capability independent from any particular individuals or teams? How might we allow for our hard-won effectiveness to continue – even when the involvement of key individuals does not?

Plan A

Most folks faced with this conundrum seem to put their faith in the idea of process. In particular “process maturity”, as exemplified by the CMMI. If we have a comprehensive set of rules, so the logic goes, then it doesn’t particularly matter who’s involved in the work. We can gaily swap resources (sic) in and out as circumstances dictate. In fact, with comprehensive and detailed enough rules, we could even hire monkeys and still get quality software out the door.

This had been tried – and reported on – often enough for both the advantages and disadvantages of this logic to have become apparent.

Sadly – both for those in charge, and for those in the trenches – the practical disadvantages have come to be seen as greatly outweighing any notional advantages.

So, what other option do we have? Are we condemned to continue building soulless, violent and oppressive software “factories” where people are reduced to mere dispensable cogs in some Brazil-esque corporate machine?

“Managers will try anything easy that doesn’t work before they will try anything hard that does work.”

~ Jim Womack

Plan B

I propose that we do have an alternative. One that recognises the primacy of the human element, and works with that, rather than against it. One that understands that Man is a social animal. Pre-wired by evolution for society, and living together.

This alternate approach draws from ideas of community. By encouraging the emergence and evolution of a cohesive community, having a shared mindset and a storehouse of implicit community knowledge, with shared purpose and shared values, rules become unnecessary. Enforcement and coercion becomes unnecessary. Folks can intuit the “right” thing to do, without having to refer to guidelines or processes. Or be told.

In novel and unanticipated situations, folks don’t need to worry about not having comprehensive instructions to follow.

New hires – at least those possessing a certain basic “affinity” – can quickly pick up on the vibe, and fit right in.

Granted this is not a new idea. Senge was writing about “learning communities” in e.g. The Fifth Discipline more than twenty years ago.

But maybe now the time is coming where we can begin to see the folly of dehumanising work, and can more readily consider the heretofore unpalatable option of Plan B.

- Bob

Further Reading

The Fifth Discipline ~ Peter Senge
Product Development For The Lean Enterprise ~ Michael Kennedy

Wolf Magic

Wolves chilling

In a recent blog post I thanked @davenicolette for drawing my attention to an article by Eric Barker, and more specifically to the concept of the Omega Wolf. Setting aside the question of whether the behaviour in wolves is natural or forced, I share Dave’s view that the notion of Omega Wolf makes for a fine metaphor for a particular role in our organisations.

“A really successful team needs at least one person who is not a team player. Someone who’s willing to stand up to authority, to rock the boat. To not make everybody happy. To not pat everybody on the back.”

~ Eric Barker

“Every wolf pack has an omega who bears the brunt of pack members’ frustrations. This individual functions as a sort of social glue for the pack, defusing conflict and aggression before it harms the group’s cohesion…”

~ Dave Nicolette

When I read this, I instantly recognised myself and my roles in various organisations over the years. I also saw the way in which the Omega Wolf complements the Chaos Monkey so well.

And as with Chaos Monkeys, folks in the role of Omega Wolf can easily be misunderstood – as troublemakers, lamers, losers, doormats, clowns or maybe even worse, idealist.

“Looking at the big picture and the long view, the lowest ranking wolf—the omega wolf—may actually be the ‘cornerstone wolf’ — keeping the pack together and peaceful.”

~ Robert Lindsay

Looking at human organisations – and particularly the dysfunctional ones (there are other kinds?) – I’d suggest that the people in the Omega Wolf roles are the great unsung – and often unappreciated – heroes of highly effective – and joyful – teams.

My Omega Wolf Credo

  • I aspire to help people by defusing stressful situations and bringing people together in increasingly authentic fellowship and harmony.
  • I aspire to care for the young cubs, the new hires, and the other folks who may be feeling disoriented and wondering how to become more part of “the team”.
  • I aspire to help people by being playful and encouraging others to “play” more, too.
  • I aspire to help organisations and the folks therein by championing the value of joy and humane relationships in work.
  • I aspire to improve the quality of individual and collective relationships by illustrating the value of nonviolence.
  • I aspire to improve the cohesion of the team(s) and the organisation more widely.
  • I aspire to raise awareness of the value of authentic harmony, the role of the Omega Wolf in contributing to that, and to make Omega Wolf behaviours not only acceptable but highly sought-after.

Who are the Omega Wolves in your company? How much do they contribute to the well-being of the organisational “community”? And how well-understood are they – and the value they add – in this role?

- Bob

Further Reading

Wolfpack Programming

Different Worlds, Different Roads

Three roads diverge

“We are what we think. All that we are arises with our thoughts. With our thoughts, we make the world.”

~ Buddha

With our thoughts, we make the world. Indeed.

Through my own work, I’ve become pretty sensitised to folks’ thoughts, and the way they make their worlds. Their different sets of assumptions – illustrated by the words they choose and the solutions they propose for “making the way the work works, work better”, a.k.a. “Rightshifting“.

Just now, it looks to me that the sometimes-cosy, always fractious Agile consensus is beginning to implode. Let’s face it, results have been less than stellar, less than promised, even. And many folks who really care about this stuff have become pretty much sick and tired of all the hype and misdirection and crass commercialism now the norm in the Agile space. I know I have.

Three Roads

From my vantage point, I see the future opening up along three distinct and mutually exclusive roads. Three distinct choices for people and organisations to follow towards “doing things better”.

The High Road

I see some folks select “poor or inept management” as the core problem holding back progress, and thus a focus on making management better. Through education and re-education, training, selection, taking managers to the gemba, and so on, travellers on this road assume that if we “fix managers”, then progress can be made. Travellers on this road seem to hold in common the belief that “management” is something than can be fixed.

The Low Road

I see some other folks place their faith in “big process”. Process is good, right? So bigger process (wider scope, more things controlled, more emphasis on process compliance, more detail) is better, yes? And of course that implies much “process improvement”, too. Scaled agile (SAFE, DAD, LeSS, etc) is one example of this natural progression from structured methods, through RUP, ERUP, CMM, CMMI, Prince2 et al.. The common denominator I see amongst folks on this road is the belief that knowledge work (and workers) do best when they have a map to follow at all times. And the more detailed that map, the better.

The Road Less Travelled

We might choose to signpost the third road as “the people way”. Some folks have decided that people are at the heart of knowledge work, and so progress is predicated on better understanding of people – through e.g. group dynamics, psychology, neuroscience and so on. The common theme I see shared here is that people are generally trustworthy enough, and interested enough, to figure things out for themselves, together, as they go along.

You probably know where my sympathies lie, and have some idea of the world that my thoughts have made for me. I feel no need to rank these three separate roads. I’m sure each has an appeal for various folks.

Which road resonates most with you? For which road will today’s organisations want to pay the toll? And along which road would you prefer to travel?

- Bob

Further Reading

Why We Don’t Sell Process Improvement ~ David Anderson
Description Of The Scaled Agile Framework ~ SAFe Website
The Antimatter Principle ~ Bob Marshall
Product Development for the Lean Enterprise (“The Blue Book”)  ~ Michael Kennedy


Get every new post delivered to your Inbox.

Join 10,105 other followers

%d bloggers like this: