Hyper-joyful

Seligman refers to it as “flourishing”. Ackoff as “fun and meaningfulness”. Deming (originally) as “pride”. And Rosenberg builds the whole of Nonviolent Communication on the cornerstone of “joy”.

“Management’s job is to create an environment where everybody may take joy in his work.”

~ WE Deming

“If there isn’t joy in in work, you won’t get productivity, and you won’t get quality.”

~ Russell L. Ackoff

I don’t see joy being the explicit focus of much attention in the world of software and product development (or in many other theatres of work either, for that matter). This in itself makes me feel sad., for I have a need to see folks living a full and flourishing life. And I see work – for good or ill – as a major part of life in today’s world.

“I believe that the most joyful and intrinsic motivation human beings have for taking any action is the desire to meet our needs and the needs of others.”

~ Marshall B. Rosenberg

I feel even more sad when so many of the folks I ask seem to think that joy at work is not part of the equation or of the implicit “contract” of working for an employer. Although many folks do seem to have an interest in the subject, once it’s brought to their attention.

Even Dan Pink (Drive) has little to say about joy, directly.

I believe, as did Deming, that joy in work “unleashes the power of human resource contained in intrinsic motivation”, and that doing “quality” work is the source of much of that joy.

And as a practising Organisational Therapist with an keen interest in Positive Psychology, I’d rather devote my efforts to spreading joy than to e.g. correcting deficiencies and dealing with the inevitable consequences of a lack of joy.

I’ve given this post the title “hyper-joyful” in reaction to the concept of “hyper-productivity” which I’ve seen bandied-about more and more often recently. I can’t help but feel scornful and dismissive – and yes, sad, too – every time I hear or see the term “hyper-productive”. It’s not like Agile often lives up to that aspiration, in any case. Who, in fact, can get a feel-good feeling about hyper-productivity?

“The 14 Points all have one aim: to make it possible for people to work with joy.”

~ WE Deming

Personally, I’d feel much happier if more folks talked a bit more about hyper-joyfulness – and a bit less about hyper-productivity.

How about you? Would you be willing to raise the topic of joy and joyfulness in your workplace, and with your peers?

Semper mirabilis!

- Bob

Further Reading

Dr. Deming’s Joy at Work, Happiness, & the High Performance Organization ~ Lawrence M. Miller
Nonviolent Communication ~  Marshall B. Rosenberg
Drive ~ Dan Pink

The Same Old Way

“They came on in the same old way – and we defeated them in the same old way.”

~ Arthur Wellesley, First Duke of Wellington

As someone who develops or tests software, how well do written requirements – a.k.a. “specification documents” – meet your needs?

Have you, in fact, ever thought about the ways in which you come to understand what needs to be implemented?

Or do you just take for granted that there will be business analysts cranking out specifications in the same old way, and you’ll be poring over them in the same old way, ad nauseam?

Who Serves Who?

Do you see your business analysts as the experts on the expression of requirements, and defer to them in such matters? Or do you have a more of dialogue about your needs as implementors, and about how they (the business analysts) might best serve you and your needs?

The Agile Thorn

In Agile development, of course, three of the four core values in the Agile Manifesto are:

• “Working software over comprehensive documentation”
• “Individuals and Interactions” over processes and tools”
• “Responding to change over following a plan”

I have long chosen to interpret this as meaning that developers and the people with the detailed vision of the product – if not one and the same – get together as interacting individuals and explore, exchange and refine their common understanding of the emerging “requirements” by building working software – and not by cranking out and then working from comprehensively documented requirements specifications (in effect, a plan a.k.a blueprint).

Aside: My thanks to @michaelbolton for providing the related insight that the content of requirements specifications (documents) are much too often mistaken for and confused with the “real requirements” i.e. what the users, etc. of the software, product or service might actually want.

Who Leads Who?

As a business analyst, have you explored the needs of the implementors, with them? Inspected together how you and they come to understand what needs to be implemented, and adapted to best – or at least, better – meet those needs?

Who is better placed to initiate or lead this kind of dialogue? Does this fall under the general heading of “Business Analyst expertise” or are the implementors best placed to initiate and/or lead the conversation?

Scrum

Lest we forget, or overlook the Scrum perspective on this subject, in Scrum there are only three roles: “The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master”. Also note: “Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis.”

Effective?

So, the core question remains: In highly-effective development work, are there alternate, more effective means for deciding what gets implemented (and incidentally, when) – or is everyone just stumbling along “in the same old way”?

- Bob

Slow Change

Progress in learning organisations comes in its own time, at its own pace. Some folks might wish to see that pace accelerated.

“Be careful what you wish for, you may receive it”

~ from The Tale of the Monkey’s Paw

I share the belief of the folks in the Slow Movement, that care, concern for others, the building of meaningful connections and relationships – the bedrock of the learning organisation – is best tackled unforced and unhastily.

“The only thing for certain is that everything changes. The rate of change increases. If you want to hang on you better speed up. That is the message of today. It could however be useful to remind everyone that our basic needs never change. The need to be seen and appreciated! It is the need to belong. The need for nearness and care, and for a little love! This is given only through slowness in human relations. In order to master changes, we have to recover slowness, reflection and togetherness. There we will find real renewal.”

~ Professor Guttorm Fløistad

Where does that leave the frantic clamour for change in most organisations today? For the large part, I’d say it leaves it screaming into the wind. Forcing change faster than its natural pace makes no sense to me, bringing as it does a whole host of inevitable dysfunctions, such as stress, disassociation, and disaffection.

Better, I think, to take things as they come, to take careful steps, with maybe a tad of due consideration for progressing in the right direction.

And to take time to see each other as human beings, to encourage a sense of community, of a journey made together, not for the sake of arriving, but for the joy of the journey.

So, when considering the pace of change, would you be willing to fret a little less about seeing things happen faster, and become a little more comfortable with the natural rhythms and pace of events?

- Bob

Learning to Let Go

I’ve just come back from six weeks in Delhi, working there with around eighty people engaged in software development – mainly coding and testing – as members of a number of different product teams located in various other geographies around the world.

This post is by way of thanks to the Delhi folks for their hospitality, generous spirit, and humanity – and for helping me (re)learn a valuable lesson.

The Lesson Relearnt

The lesson in question is: people do not learn from hearing things.

I see my present role – of which my time in Delhi was but one example – as fundamentally about inviting folks’ curiosity and interest. No more, no less. In essence I am asking the question:

“Would you be willing to examine with me – or amongst yourselves – your current views and assumptions regarding the field of software and product development?”

Whether they choose to accede to the request or not matters to me – not because I have any agenda for them, but because my needs include making meaningful connections with people, and helping folks’ life become more wonderful. Given the amount of time folks spend at work, I can think of few better opportunities to pursue my needs. If people choose not to engage with my request, I respect that choice, even though I personally see it as a lost opportunity for all concerned.

Letting Go

So, of what am I “letting go”? I’m letting go of the need to be an expert. Of the need to have answers to their problems (I don’t even know their problems, really). And of the need to tell them all about how highly-effective software and product development works. As someone who has been examining my own views and assumptions of software and product development for the best part of forty years, I’m letting go of the idea that I can help people learn and grow by simply telling them things from my own experiences. Unless they ask. And they may not know that asking me is an option.

“We cannot teach people anything; we can only help them discover it within themselves.”

~ Galileo Galilei

Some years ago, recognising the dysfunctions inherent in telling folks things, I used to withhold information unilaterally – until I thought folks were ‘ready’ to hear it, piece by piece. Having learned from e.g. Argyris, Noonan, Kline and Rosenberg, nowadays I try to make it clear that, to the extent that I have any knowledge or information that might be useful to someone, the timing and manner of its sharing can be something on which we can decide together.

I suspect this notion of self-paced ‘pulling’ of information or knowhow is pretty novel to many people. And so I suspect that many may not connect with the notion straight away. At least, not in a way that they might immediately benefit from.

Summary

In summary then, in attempting to help folks have a more wonderful life at work, I believe that if I have any part to play it’s in simply being there, with them, giving of my full attention:

“The quality of our attention determines the quality of other people’s thinking. Attention, driven by deep respect and genuine interest, and without interruption, is the key to a Thinking Environment.”

~ Nancy Kline, More Time To Think

- Bob

Product Aikido

Photo Credit: Sigurd R

I wrote a post some time about Doctrine, although in that case I was writing about business, and the potential value to an organisation in defining just what it means by the term “business”.

“I reject any doctrine that does not appeal to reason and is in conflict with morality.”

~ Mahatma Gandhi

Since then I have been working on a first draft of a doctrine for Product Development, which I have named “Product Aikido” (presently, a document of some eighty five A5 pages). My motive for this has been the belief that there is much value in (product) organisations having a shared, common understanding of what product development is, and how it is conducted.

Note: The colophon at the end of the document explains a little more about the choice of name, amongst other things.

I offer this first draft here for your kind consideration. Any feedback, questions, comments or suggestions you might have for its improvement will, as always, be most welcome.

Excerpt

“The essence of product development is an intense and ongoing struggle between organising intent and entropy. Organising intent is the will of the company, manifest in the actions of its product development people, bent on meeting the goals of the company through the creation and evolution of products and product features.”

- Bob

Optionality – The Double-Edged Sword

Having asked some difficult questions in my previous post, and not found many clear answers, I’d also like to bring up the question of optionality.

I’m pretty sure that many people, particularly those of an implicitly violent predisposition, might rail against the idea of folks being free to choose whether to participate in change, and what changes to embrace or decline. Is this not a recipe for anarchy and the undermining of all discipline and authority?

Well, as I see it, folks choose whether to participate in change, and what changes they will each embrace or decline, in any case—whether they are nominally “free” to choose, or not. It’s just that in many situations, they keep their choices secret, and when their opting-out of certain changes IS somehow noticed, other folks remark on their apparent “disengagement”.

We can of course choose to treat people like children, coercing or otherwise motivating them to (pretend) to accept the changes.

But in organisations more Theory-Y in outlook, where the idea of treating people like consenting adults has more traction, is it not more congruent to make the optionality of involvement in change something clear and unambiguous? Might this not reap benefits in term of the health of the social fabric of the organisation? And might it not allow us all to see more clearly which changes have wide support, and which are seen as unhelpful or irrelevant?

“If you do not change direction, you may end up where you are heading”

― Gautama Buddha

I titled this post “…the Double-Edged Sword” because optionality cuts both ways. If folks are free to opt in or out of something, both options will likely have consequences.

I have found that folks often think deeply about the consequences of change (the opting-in to change choice) but little or not at all about the consequences of no-change (the opting-out of change choice). Ackoff refers to this phenomenon as “errors of commission vs errors of omission” and observes that people rarely get criticised for errors of omission (e.g. not taking a decision).

Whatever the reason, sticking with the status quo generally has at least as many consequences as opting for change.

Disclaimer: It would make my life a bit easier if folks could wake up to this.

- Bob

The Ethics of Change

Engaged as I am in what some might choose to call a “change programme”, I’ve had some occasions to ponder recently the ethics of change.

It is ethical to change people? Even given the truism that we can’t change others, we can only change ourselves, is it ethical to even contemplate changes to a system (the way the work works) with the idea of maybe seeing some behavioral changes in the folks working within that system?

As my ethical system these days is fairly bound up with nonviolence, for me the question resolves to “is asking questions with an intent to raise folks’ awareness actually a kind of violence?”

And given that’s what I’ve been doing recently —asking such questions—how far can one travel down that road before it becomes an act of violence? Put another way, where does “making meaningful connections with folks, through dialogue” end, and “coercion through asking leading questions” begin?

My working position on the question, presently, revolves around the twin notions of informed choice and need.

Informed Choice

To the extent that people realise what’s going on, and that they understand that they have a choice whether to participate or not, then I can live with the situation.

Needs

In the vernacular of Rosenberg, do folks need some change? If not, then forcing or coercing anyone into change seems to cross the ethical line. But how to broach the question of needs with each individual? Is even asking the question, starting the conversation, on dodgy ground. How about if we ask the question “Would you be willing to have a conversation about the prospect of change here, and what your needs might be therein?”?

What about folks that don’t realise what’s going on? Or have not (yet) understood the optionality of the situation? Does it behove us to do everything possible to help them understand, or is that effort—in the absence of their consent and need for realisation—in itself unethical?

- Bob