Archive

Coaching

Are You Stuck?

stuck

Are you stuck between a rock and a hard place? Is your heart telling you to do something, when your head is telling you not to? Or maybe it’s the other ways round – but still as problematic?

Do you see no way forward? No light at the end of the tunnel? Just endless busywork?

Are outside pressures getting to you? Do you have people relying on you? Is your job on the line? Your self-image under threat?

I see this kind of dynamic all too often. I say all too often because it bothers me. To see someone in a quandary bothers me. And it bothers me all the more because, so often, someone can be so stuck that they can’t even see how to find help. Or that “help” might actually help. And I know there are people that can help. Coaches, therapist, friends, fellows. Including me. It’s what I live for, actually.

Is there anything to be done? Yes. And I’m not going to use fear, obligation, guilt or shame to “help” you to get unstuck. Actually, I’m not going to use anything. Just invite you to consider if you are stuck at the moment. And if so, invite you to check out the many, many articles, posts, etc., out there on the intarwebs, offering ideas on getting unstuck.

Because, I’ve found the key to getting unstuck is recognising one’s stuckness in the first place. Oh, and then doing something about that. Natch. There’s even an app for that.

“Getting unstuck is half the fun in life.”

And if you find something that works for you, maybe you’d like to share it, through a comment, here?

- Bob

Further Reading

16 Ways To Get Unstuck ~ Tiny Buddha
7 Ways To Get Unstuck ~ Sura

 

Write Your Own – Flow

One of my core specialisms these days is organisation-wide product development flow. I was about to write a new blog post on the subject when I saw this, which reminded me there could be a better way:

Students learn better when they think they’re going to have to teach the material.

This set me to thinking. Why write a blog post? That’d be a bit like teaching on the subject, wouldn’t it? How about posting e.g. an outline of topics (using something like the Pyramid Principle) and see if folks would enjoy researching and writing their own version of the post (or article, or mini- e-book)?

So, here’s my outline for a book on Product Development Flow. If you’re inspired to fill in some of the blanks, like you were trying to inform/teach others, great. I’d be happy to help with some pointers, etc. Just drop me – @FlowChainSensei – a line on e.g. Twitter. And if you’d like some wider audience for what you write, please feel free to post the URL or whatever in the comment section below, or tweet me so I can retweet for you.

And if you’d value someone to whom present your writing directly, I’ll be delighted to volunteer to read it.

Here’s the outline:

Product Development Flow

  • Introduction
    • Purpose of this book
  • Overview
  • Definitions
    • What is a “Product”?
    • What is “Value”?
    • What is “Product Development”?
    • What is a “ValueStream”?
      • Where do value streams come from?
      • Prod•gnosis
    • What is “Flow” (of e.g. Value)?
    • What is “Product Development Capability”?
    • What is “Product Development Capacity”?
  • Key Organisational Capabilities / Concepts
    • People
      • Collaboration
      • Motivation
    • Innovation
    • Entropy
    • Continuous Improvement
      • Kaizen
      • Kaikaku
    • Variation and SPC
    • Work In Progress (WIP, WIP limits)
    • Making things – like Flow – visible
    • Organising Intent (a.k.a. Commander’s Intent, Auftragstaktik)
    • Relative Effectiveness
    • Quantification
    • Emotioneering
    • Lean
      • Lean Product Development
      • Lean Startup
      • Lean Service
    • Idealised Design
    • Systems Thinking
    • Queueing Theory
    • Organisational health
    • Philosophy and doctrine
    • Financials
      • Cost of Delay
      • ROI
  • Foundations
    • Russell L. Ackoff
    • W.E. Deming
    • Peter Drucker
    • John Gall
    • Douglas McGregor
    • Taiichi Ohno
    • Eliyahu M. Goldratt
    • Peter Senge
    • John Seddon
    • Donella Meadows
    • Allen C Ward
    • Michael Kennedy
    • Don Reinertsen
    • Tom Gilb
    • Steve McConnell
    • Nancy Kline – Thinking environments
    • Argyris, Isaacs, Bohm et al. – Skilled dialogue
  • Exemplars
    • TPDS – The Toyota Product Development System
    • FlowChain
    • Product Aikido
  • Other / miscellaneous

- Bob

Further Reading

Lean Product and Process Development ~ Allen Ward
Product Development for the Lean Enterprise ~ Michael Kennedy
The Principles of Product Development Flow ~ Don Reinertsen
Lean Product Development Flow ~ Bohdan W. Oppenheim (pdf)
Sketching User Experiences ~ Bill Buxton
Managing the Design Factory ~ Don Reinertsen
Learning To See ~ Mike Rother

TDR – Test Driven Relationships

TDD (Test Driven Development) seems fairly well known as a software development technique these days – even though uptake and understanding remains “patchy”. TDD purports to improve the quality of code by focusing on the intended behaviour of a piece of code before writing that code.

I believe that relationships – interpersonal relationships, relationships between people – are what really matters in work – and particularly in collaborative knowledge-work. Far more than code quality – although that’s handy, too.

One question which folks ask me regularly is “how might we go about improving the quality of our relationships?” I propose TDR – Test Driven Relationships might offer a way forward.

What is a Quality Relationship?

Psychology and psychotherapy have quite a lot to say about what makes for a quality relationship.

Gregg Henriques offers the “5 Cs” model (Conflicted -> Civil -> Cordial -> Close -> Connected)

Patrick Lencioni has his “5 Dysfunctions” model (Trust -> Positive conflict -> Commitment -> Accountability -> Results)

The Fundamentals of TDR

In improving relationships, it’s often helpful to try things out. For example, if we’re wanting to be more empathetic, it can be useful to try to guess how someone is feeling, and then ask them how close to the mark our guess is.

“In relationship, business, classroom, and parent-child conflicts, we can learn to hear the human being behind the message, regardless of how the message is framed. We can learn to hear the other person’s unmet needs and requests. Ultimately, listening empathetically does not imply doing what the person wants; rather, it implies showing respectful acknowledgment of the individual’s inner world. As we do that, we move from the coercive language we have been taught to the language of the heart.”

~ Marshall Rosenberg

Taking this principle and extending it, TDR says “define the results you expect – or desire – from an upcoming interaction with someone, plan an approach, have the interaction, and then compare the results against those expected / desired”. If the results don’t match up, refactor you approach to the interaction and try again.

As a reference and comparison, here’s the vanilla TDD four-step red-green-refactor process:

  1. Add a test – the simplest possible
  2. See it fail (red)
  3. Make all tests (to date) pass, using the minimum amount of instructions (green)
  4. Refactor

Why It Works

TDR helps us clarify our intent, and experiment in small increments with the way we relate to others, adjusting as we find things that don’t work so well, aw well as things that work particularly well.

“Every time I mess up is a chance to practice.”

~ Marshall Rosenberg

TDR also allows us to better keep the idea of “relationship quality” in our minds, and provides us with a practical means to focus on improving that quality.

For those who object to TDR on the grounds that it’s somehow fake, I offer the following advice:

“Fake it ‘till you make it.”

~ Neil Gaiman

How important is relationship quality to you? And what are you already doing about that, by way of e.g. deliberate practices?

- Bob

The Words We Use

Violence is so endemic in our society and workplaces that we rarely notice it. Nor notice its effects.

Why does it matter? Well, we humans generally feel less happy when victims of violence – however minor or unremarked. But setting aside that general point, anything that negatively impacts our state of mind has similarly negative implications for knowledge workers’ productivity and the quality of that work.

“Most of what we call management consists of making it difficult for people to get their work done.”

~ Peter Drucker

And one wildly underreported source of such difficulty is the unwitting violence that happens every day in our relationships at work.

To illustrate how unaware we can be about the violence we do to ourselves and others, you might like to consider some examples. Examples of some commonly used words which not only seem innocuous, but even carry imagined positive connotations. Even these oft-lauded words can harbour implicit violence:

Discipline (verb)

Most folks take this to mean e.g. self-discipline = forcing, compelling or otherwise obliging ourselves to do things we feel we should be doing. And disciplining others = forcing them, mainly through fear, obligation guilt, shame (FOGS), or the threat of punishment, to do the things we feel they should be doing.

Professionalism

Many folks take “professionalism” to mean “constrained by expectations about how something should be done”. Here again, if we but reflect a moment, we may see the violence inherent in this idea. For example, the fear of e.g. a sanction such as ridicule or shame, when one’s behaviour does not conform to that expected of a “professional”.

Responsibility

This notion often translates to an expectation of obligation. If we are responsible for something, then we (or others) expect us to act in certain ways. Once more, we may choose to see this as raising issues of self-violence (where we take a responsibility upon ourselves) or violence done to us (where the responsibility is conferred – explicitly or implicitly – by other people, or even by rules, policy, social mores, etc.).

We Can Choose Our Words

There are, of course, hundreds if not thousands of other words, in many languages, which carry an implication of violence. How often are we aware of those implications when choosing words, and of the consequences of such choices?

Would you be willing to share some words which you find violent, in effect?

- Bob

Further Reading

Domination Systems – Duen Hsi Yen

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 your 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 the teams propose regularly get actioned? Or is their morale and continued engagement not so important to you?

Summary

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 also: 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

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

The Antimatter Principle

Photo-realistic simulation of matter-anti-matter annihilation

Antimatter is by far the most valuable substance, by weight, known to Man (around $25 billion per gram). It’s incredibly rare, amazingly expensive and difficult to produce, and yet is by far the most powerful energy source we presently know of. It’s also the very epitome of alienness.

Seems like a good metaphor for the Antimatter Principle – the only principle we need for becoming wildly effective at collaborative knowledge work.

The Antimatter Principle

Inspired by Jim Benson’s Personal Kanban, which has just two simple “rules” – “make work visible, and limit wip” – I’ve been seeking to simplify software and product development – or, in fact, any kind of knowledge work – and reduce it to just one rule:

“Attend to folks’ needs.”

The power of this simplification may not be immediately apparent, so please allow me to explain…

Attend To

Meaning, “pay attention to”. In a complicated or complex group endeavour such as developing a major piece of software, or tech product, we have the opportunity to pay attention to many things. What we pay attention to determines what gets done. Traditionally, these kinds of endeavour might pay attention to value, flow, cost, quality, customers or profits – to name just a few. But if we accept that people are central to this kind of work, then all these typical foci pale into insignificance alongside folks and their needs.

Folks’

Meaning, everyone involved. Software and product development endeavours typically involve lots of people. Not just the “doers”, but the “sponsors”, the “buyers”, and a whole host of other groups and individuals. Some folks will obviously be in the frame from the get-go, many other folks will only come into view as the endeavour unfolds. I have for many year used the term “covalence” to describe this perspective.

Needs

This reminds us that we’re working for and with people, and all people have needs, many of these tragically unmet. Needs are the universal lingua franca of the human race. Sadly, much too often overlooked or down-played. Here’s a list of needs as an example of the kind of thing I have in mind.

Expecting folks to gaily subjugate their personal needs for the Man’s coin is not only naive, but flies in the face of decades of research.

The Antimatter Principle asks us to remember to listen our own deeper needs – and to those of others – and to identify and clearly articulate what “is alive in us”. Through its implicit emphasis on deep listening – to ourselves as well as others – the Antimatter Principle fosters respect, attentiveness and empathy, and engenders a mutual desire to give from the heart. This is oh so simple, yet powerfully transformative.

Wrap

Does the Antimatter Principle, and this explanation of it, meet *your* needs?

- Bob

Follow

Get every new post delivered to your Inbox.

Join 11,133 other followers

%d bloggers like this: