I remarked en passant the other day that I never see places where the biggest problem was sprints. Someone asked me what I do often see as the biggest problem when I walk in to a new shop? This gave me a lot of thinks. There are certainly things one sees over and over again. But most of these are small.
On the other hand, there are a small number of, idunno, problem patterns, that seem much more ever-present. It’s not so much the details here as the level of abstraction one level or two above them. Anyway, I think the real question is actually more about the coaching than about the shops. What do I look for first? After all, the things we look for first ought to correlate for the things we most often see. If we’re any good, that is.
So, a short list, not of problems, but of problem-patterns. Fair warning, this is likely to resemble Borges’ famous chinese encyclopedia.
For any given problem pattern, the underlying issues might vary widely. It could be a policy, or a structure, or a physical or technical setup. It could be just an attitude. It could be the absence of key knowledge, or of certain conversations.
Y’all know I believe in "no one way", right? Well, there’s not just no one way to do well, there’s no one way to not do well. Various are the evils of the world, too various to list, but they do fall into certain effects, and these are what I mean by problem-patterns.
- Problem: we’re afraid to change code we already shipped. This is sometimes policy, sometimes attitude, nearly always backed by a lack of technique that created historical damage leavened with a generous helping of fear-mongering.
- Problem: we’re afraid to say what we don’t like about what we’re doing. This, of course, leads us to not *change* what we’re doing.
- Problem: we substitute team meetings for f^2d^2, frequent focused direct dialog between interested parties.
- Problem: we use a uniform working-together/working-apart policy instead of one that is continuously tuned to tasks & individuals.
- Problem: we use the same zoom for looking months ahead that we do for looking days ahead.
- Problem: we standardize things that don’t benefit us by being standardized. This is endemic to vbca life. (vbca = Very Big Corporation of America).
- Problem: we report out numbers instead of narratives, and they’re usually the wrong numbers.
- Problem: we share key externalized resources like servers and db instances that teams need everyday all the time, and we often restrict their number for alleged cost reasons.
- Problem: we attend more to the *made* than to the *making*. Henry ford didn’t change the world by revolutionizing made cars, he did it by revolutionizing making cars.
- Finally, for now, *problem*: we do not persistently seek to increase the happiness of our own people.
What a strange list! It feels kinda like a list of illnesses, but I notice I haven’t listed any detailed symptoms, any root causes, or any remedies. So what is it?
I spoze it’s the stuff I scout for first. And I spoze it has to be at a fairly vague and high level of abstraction. We could make a checklist of a thousand questions, but i’m not sure it would do us much good. Coaching in sociotechnical situations is always about "feel". Many of the people I work with & for don’t start out even able to tell me what is going on with them, for a variety of reasons. And orgs, it is to laugh: orgs have less access to reality than anyone inside them.
I go on site. I often give a short class. I use the time-honored technique called "hanging around", and I use it to feel my way into my by-now oft-repeated target: help the team fix the nearest team-felt owwie that’s within their reach.