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

Code Refactoring

Don’t ask me why I’m writing this post. It’s bound to get me into trouble.


What Is Refactoring?

Code refactoring (according to me) is taking a piece of code, code that is already working, and revising it – typically in small steps – to make it more readable, more efficient in execution, or otherwise “better” in one or more ways. Folks expect that such pieces of code will exhibit the same (unchanged) behaviour before and after refactoring.

Aside: This “invariant behaviour” itself seems arguable, as in practice many refactorings leave the code with different “-ilities” (non-functional characteristics – for example, execution efficiency). I suggest claims for such equivalence (of behaviour) are, in general, bogus. “Passes the same tests” is not a great yardstick – how many teams have a suit of tests checking all “-ilities”?

Refactoring is Waste

Given that the piece of code in question is already working, then doing more work on it could be construed as waste (i.e. not adding any value). But hang on. There’s more to it than this.

Firstly, “working” is a relative term. In the Antimatter Principle vernacular, “working” means “meeting some folks’ needs, to some extent”. We can always meet folks’ needs better. So the question then becomes, “when to stop?”. When is any piece of code “good enough”? We can really only answer this question when we have some general understanding of what “good enough” means, for each and every person involved.

Aside: How does your team go about soliciting and sharing information on what “good enough” means?

Why Not Make It Right First Time?

Well, there are some valid reasons. Cognitive load perhaps being the most relevant. Many coders just can’t always get their head around every aspect of the code they’re writing, all at the same time. Many find it necessary, at least sometimes, to defer some considerations – such as performance or readability – until they’re got something roughly “working”.

And then there’s the question of coders’ competence, and intellect, as well as the working environment and coders’ states of mind, from moment to moment.

So, for many coders, right-first-time is just beyond their present capability-in-the-moment.

All this doesn’t change the basic fact that refactoring is waste (muda, in japanese). It does beg the question, though, as to whether it is type I or type II muda:

  • Type I muda: Non-value-added tasks which seem to be nevertheless necessary.
  • Type II muda: Non-value-added tasks which can be eliminated immediately

Why Bother with This? Isn’t it a Storm in a Teacup?

My ha’penn’orth: If we choose to regard refactoring as muda, then we have our eyes open to reducing it, to writing better code on our first attempt, learning and finding other, less wasteful means to meeting folks’ needs, and getting progressively better at our craft. If we choose to see refactoring as part of our regular toolkit of practices, we may be less inclined to search for better ways, and more inclined to just live with it.

And, honestly, the whole “what is waste” question from the Leanheads seems contrived and mostly arbitrary when it comes to drawing a waste/no-waste line. IMO there’s not so much a clean line as a broad and fuzzy overlap between what is and what isn’t value-adding, especially when one considers the needs of all stakeholders, and not just the needs of the “customer”. See also “What is value”.

- Bob


Core Practices for the Antimatter Principle

When presenting the Antimatter Principle, some folks have suggested that it might help meet their needs for me to also present some ideas on how to go about applying it. In other words, some core practices.

I guess it’s the curse of the expert that makes me wonder how this could be useful, given it’s so obvious to me how to apply it (not least, having done so for the past eighteen years or more). After all, what’s so difficult about asking folks what their needs are?

I do feel uneasy about giving people “advice” – in the form of recommended practices – too. I find folks have an enormous potential for coming up with their own ideas – ideas much better suited to their own needs and contexts – given half a chance.

“When it comes to giving advice, never do so unless you’ve first received a request in writing, signed by a lawyer.”

~ Marshall B. Rosenberg

And, of course, there’s a huge body of work in Marshall Rosenberg’s Nonviolent Communication which can help with having productive dialogue focussed on attending to folks’ needs.

Anyways, before I put some time into explaining some relevant practices, I’d like to ask you, dear readers, whether you have any practices you use that might serve the Antimatter Principle? Would you be willing to contribute by means of a comment, a post on your blog, or even a guest post here? I’d be happy to collaborate to help you do so. I make a special plea to the Rightshifting Community in this regard.

Aside: For one of my own core practices – about which I’ve already written – see the post “Nonviolent Project Management”, which includes an example of said practice: “Stakeholder and Their Needs”.

- Bob





Vital Conversations

Two chaps having a vital conversation

I was keynoting on the Antimatter Principle at Agile Adria 2014 this week. As at all of the other conferences I have attended in the past year or so, I found myself feeling impatient with e.g. the hallway and dinner-table conversations, because I was feeling less connected with people than I would like. I also often feel that, amongst so many energised and experienced folks, we could be having great conversations of mutual exploration and import. Vital conversations – conversations full of energy, and life, and mutual joy. Yet we don’t seem to be able to make that happen.

At each conference, I’ve shared my feelings with one or two folks, without much in the way of ideas coming to mind.

