Archive

Monthly Archives: October 2018

Random Walks

How well does the almost universal Agile practice of “build it and see if they come” serve us (as developers, as customers)?

I suggest it’s time to rethink our belief that customers (and developers, for the most part) “don’t know what they want until they see it”.

My late, great colleague and friend Grant Rule used to refer to the practice, common in the Agile domain, of building (a portion of) something to see if the customer likes it as “random walks through the problems-solution space”.

Quality Demands Requirements

Philip Crosby, a widely acclaimed “guru” of Quality Management, defined quality as “conformance to requirements”. As simple and blunt as that.

Recently, I’ve been reflecting on my experiences with software product development, especially the development of “quality” products that customers love. In Javelin, we place special emphasis on de-risking delivery through explicitly defining the customers and their respective requirements. Not big-bang, up-front stylee, but incrementally, just enough each couple of days to build a little more of the product and deliver it to the customer(s) for their delight, confidence, and feedback.

But in our approach, requirements (in the frame of the Antimatter Principle we call these needs) precedes building anything. Agile shops these days seems to major in building something before discussing requirements (if they ever get discussed at all). BDD offers an exception, but how many shops do BDD?

Aside: In Javelin, we identify all stakeholders (a.k.a. all the Folks That Matter), discuss their needs (“Stakeholders’ Needs”, in Javelin parlance) and quantify them (a la Gilb – see: Competitive Engineering) in the form of Quantified Quality Objectives. Although:

  • This all generally proceeds incrementally, rather than in a big batch up front.
  • The information is always to hand by the time someone gets around to building the relevant part of the thing in question.
  • The requirements come from dialogue(s) with the relevant Folks That Matter.
  • The requirements need not get written down (documented) unless there are some Folks That Matter that need them to be.

People work from the requirements. Always.

Random Walks are not Our Bag

Random walks are not our bag.

By cleaving to the belief that customers “don’t know what they want until they see it”, and structuring the whole approach to development around this belief, Agile shops have no incentive to improve the way they work with customers to understand their needs. No incentive to improve requirements elicitation and capture. No incentive – or means – to prevent defects and deliver zero-defects quality. Indeed, this belief and its associated practices blocks us from working to continually find better ways to create useful requirements (formal statements of folks’ needs) from which to drive quality (cf Crosby) and the improving of relationships with each other (developers, ops) and with customers.

Is this emphasis on working-from-clearly-stated-and-agreed-requirements better? Well, in my experience it makes for happier customers, happier developers, and more successful products. I’ll leave it to you to decide whether and how that’s “better”.

– Bob

Digital Transformation

It seems like “Digital Transformation” of organisations is all the rage – or is it fear? – in C-suites around the world. The term implies the pursuit of new business models and, by extension, new revenue streams. I’ve been speaking recently with folks in a number of organisations attempting “Digital Transformation”, some for the fourth or fifth time. I get the impression that things are not going well, on a broad front.

What is Digital Transformation?

Even though the term is ubiquitous nowadays, what any one organisation means by the term seems to vary widely. I’ll attempt my own definition, for the sake of argument, whilst recognising that any given organisation may have in mind something rather different, or sometimes no clear idea at all. Ask ten different organisations what Digital Transformation means to them, and you’re likely to get at least ten different answers.

Digital Transformation is the creation and implementation of new business models, new organisational models and new revenue streams made possible by the use of new digital technologies and channels.

~ FlowchainSensei

Ironically it’s proving to NOT be about technology, but rather about company culture (this, in itself, being a product of the collective assumptions and beliefs of the organisation).

“A significant number of organisations are not getting [digital] transformation right because of a fundamental quandary over what digital transformation really is.”

~ Brian Solis, principal analyst and futurist at Altimeter

My Interest

So, why am I bothering to write this post? Aren’t there already reams of articles about every conceivable aspect of Digital Transformation?

Well, one aspect of Digital Transformation I see little covered is that relating to the development of “digital” products for the digitally-transformed company. And the implications this brings to the party.

Digital Transformation requires the development of new products and services to serve the new business models, new organisational models and new revenue streams. Digital products and digital services. In most cases, this means software development. And organisations, particularly untransformed organisations – which even now means most of them – are spectacularly inept at both software development and product development. Some refer to this as “a lack of digital literacy”.

Things have not changes much in this arena for the past fifty years and more. Failure rates resolutely hover around the 40% mark (and even higher for larger projects). And the much-vaunted (or is it much cargo-cullted?) Agile approach to development has hardly moved the needle at all.

For the past two decades I have been writing about the role of the collective psyche – and the impact on organisational effectiveness of the collectively-held assumptions and beliefs about how work should work. And make no mistake, effectiveness is a key issue in digital product development. Relatively ineffective organisations will fail to deliver new digital products and services at least as often as 40% of the time. Relatively effective organisations can achieve results at least an order of magnitude better than this.

The Marshall Model provides an answer to the question: what do we have to do to become more effective as an organisation? And it’s not a popular answer. By analogy, people looking to lose weight rarely like to hear they will have to eat less and exercise more. Organisations looking to become more effective rarely like to face up to the fact that they will have to completely rethink long-held and deeply-cherished beliefs about the way work should be organised, managed, directed and controlled. And remodel their organisations along entirely alien lines in order to see a successful Digital Transformation and compete effectively in the digital domain.

Successful Digital Transformations demand organisations not only come up with new business strategies, organisational models, revenue streams and digital products and services, but also that they shift their collective mindset to one which aligns with their ambitions. Personally, I see shifting the collective mindset as an essential precursor to the former. Most organisations approaching Digital Transformation fail to recognise this inevitability, this imperative. And so, most Digital Transformations are doomed to underachieve, or fail entirely.

“Ask yourself whether what you’re doing is disruptive to your business and to your industry. If you can say yes with a straight face, you may well be conducting a legitimate digital transformation.” And if you’re unable to say yes, then whatever you’re doing, it’s likely not a Digital Transformation.

If you’d like to explore this topic, understand more about the Marshall Model, its relevance and its predictive power, and save your organisation millions of Dollar/Pounds/Euros – not to mention much embarrassment and angst – I’d be delighted to chat things over with you and your executive team.

– Bob

Further Reading

Reinventing Organizations ~ Frederic Laloux

Effectiveness

I recently had a bit of a wake-up call via Twitter. I asked the following question:

“What’s the one thing /above all/ that makes for an effective organisation?”

My thanks to all those who took the time to reply with their viewpoint. The wake-up call for me was the variety of these responses. All over the map might be a fair description. Which, given I’ve been writing about effectiveness in the context of organisations for more than a decade now, tells me I’ve some way to go to get my perspective across. Not that I’d expect folks to respond by simply parroting my definition, of course. And nor do I claim any special authority over the term.

Goldratt defines (in)effectiveness as:

“Things that should not have been done but nevertheless were done.”

Drucker defined it as:

“Successfully aligning behaviour with intentions.”

Aside: It’s been my experience that (organisational) effectiveness gets little attention or focus in most organisations. And seeing as how in most organisations things are so ineffective, I’ve come to believe that those making the calls don’t see a need for effectiveness.

Spectra

Effectiveness is a spectrum. From highly ineffective through to highly effective. Note that this spectrum is orthogonal to the spectrum of organisational success (by whatever measure you might choose for success: revenues, profits, social impact, personal kudos, joy, employee satisfaction, customer satisfaction, quality, returns to shareholders, executive bonuses, w.h.y.).

Effective organisations are not necessarily successful, and successful organisations are not necessarily effective. I posit that effectiveness can help create, contribute to, and sustain success. I seem to be in a minority.

Survey Results

Here’s the responses I received to my question “What’s the one thing /above all/ that makes for an effective organisation?”:

  • @FragileAgile: “Folks needs being intentionally met.”
  • @andycleff: “+1 to Trust. Foundation for all the things.”
  • @LMaccherone: “Happy paying customers”
  • @stuart_snelling: “Accurate, contextual and meaningful data that is readily accessible.”
  • @ChangeTroops: ”Growth mindset.”
  • @allygill: “Effective people who understand the needs of their customers (internal and external) and each other.”
  • @KarimHarbott: “Totally and utterly dependent on what they are trying to achieve.”
  • @ArnoutOrelio: “People”. “Their ability to improve things; their creativity.”
  • @gertveenhoven: “Trust.”
  • @ferigan: “A team structure that doesn’t require effort to collaborate in and allows work to flow well.”
  • @anam_liath: “Common vision and ideals.”
  • @rogersaner: “Empowering your people.”
  • @sourabhpandey05: “I would say ‘Culture’ of the organisation. Culture which promotes1 the values trust, transparency, respect for everyone.”
  • @heybenji: “Ingenuity.”
  • @joserra_diaz: “Mindset of the owner.”
  • @ard_kramer: “Autonomy for individuals and a common understanding of what is of value for the organisation.”
  • @martinahogg: “Alignment.”
  • @briscloudnative: “Love.”
  • @barryfarnworth: “Understanding purpose….”
  • @mikeonitstuff: “Ultimately I think it’s leadership. The leaders set the stage for the culture and the vision for the organization. Poor leadership can destroy value and morale, great leadership creates the conditions for high performance.”
  • @EricStephens: “Uniform Commitment to the mission.”

For each of the above, I invite you to apply this litmus test: “if we had this, would we then necessarily be effective?”

Rightshifting

Some folks asked me for my “answer”, so here it is:

Rightshifting and the Marshall Model both attribute (relative) organisational effectiveness to the prevailing collective mindset. That’s to say, what an organisation collectively believes about how the world of work should work will absolutely dictate how effective that organisation will be. Any organisation wishing to become significantly more effective faces the formidable challenge of changing its collective assumptions and beliefs about work (in the broadest sense of the term). In other works, change the prevailing paradigm, or better yet, acquire the power to transcend /any/ particular paradigm.

For clarity then, the one thing above all that makes for an effective organisation is its collective mindset a.k.a. memeplex.

This echoes the famous “Twelve Leverage Points to Intervene in a System” by Donella Meadows:

– Bob

Ending Therapy

Plan for the Ending

Any therapy relationship is likely to end, sooner or later. Sometimes it’ll be a happy ending, sometime less so. Although the seeds planted during therapy often means the client can continue to grow and develop, becoming more whole, more congruent, in their own time and under their own tutelage.

There are many reasons clients decide to end therapy. Sometimes they’ve reached their goals. Sometimes they need a break. Sometimes the connection with their therapist isn’t there. Sometimes they notice a red flag. Sometimes they’re about to face a new fear or realise a new insight.

Whatever the reason, it’s vital the therapist and the client brings it up as soon as either party becomes conscious of it. Wanting to end therapy is a critical topic to explore. And it could be as simple either the client or the therapist saying “I feel like it might be time to end therapy, I wonder what that’s all about?”.

An end in therapy can be more like a bittersweet parting than a sad, abrupt, or complicated loss. Ideally, clients can have a satisfying closure to therapy that will help them end other relationships well in the future.

Processing negative feelings can be a way to work through maladaptive patterns and make the therapeutic relationship a corrective experience. If clients avoid this conversation by simply discontinuing therapy, they may miss the opportunity for a deeper level of healing resulting from their therapy.

I find it helpful to mention the ending even from the outset of the therapy relationship. If only in the information conveyed as part of the setup of that relationship.

Any particular client may find it a distraction, discomforting, or scary to entertain the idea that the relationship – or, at least, the therapy – might come to an end even as it’s just getting started. So the timing of the broaching of the subject generally depends on how things are going.

Advice for Clients re: Ending Therapy

  1. Examine your reasons

A positive approach to ending therapy is to delve into the possible reasons why you’d like to leave. Is it because you feel disrespected, stuck or incompatible or because of feelings of discomfort in dealing with certain things that the therapist is pushing on me on? It’s common and part of the process of changing problematic patterns, to feel triggered and even angry with your therapist.

  1. Don’t stop suddenly

It’s important for clients to discuss the ending with their therapists, because they may suspect that the desire to part ways is somehow premature. Even if a client decides to leave therapy, processing this can be therapeutic in itself. Some sessions discussing  the subject, including feelings and what kinds of post-therapy experiences the client might go through can help ease the guilt, regret or sadness that often arise.

Plus, honouring the relationship and the work everyone has done together, with some sessions to achieve closure in a positive way can be a very powerful experience in its own right.

  1. Talk in person

Avoid ending therapy with a text, email or voicemail. Speaking directly is an opportunity to practice assertive communication and perhaps also conflict resolution, making it is an opportunity for learning and growth.

  1. Provide honest feedback

If you feel comfortable and emotionally safe doing so, it is best to be direct and honest with your therapist about how you are feeling about him or her, the therapeutic relationship or the approach you’ve been experiencing. After all, this has been a partnership, and part of growth is to embrace that, see the therapist as a human being, and see other folks’ needs met – including the therapist.

When offering feedback, do so without judgment. After all, the therapist will be working with other organisations and your thoughts may change their style and help them to better serve their clients in the future.

A good therapist will be open to feedback and will use it to continually improve.

  1. Communicate clearly

Be as direct, open, and clear as possible. Articulate the exact reasons for wanting to end therapy.

  1. Be ready for dissent

It is not unusual for a therapist to agree with ending therapy, especially if the client has reached their goals and is doing well. But they also might disagree. This disagreement can serve positively, as a spur to enhance the ability for discussing difficult topics.

Every therapy ends, there’s no reason to avoid this reality. Early in therapy, when discussing goals, why not talk about how and when therapy might end.

Advice for Therapists re: Ending Therapy

  1. Invite feedback

Most personal therapists note that having their clients share feedback on their experiences is incredibly valuable. It’s no different in the OP context. Feedback helps therapist  improve and grow as practitioners.

  1. Sometimes we won’t know why

Sometime we won’t get to know why a client ends their therapy. The connection can just fizzle out, with little to no contact or explanation. As we’re very invested in our work and in our relationship with the client, such an ending can be both a puzzle and a disappointment.

  1. Practice letting go

Some clients simply stop, so it’s not easy to know if they’re just ‘done’ with therapy or if we’ve done something to make them want to leave. When this is the case, I just let it go. It’s their issue, not mine, and I don’t need to worry over it when I don’t know the reasons behind it. Of course we could wish it were otherwise, but letting go can be the hardest thing.

  1. Enjoy the experience

When client and therapist are able to have some sessions for proper closure, it becomes a great opportunity to reflect on their work together. These sessions can be highly joyful, for both parties.

Our goal is to support our clients in confronting life and the issues they see as holding them back, blocking them from greater success. If clients have clear reasons to end therapy and we’ve had the time to talk about it and tie up the loose ends, ending therapy is a great time to reflect on our work, invite the client to talk about their future, and discuss what has been accomplished and what hasn’t. We can leave with a sense of closure, without nagging, unresolved issues. And with the sense that the client is now netter placed to tackle themselves new issues that might arise in their future.

Those precious final sessions afford the opportunity to relax, reminisce about our shared experiences, ponder the future, and learn how to be a better therapist for others.

When clients can approach the ending of therapy with respect, dignity and integrity, that sets the tone for other relationship issues. In other words, with proper closure, everybody wins.

In your practice, how often do you plan for the ending?

– Bob

The Relevance of Giants – 2. O Sensei (Morihei Ueshiba)

On most every occasion when I’m speaking in public – at conferences, workshops, and the like – I tend to mention one or more of my “Giants” of Rightshifting. Men and women who, through their lives and work have contributed significantly to my understanding of work, and in particular to my understanding of effective collaborative knowledge work.

Many folks express interest in these Giants, but I do wonder if they appreciate the relevance of the ideas and experiences of these Giants to their own daily lives at work.

I mean, what relevance does, say, O Sensei have to developers, testers, operations staff and the like? Which aspects of any of these Giants’ work could be useful or helpful or simply comforting to these folks?

In this occasional series of posts I’ll be exploring some of the Giants’ relevance to folks other than theorists, managers, consultants and the like. I’ll be sharing some insights into their work, and specifically, the likely relevance.

With these posts I hope to pique your curiosity just a little. Let’s continue, with this second post in the series, with O Sensei.

O Sensei

Morihei Ueshiba

(December 14, 1883 – April 26, 1969)  (See also: Wikipedia entry)

I’m not going to dwell on his early life and experiences in the Japanese Army, his adventures in Mongolia, nor his experiences in Manchuria and Japan during the time of World War 2.

Aikido

I suggest the primary relevance of O Sensei to most folks working in the field of software development (and production operations) is Aikido – the martial art he developed. Excepting it’s less a martial art, and more a philosophy for life, and for harmonising with others.

Unlike many other martial arts, Aikido is focussed on caring for others, as emphasised by the translation of the three kanji: ai-ki-do as the Way of Unifying Spirit or the Way of Spiritual Harmony. O Sensei envisioned Aikido as an expression of his personal philosophy of universal peace and reconciliation. O Sensei’s goal was to create an art that practitioners could use to defend themselves while also protecting their attacker from injury.

Blending“, one of the core techniques of Aikido, invites us to look at conflicts from the perspectives of the other person – or people – involved. For me, this has a direct connection with empathy – as promoted by e.g. Marshall Rosenberg and others of the nonviolent community.

“Life is growth. If we stop growing, technically and spiritually, we are as good as dead.”

~ Morihei Ueshiba

Where’s the Relevance?

How do we make it more likely that we’re all spending our time on stuff that matters? How do we go about attending to folks’ real needs? I find blending a great asset in identifying with the needs of others. As I blend, I see their perspective, and their needs, more clearly. And in turn, they can feel more listened-to. And choose to reveal other things, crucial things, that means we get to understand more about what matters to us all. With this knowledge – and goodwill – we have a better chance of focusing on what matters, and of reducing the chance of wasting some or all of our time on the inconsequential, on detours, and on dead ends.

Practical Investigation

You might like to join an Aikido dojo, to practice the physical forms of the techniques. And to discuss the philosophy with like-minded people wha have already started the journey. Beware, though, of those dojos and sensei that emphasise the physical forms at the expense of Aikido philosophy.

– Bob

Further Reading

The Life We Are Given ~ Michael Murphy, George Leonard
The Way of Aikido ~ George Leonard
It’s A Lot Like Dancing ~ Terry Dobson

The Relevance of Giants – 1. Deming

On most every occasion when I’m speaking in public – at conferences, workshops, and the like – I tend to mention one or more of my “Giants” of Rightshifting. Men and women who, through their lives and work have contributed significantly to my understanding of work, and in particular to my understanding of effective collaborative knowledge work.

Many folks express interest in these Giants, but I do wonder if they appreciate the relevance of the ideas and experiences of these Giants to their own daily lives at work.

I mean, what relevance does, say, Bill Deming have to developers, testers, operations staff and the like? Which aspects of any of these Giants’ work could be useful or helpful or simply comforting to these folks?

In this occasional series of posts I’ll be exploring some of the Giants’ relevance to folks other than theorists, managers, consultants and the like. I’ll be sharing some insights into their work, and specifically, the likely relevance.

With these posts I hope to pique your curiosity just a little. Let’s start with Bill Deming.

W. Edwards Deming

Bill Deming

(October 14, 1900 – December 20, 1993)  (See also: Wikipedia entry)

I’m not going to dwell on his work in SPC (Statistical Process Control) or SQC (Statistical Quality Control), his pivotal role in the Japanese post-war economic miracle, his 14 Point system of thought he called the “System of Profound Knowledge”, nor his Plan-Do-Study-Act (PDSA) cycle (the latter being the basis for most Agile approaches, btw).

Deming’s 95/5

I suggest the primary relevance of Deming to most folks working in the field of software development (and production operations) is primarily the idea known as “Deming’s 95/5” (although this originated in a quote from Peter Scholtes).

“The fact is that the system that people work in and the interaction with people may account for 90 or 95 percent of performance.”

From my studies of Deming, and from applying his ideas in my practice, I have come to believe that it’s the interactions between people that account for the lions share of “productivity”, “performance” and “success” in collaborative knowledge work. And the “system” a.k.a. the way the works works has a major (hidden) influence on the quality of those relationships, as well as on the work (output, results) of the individual workers.

“Dr. Deming taught me that 95% of the performance of an organization is attributable to the system (processes, technology, work design, regulations, etc.) and [only] 5% is attributable to the individual.”

~ Tripp Babbitt

Where’s the Relevance?

If, like most people, you’re looking for a better quality of life at work, Deming points the way to us improving our relationships with our colleagues, peers and managers. Maybe this perspective is something to consider on those occasions when you’re less than happy in your work, when you’re checked-out, or disengaged, or frustrated.

And Deming’s attribution of 90-95% of your performance to the system within which you’re obliged to work throws a new light on many typical organisational practices such as history-led recruitment, performance appraisals and reviews, stack ranking, criticisms (and praise) for your efforts, etc.. Your results (and self-esteem) may be taking a hit from the effects and constraints inherent in that system, not from anything you’re doing (or not doing) yourself.

Practical Investigation

Deming designed the Red Bead Experiment to illustrate these very points, in a way that most people can directly relate to.

– Bob

Further Reading

Four Days with Dr Deming ~ Latzko and Saunders
95% of performance is governed by the system ~ Vanguard web page