Don’t give me feedback

I don’t like feedback. I’ve never liked feedback. Not liking feedback has been problematic as people take it to mean that I don’t want to learn and grow. This mindset is so prevalent that I began to believe it myself. What’s wrong with me, I wondered, that I can’t hear critical feedback? Am I so arrogant as to believe I have nothing to learn from others? Intuitively, I know this isn’t true, and yet I balk every time someone offers me feedback. I’ve come to realize that my desire to learn through listening and reflection is misaligned with the primary technique we have to drive that learning. Feedback fails us.

In 2009 I wrote a post entitled The Inadequacy of Feedback. It focused specifically on the feedback forms that are handed out by trainers and presenters after… well, just about everything these days! In that post I asked if there are better ways of giving feedback. More recently I’ve realized this is the wrong question. A more interesting question would be, how can we learn without feedback?

Feedback is judgment. Not sometimes, but always. Whether the feedback is complimentary or critical it is a judgment made by the giver on the receiver. I don’t care for your judgments, so your feedback has no meaning to me. It is just a nuisance. It sucks me into a conversation with you, or worse, with myself, that I don’t want to have and from which I learn nothing.

Positive feedback, compliments, affirmations, may occasionally be elegantly stated and delightful, but are more often awkward, and rarely offer the receiver any new insights. More important to acknowledge is that such feedback is rarely about the receiver. If I get inspired by a workshop, talk, or some other interaction my desire to praise is about meeting some need I have, and has little to do with the other. My positive feedback to you makes me feel good. Very few of us are willing to acknowledge this selfish aspect of positive feedback. When I get such feedback myself I try to be gracious, and accept it for exactly what it is: the other’s need to be heard. This may be to genuinely express what is in their heart, or to connect, or perhaps to be thought well of. It has minimal impact on who I am or what I do.

So much for positive feedback. Now onto critical feedback. We’ve probably all been in situations where a well-meaning colleague or manager asks, “are you open to some feedback?”. And then offers to go on a walk with us, or sit quietly somewhere. We all know what this means: we are about to be critiqued, and—double whammy—by someone who has set themselves up as the person to guide us to a better way of being. And then there’s the whole peer review system, where we are asked to write “feedback” on our colleagues to their manager, often in secret. All feedback is destructive, but this particular brand is especially toxic.

The arrogance of critical feedback must not be underestimated. It is deeply self-centered—and sheer folly—to believe we know how another should change, how they should improve. Every (uninvited) feedback conversation is a comedy of errors, a farce of misunderstanding, and fertile ground for resentment, mistrust, or even worse—fake trust.

Rather than getting caught in the destructive cycle of feedback, we need to explore other ways of learning through our interactions with others. One method my colleagues and I have experimented with is observation. Simple observation comes without judgement. Coupled with a quest to learn it becomes an enquiry rather than a platform for opinion. We have found this difficult, all of us trapped in our own opinions, with the corporate feedback model so ingrained in us. But we’ve been trying it, tripping up along the way, and learning through the process itself.

To give an example: I wanted to “give feedback” to a colleague that his making light of everything was an impediment (I believed) to his own learning—and frankly irritated me. I tried to phrase this as an observation: “You often use humor during our conversations.”

For this to be authentic, and not a statement couched in my inherent prejudices I first needed to do some work. I needed to recognize that i) he wasn’t doing this to annoy me, and ii) the trait may serve him in some way that I am unaware of. Freed of my opinions and my self-centeredness, and open to possibilities I could make the observation with an air of enquiry.

Another team member said he observed it too. This opened up a dialog on the use of humor in difficult situations, how it can serve, how it can waylay, how it may affect others. This led to a conversation on safety and risk, on comfort and courage. The person still uses humor much as he did before. What changed is that he is more aware of the tendency, creating choice, and perhaps more importantly (for all in our team) I am no longer threatened by it, thus my responses to the humor are more accepting and I have implicit permission to confront it if I need to. Hard to capture all this in a short blog post, but I hope the idea comes across. If I had offered this as feedback it is likely I would have learned nothing, and my colleague would either feel he needed to stop a behavior that was helpful to him, or he would have dismissed my feedback, entrenching both of us in our previously held opinions.

To summarize, feedback is judgment. It creates (or reinforces) an imbalanced power relationship between the giver and the receiver of the feedback. It may lead to resentment, entrenchment, and lack of trust. Feedback is manipulative, being almost completely focused on the one giving the feedback, with little concern for the one receiving it—except in as much as the receiver changes in the way the giver requires.

Observation gives us, whether in the position of offering or hearing the observation, an equal opportunity to learn. When learning is not two-way, there we have the root of an oppressive system.

Improv in Seattle

a promo post

Matt Smith, improv teacher, performer, and movie actor, fresh from the successful premiere of his new movie, My Last Year with the Nuns, is back in one of his favorite old haunts, The Valley School, Seattle to teach a weekend workshop on improvisation and story telling. I’ve done workshops with Matt in the past, explored ideas, and partnered with him on Scrum workshops. Much of what I offer to the Scrum community came from the work Matt and I did together. I highly recommend his engaging workshops to learn new approaches to collaboration, and to lift yourself out of fear and into risk.

The workshops take place on the weekend of 21/22 June, at The Valley School, 309 31st Avenue East, Seattle, WA. Here is the information from Matt’s website:

Spontaneity Now! Basic Improv class
Saturday, June 21st, 9am – 3pm
No previous experience necessary. It’s for everyone. And it’s a blast! This foundation class focuses on spontaneity. Replace that which keeps you rigid with advanced flexibility. So you can be better. At everything. It’s fun and fascinating. 

Create Stories That Stick 
Sunday, June 22nd, 9am – 3pm
Hello writers, storytellers, teachers, actors, or “others” reaching for scintillating material… interested in weaving stories that’ll make your audience lean in? Feeling blocked or squirmy? Then take this entirely narrative-focused class where you’ll jump into exercises that’ll put you in the mindset to uncover good, sticky narrative where it hides. It’s not just for writers! 

To sign up for one or both of these workshops, email Matt at matt (at), or call him on 206-551-4622. The cost for each workshop is $95. Highly recommended.

Project Management. Sigh!

"Let’s organize this thing and take all the fun out of it" — Ashleigh Brilliant

I’m aware that some folk think I like to dismiss project/program managers as unnecessary overhead in organizations, so I’ll start by saying I know some wonderful people who work under these titles. This post is not about people, it is about roles. I strongly believe the PM/PgM role is a cop out. It is an excuse for poor collaboration, and a necessary role only as long as developers and customers refuse to talk to one another in healthy, collaborative ways.*

XP refers to customers, development teams and coaches. Scrum refers to product owners, teams and scrum masters. Neither recognizes a PM role. And yet all these organizations currently “going agile” seem unable to let go of this role—and worse, many add whole Agile PMO (sic) offices to manage their agile transformations. If we could stop managing things, and simply let the people who do the work actually do the work we may find that Agile emerges naturally, that people become engaged, and that products get created that people care about and want to use.

We don’t make projects or programs, we make products and services. The terms project and program are used as wrappers around groups of products (or services), usually for the purpose of “sharing resources”. The argument goes something like this: we have people with specialized skills, so we need to assign them to the right work at the right time in order to maximize their value. If we don’t do this they will have idle time, and this is waste.

We can pick this argument apart, not by offering a counter-argument, but by asking a few questions, e.g. why do we (only) have specialists? Would these specialists like to learn new skills? Why do intelligent people need to be assigned work, is vision and purpose being withheld from these experts, if so, why? Is idle time necessarily bad… what might a skilled specialist do with such time? And so on. My point being that we can justify any routine behavior on the grounds that “it is just what we do”. It does not move us forward though. True, good project managers reflect (hold post mortems) and plan improvements. This is classic single loop learning where we simply keep doing the wrong thing righter. Few ask the deeper questions, few address the systemic problems that cause this thinking in the first place.

A second argument in favor of program management is: Someone has to ensure the deadlines, manage the dependencies, track the work, create reports for executives, and so on. Why have developers waste time with this work?

Again, good justification within the current paradigm. But perhaps if we stopped committing to date and scope, and focused on frequent delivery of high value, there would be no need for death markers. Perhaps if developers and product managers worked more collaboratively we could reduce—even eliminate—dependencies. Perhaps if all those doing the work cared about what they were doing, and always did their best tracking would become unnecessary. And perhaps executives could have conversations with workers—learn the truth firsthand and engage in solutions, rather than being blinded by statistics, and patronized by red/yellow/green stripes and smily/sad faces.

Our businesses need to lead with purpose. Purpose will foster engagement, and engagement will lead to joy. The more layers of management we insert, the more workers become disconnected from purpose, and disengaged. Disengagement leads to sadness, and a sense of futility, usually requiring the company to hire consultants, coaches and trainers who offer (God help us!) team building workshops. It’s a positive feedback loop resulting in a high-pitched scream of despair. We need less, not more organization. We need collaborative conversation, not excuses for our silo’d silence.

Wonderful as some of my project manager friends are, I feel sad for them, being stuck in an excuse instead of excelling in the greatness many are capable of. I’d go as far as saying that making someone a project manager is a form of corporate abuse. It needs to stop, for the sake of humanity, for the sake of sanity.


* I use the term “refuse” very deliberately, as it is absolutely a choice to remain silent, giving all your power to someone else. True, this is part of the epidemic of fear and compliance raging through the corporate world, but even in such a climate a cure is available, and we can seek to heal.

The Scrum Sacrifice

My upcoming talk at Scrum Day San Diego

Scrum is a paradigm-shifting ideology. Trouble is, most leaders and managers don’t want to be shifted. They’d rather have their existing beliefs endorsed, and so they look to Scrum as a methodology to put a better face on existing ways of working. They look to Scrum consultants the same way they may look to beauticians or plastic surgeons.

The tragedy is that so many of us comply. We sacrifice the principles of Scrum in favor of “by the book” process. We compromise our values to satisfy the customer (or our manager). It’s easy to see the error when the implementation fails, harder when there is some measurable success. The latter case is the more destructive. Failure leads to rethinking. Success leads to more of the same, thus compromised Scrum becomes the norm: “it’s better than it was”.

What do we gain by this compromise, and what do we lose? This talk will explore both aspects.

The scrum board: dead on arrival

A few years ago I wrote

The longer I teach and coach scrum, the more I become convinced that the physical workflow board is the heart of scrum. Without the workflow board, a team has no center, no focus, no hub.

More recent experience has shown me that this heart has no beat. Here’s the problem: a scrum expert comes in to work with a team. This well-meaning, and often very caring person helps the team create a physical workflow board to visualize the work in progress. Good start. Then the team starts to use the board, and—no surprise—it doesn’t accurately represent the actual workflow of the team. The board, with all the best intentions, is dead on arrival.

Context is everything in software development, and attempting to force-fit a team’s way of working into a tool designed by someone outside the team creates blocked arteries, a disconnect with the life-force and a lot of pain. Ultimately the team experience a kind of living death.

Why does this happen? It is an unexpected consequence of the well-intentioned help. The team see the scrum expert as, well, an expert. This person must know what they are doing, so we should use the board as designed. I’ve visited many scrum teams using physical workflow boards with columns and rows that mean absolutely nothing to the team. They struggle to have the board make sense in their context. It doesn’t. It is ultimately abandoned, or perhaps even worse, kept in it’s half-life state by a dedicated scrum master, tasked with “ensuring the integrity of the process”.

A workflow board—like a heart—must be a living, emerging entity, adapting to circumstance. The board, like the work process itself, is a quest, it is not a state. Quest will take us on a journey. State will halt us in stagnation.

Learn about different ways to visually map your work. Read, explore, listen to experts, certainly, and then throw away all the advise and begin with a new mind to create something meaningful to your own team, your own context. Frequently question the value of this artifact, and frequently seek improvements.

Only then will you create a beating heart; the blood will flow, coagulation will be minimized; you’ll have freedom to breathe, and energy to dance.

Scrum: a 5-step guide for managers

[Originally published on ThePeoplesForum 7/31/13]

Scrum is really very simple. Here’s a 5-step guide for managers and executives for starting a new Scrum process.

  1. Start with a clear product vision—and a visionary guide (PO).
  2. Establish a co-located, cross functional team whose members between them have all the skills necessary to build the product. [1]
  3. Create a space for the team to work in, with plenty of wall space, whiteboards, index cards, tape and sticky notes. 
  4. Introduce the team to their stakeholders and users.
  5. Get out of the way.

Even without any Scrum training, you’ll find that your team is 75% of the way to having a highly effective process. The continuous improvement part will emerge, because people working in an autonomous way, with clear purpose, want to be the best they can be.

Starting Scrum is really is as simple as this. Why do we make it so complicated. Why is each of these steps so hard—especially step 5? 

[1] Start with the smallest possible team. Let the team determine who/what skills they need to add as they progress

Original comments can be seen here

See also Scrum: the necessary conditions

Scrum: The Necessary Conditions

[Originally published on ThePeoplesForum 8/5/13]

The previous post Scrum: a 5-step guide for managers was (quite rightly) criticized for not describing Scrum. It was never intended to. In the text I describe the five steps as being for “managers and executives for starting a new Scrum process”. The title was intended to challenge, to have people ask, so what is Scrum?

Scrum, clearly, is the thing defined in The Scrum Guide, a lightweight document, laying out the process, roles and artifacts of Scrum, and describing the value it offers. It is—happily—very low on prescription, beyond prescribing the basic Scrum framework. There is little in there to take issue with, and actually little that has changed from original Scrum. The problem is, with this and most of the books on the subject, sparse attention is paid to the environment in which we try to implement Scrum. To me this is key to success.

I recently witnessed a team implement at least the first four of the five steps I recommend. They were not “doing Scrum” and yet were closer to the values we seek with Scrum than many teams I have witnessed struggling to make the process meaningful with members in different locations, no clear product vision, team members working on different projects, being driven (and driven crazy!) by the electronic tracking tool of (someone else’s) choice, with all its rules and limitations. Scrum can sometimes create more pain that it relieves.

Teams that are not supported—environmentally, humanely, systemically—to do Scrum, will do Scrum very poorly. Teams that are so supported may not actually end up doing Scrum at all, but will likely have better results. This is my experience from the past nine years.

So my “5 steps” are intended to have managers and executives understand the necessary conditions for inspiring an effective, engaging process, whether that’s Scrum or something else. With such conditions met, I would usually recommend something that looks very much like Scrum, with perhaps a more continuous flow model á la Kanban. As always, context will determine the detail.

And if anyone doubts my own definition of Scrum, or feels it is out of line with The Scrum Guide. Please read Simple Scrum, an essay written in 2009, which still accurately reflects my understanding of Scrum.

Original comments can be seen here

World, I am not a project manager

I’m invariably surprised how often I get contacted by project management organizations, who want to guest post on my blog, or engage me in some other way to help promote their tools and techniques. Even after twenty years of Scrum in our industry, where the project manager role is noticeably missing, there is somehow a perception that a scrum master and a project manager are the same role. Or that there is still a place for project managers in an agile process. There isn’t. Here, verbatim, is a recent exchange with a tool vendor. Names have been changed to protect the misguided:

Read More

A Community Library

I haven’t written much on this blog recently. In those rare spare hours between my full-time job, working on my second book, contributing to my local community, building a studio extension to our tiny house, and raising our wonderful baby (now nine months old) I’ve been building AgileLib.Net as a community platform for sharing agile resources with your fellow travelers.

Read More

My (somewhat) interactive “Thought Citizen” keynote given at AgileEE, Kiev, Oct 2013. There are some three minute silences where conference participants are engaging in dialog. Unfortunately, we can’t hear what they say. You could skip over those bits, or use the time to ponder the questions for yourselves :)