This morning, I find an oh-so-simple idea has been staring me in the face, unrecognised, for months.

I’m speaking of this passage from an interview with Marshall Rosenberg:

SARAH: I was interested in an example you shared in one of your workshops about a group of teachers who were having a conversation that wasn’t feeding you spiritually.

MARSHALL: “Well, I was sitting around with a group of teachers who were all talking about what they did on vacation. Within ten minutes, my energy had dropped very low; I had no idea what people were feeling or wanting.

“In giraffe, we know it’s not being kind to the other person to smile and open your eyes wide to hide the fact that your head has gone dead. The person in front of you wants their words to enrich you, so when they aren’t, it’s helpful to be kind and stop them. Of course, in the jackal culture, this isn’t done.

“After listening awhile to the teachers, I screwed up my courage and said, “Excuse me, I’m impatient with the conversation because I’m not feeling as connected with you as I’d like to be. It would help me to know if you’re enjoying the conversation.” All nine people stopped talking and looked at me as if I had thrown a rat in the punch bowl.

“For about two minutes, I thought I’d die, but then I remembered to look at the feelings and needs being expressed through the silence. I said, “I guess you’re all angry with me, and you would have liked for me to have kept out of the conversation.”

“The moment I tumed my attention to what they were feeling and needing, I removed their power to demoralize me.

“However, the first person who spoke told me, “No, I’m not angry I was just thinking about what you were saying. I was bored with this conversation.” And he had been doing most of the talking! But this doesn’t surprise me. I have found that if I am bored, the person doing the talking is probably equally bored, which usually means we’re not talking from life; we’re acting out some socially-learned habits.

“Each one of the nine people then, expressed the same feelings I had – impatience, discouragement, lifelessness, inertia. Then one of the women asked, “Marshall, why do we do this? Why do we sit around and bore each other? We get together every week and do this!”

“I said, “Because we probably haven’t learned to take the risk that I just did, which is to pay attention to out vitality. Are we really getting what we want from life? Each moment is precious, so when our vitality is down, let’s do something about it and wake up.”


So, I now have a new avenue to pursue the next time I find myself feeling frustrated, impatient or disconnected. I’ll just have to remember to say something like:

“Excuse me, I’m impatient with this conversation because I’m not feeling as connected with you as I’d like to be. It would help me to know if you’re enjoying this conversation.”

Do you sometimes have the same feelings? How might this approach help you in similar circumstances? Could you find the courage to make such an interjection? How might you feel – and react – if someone else said something like this, to you?

- Bob



“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

What Are Values?

No, not “What Is Value?”. I already did that. :)

Rather, what are “values”. As in e.g.

“Agile is much more a set of values than a set of practices.”

~ Andrew Binstock

I guess different folks have many different conceptions of “values”. Before my Road to Damascus experience with Nonviolent Communication, I probably would have described “values” using terms like “moral values”, ethics, good-and-bad, right-and-wrong, and so on.

But now, having seen the Light, here’s how I’m using the term:

Values are what drives us to choose – often subconsciously – one particular strategy for getting our needs met from a range of possible strategies. We choose a particular strategy because of how we feel about it. If we feel more comfortable with a particular strategy, we’re more likely to choose it over other strategies with which we feel less comfortable.

Note that this has little to do with rational thought, such as a logical evaluation of the relative merits of the chosen strategy – whether it might work well for us, whether it might best serve us in getting our needs met.

We sorry humans often choose suboptimal strategies (understatement!). Suboptimal strategies which fail to get our needs met, or even actively work against us getting our needs met. We might choose to say that we do this because we are following our “values”. BTW Chris Argyris refers to this as our “theories in use”.

Agile Values

So when folks talk about “Agile values”, for me this implies a certain set of strategies for attending to the individual and collective needs of the folks in a team – as well as the needs of the higher-ups, customers, etc.. Often, these strategies are very different from those strategies more widespread in the team’s containing (parent) organisation. We might hear folks describe this in terms of different – and competing – “value-systems”.

FWIW I more often describe this as a clash of mindsets. I don’t see the differences in nomenclature – mindsets vs memeplexes vs value-systems – as being very material in this context.

Of course, “Agile values” are an attempt to share – and encourage the adoption of – strategies that some luminaries in the software development community believed (circa 2001) are more likely to get folks’ needs met than some other strategies – for example, those implicit in “traditional business value-system” a.k.a. the Analytic Mindset.

How does this all fit with your values?

- Bob

Further Reading

A Beginner’s Guide to Personal Integrity ~ Think Different blog post
Memes of the Four Memeplexes ~ Think Different blog post
Nonviolent Communication – A Language of Life ~ Marshall B. Rosenberg


Get every new post delivered to your Inbox.

Join 10,105 other followers

%d bloggers like this: