Non-Linearity & The Thinking Knee: More On Fundamentals Of Agility

so we talked about non-linearity here, wrapping it into the context of explaining why we prefer continuous integration (CI). but non-linearity isn’t just a good rationale for CI, it’s actually a driving factor for several of the practices of agility. it’s worth it to take a little more time to look hard.

we’ve said that some problems are linear and some non-linear. non-linear problems don’t just get bigger when you add more pieces, they get “bigger-er”. why?

one thing that causes non-linearity we’ve already touched on: if you have to relate the newest piece to all of the older pieces to solve the problem, *whoosh*, we’re in non-linear land for sure.

in the first example, a new card had to be compared to each old card to answer the question “is this one greater than all the others?”.but, as my more astute — not to say less attractive in any way — readers pointed out, you might solve that particular problem in another way. what if you just always remember the biggest card you’ve seen so far? then compare the new card to that, and you’ll know the answer.

that move, of tweaking the algorithm, the formal recipe we use for solving the problem, is one we use every day. in this case, the problem goes from being non-linear to perfectly linear with just that one trick.the non-linearity there was all embedded in the algorithm, and a clever person could eliminate all of it just by changing that algorithm.

(if you think that’s just the bee’s knees, you should prolly a) learn to geek for a living and b) stop using expressions from America’s 30’s and 40’s, you hep-cat.)

in that case we beat non-linearity by changing the process. can we always do that? wellllllllllll. that’s a very tricky question. the official current formal answer ranges from “no” to “not yet”. people invent new algorithms every day for doing this outwitting of non-linearity. some problems, tho, have had generations of fine minds looking for alternatives, and the consensus on them is “there’s no faster way”.

sometimes, the fix isn’t in the algorithm per se, the process we use to solve the problem, it’s in the performance of the processor. if it’s a computer solving the problem, well, computers have gotten twice as fast about every 18 months for, what, 3 decades, 4? look up moore’s law. there, the non-linearity doesn’t go away, it’s just that the cost-per-action goes down. the *number* of actions stills goes up “bigger-er” than the number of pieces, but because actions go faster, it feels like we’ve mitigated our problem.

sometimes, non-linearity isn’t very smooth. that is, the problem is linear up to a certain number of pieces, then it goes violently non-linear after that. imagine a problem that costs 1 action for 1 piece, 10 actions for 7 pieces, and a 1000 actions for 11 pieces. (do such problems exist? oh, hell yeah.) these problems are linear or mildly non-linear for a while, then they take a sharp turn. they have a “knee” or an “elbow” at some point.

sometimes, that knee is so sharp that, for all practical purposes, when we push the problem beyond a certain number of pieces, it becomes NOT SOLVABLE.

and now, finally, we march out of the abstract math land into direct human territory. because problems whose solution depends on the performance of human bodies nearly *always* have this property.

there are limits to nearly anything you can see a body do, but in this case, i want to hone in on one particular limit, and that is the limit of how many pieces a human can think about at one time.

the metaphor i go for here is the juggling metaphor: how many independent pieces can a human juggle at one time? the answer is fuzzy. if the pieces are truly unrelated, that number is under 10, well under 10. (if the human finds it easy to relate the pieces in question, it can go up a little. if the human finds it harder to relate the pieces in question, it can go way down.)

when we talked about CI, we said that merging say 100 pieces of code into a codebase is way more than a 100 times harder than merging 1 piece. why? it’s the human.

think about it. the *computer* can actually do those merges in nearly linear time. but the computer doesn’t have to understand those changes. it just has to make them. the human has to grasp them. the computer doesn’t know or care if the new build breaks the north american power grid, or drops planes out of the sky, or prevents us from tweeting long muses, or hard-formats the drive of everyone who runs it. the human cares very much, and *has* to know.

human thinking is non-linear AND it has a very sharp knee at a very low number of pieces. and that insight lies at the heart of a great many of the techniques agilists advocate.

when we push for CI, we are trying to keep piece-counts small to reduce the non-linear effects, and so small that we are “inside” the thinking knee. and it’s not just CI. there are several other practices that adhere to this pattern. let’s name three of them at random.

TDD writes small tests interactively as we write the code. we are keeping piece counts small.

story-shaped development — iterative and incremental — wants stories we expect to take less than a day or two to implement. stories that small help us keep the piece counts low.

the emphasis in merciless refactoring on killing off duplication? hmmmm. makes fewer pieces, doesn’t it?

and our reaction to the thinking-knee isn’t just limited to reducing piece count in gross obvious ways. there are other practices that attack the knee by introducing a variety of other techniques. (i’ll take a look at a couple of these in a muse coming soon to a twitter near you.)

for now, it’s enough that you grasp the significance of both non-linearity and the idea of knees in the non-linear curve.

with the thinking-knee under your belt, you’ll see piece-counts all around you, and you’ll be sensitized to the variety of ways we seek to reduce them. you’ll be, in short, ready for the crazy non-intuitive practices agilists have been struggling towards for the last 20 years.

Some Problem-Patterns I Look For

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’s 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.

Linearity & Non-Linearity & CI

when we talk about software methods, very early on we come to a place where we simply have to develop a comfortable grasp of non-linear effects.

so many conversations founder here, where the relationship between two values becomes something other than a more or less straight line on a piece of graph paper. we spend a lot of time talking about the cluster of concepts we normally shorthand as “complexity”. that’s a good enterprise, i think, but i also think it’s a few chapters ahead of where our decision-makers are. it doesn’t take chaotic dynamics to understand why continuous integration (CI) is so important, for instance.

we all come very early on to underrstand that more pieces means more work. that concept needs no introduction. for the overwhelming majority of problems, “more pieces” = “more actions”, trivial knowledge every infant knows.

the interesting point isn’t really that pieces and actions are related. they are nearly always correlated: when the pieces go up, the actions go up. the interest comes when we ask, “how *much* does the count of actions go up when the count of pieces goes up?”

and here we meet a whole bunch of mathy words: “linear” vs “non-linear”. “arithmetic” v. “geometric” v. “exponential” progression. “asymptotic”, and so on. these are all words that sketch different answers to that question for different problems.

(aside: obviously, i’m comfy with math, and so is much of my downstream, and we all know this shit. i’m reviewing at such a starter level cuz many of the people we work with *aren’t* comfy there, and i am seeking easy ways in to it.)

some problems look like this: “no matter how many pieces you have, if you add one more piece, it will cost you one more action to finish the larger problem.” if you start with 1 piece, it takes 1 action. 10 pieces, 10 actions. 100 pieces, 100 actions. the usual example is moving bricks. it takes 1 action to move 1 brick, so it takes 10 actions to move 10 bricks, and so on. this is called “linear” btw, because the simplest abstract picture of it, a graph where pieces are on the vertical and actions are on the horizontal, makes a straight line.

there are lots and lots of problems that are like this, so it’s perfectly natural to wonder if all problems are. the answer is no.

in linear problems, one extra piece means one extra action, regardless of the total number of pieces. but there are a lot of problems where the action-cost of adding a piece is *different* depending on how many pieces are already in the problem. what kind of problems are these “non-linear” ones? well, any problem where adding one more piece means relating it somehow to some or all of the other pieces.

here’s a problem: i will give you some playing cards. each card i give you, tell me if it’s bigger or smaller than all the others you have. if you have a 3 and i give you an 8, say “yes”. if i give you a 2 say “no”.

how hard is this, how many actions does it take? ahhhhhh, well. that depends on how many cards you start with. you have to compare the new card with every card you already have before you can answer. the more cards you already have, the more comparisons you’ll have to make, the more actions it costs. so the cost for adding a card doesn’t go up a fixed amount every time. (if you draw this one, you get a curve instead of a straight line.)

it’s no coincidence that this problem involves comparison. one of the earliest lesson-sets young geeks have to master is exactly this kind of sorting task. we have to learn a bunch of clever ways to arrange and compare the cards as they get given to us, to reduce the actions.

in a linear problem, add one piece and the problem gets “bigger”. in a non-linear problem, add one piece and the problem gets, well “bigger-er”. the more pieces there are, the higher the number of actions required to add just one more piece.

(geek-grin: there are even problems where the action-cost goes up so fast per additional piece that for even relatively small numbers of pieces they become NOT DOABLE IN THE TIME REMAINING BEFORE THE SUN BURNS OUT. how cool is *that*?)

alright let’s bring this vague crap back to continuous integration (CI).

integrating code, merging two versions of a codebase, can be done once a month, a week, a day, or an hour. generally, in CI we push to make the elapsed time between merges as small as possible, in some shops we’re talking tens of minutes. why?

the longer the elapsed time, the more differences there are between the two codebases. differences are the pieces here.

naturally, the more pieces the bigger the cost of merging them. BUT, it’s worse than that. it turns out that merging pieces is a non-linear problem.with each additional piece, the cost doesn’t just get bigger, it actually gets bigger-er. i don’t have a formula, but we have ample evidence that 100 pieces is much harder than just 100 times 1 piece.

we practice CI because of this non-linearity. 8 merges, each of one hour’s worth of changes, takes less action than 1 merge of eight hour’s worth of changes. now that’s some cool-assed theory, yeah? if you hung in this far, you now have a grasp of *why* CI is a cornerstone of the modern synthesis. but that’s not why i started this monstrous thread.

do you know who totally got why CI would work before they actually tried it? just about no one. oh, a few did, a few do, don’t get me wrong. but the great unwashed mass of geeks, including me, never got it until we did it. this is especially remarkable given that the sonnet turns at non-linear effects, a subject nearly all geeks have spent substantial time studying and experimenting around.

there might be a lot of morals to this story. normally, i enumerate several of them myself. but ya know what? it’s the day after christmas, i’m out of smokes, and it was a long rambling muse, so i’ll leave it to u. pick from it any lurking lessons there. if u feel so moved, tweet them to the thread so we can all savor them. thanks for following along!

Sprints vs Pure Pull: GeePaw Takes A Stand

so, there’s a lot going around just now about iterations vs pure pull. i feel like i want to weigh in on this one.

i should say at the outset, as a coach the presence or absence of iteration/sprint is not a major outrage for me one way or the other. i routinely encounter sprint-based methods. somewhat less frequently do i see attempts at pull, tho at industrial logic we’ve used pure pull for our product development for many years.

some ask the question, what do you *get* for pure pull? this feels a bit presumptive, as if sprints have proven their own cost-benefit ratio to be in our favor.

my experience is contrary. that is, i have not found sprints to give me very much at all, and i have not found them to be cheap. inevitably, to get at this, i’m afraid we have to be prepared to wrestle with the distinction between theory & practice.

when sprints were proposed, they brought with them several hopeful aspects.

  1. they aimed at providing simple rhythm, a regular time & place for us to pause, look around, and decide what to do next.
  2. they intended to shorten planning cycles, a tremendous benefit in a trade that is obsessed with making useless and unresponsive long-term plans.
  3. they provided a convenient place to hang retrospectives, a potentially critical technique for continuous improvement.
  4. they provided a rhythmic data pulse up and out of the team so that large orgs could monitor/manage production.

so. did they do all this? i am certain they did, here and there. and yet, and yet…

the situation in the trade has changed quite a bit and also not at all since then. and as a direct result i am far less positive about the need for sprints than i once was.

first, the rise of CI/CD have made it clear that even smaller cycles are possible and desirable. sprints are smaller than what came before, but they’re still bigger than what they could be.

second, we have been singularly unsuccessful, even with sprints, in reducing the planning cycles of large orgs. sprints are regarded in the majority of cases as nothing more than simple addable work-units bound to far larger plans — on the order of quarters or even years.

third, tho sprints provided us with a place for retros, now that we now we like retros, we can give them their own place without sprints at all.

fourth, sprints lend themselves readily to — what to call it — a “bookkeeping” approach to management. people say they hate jira. but they don’t. jira works fine. what they hate is the expense & stress of the horrific management-by-jira that is so readily supported by the sprint+velocity concept.

fifth, sprints aren’t free. i commonly encounter 20% end-of-sprint ceremony costs. not universally, and not in theory, but commonly and in practice. *20%*. one day in five, two days in ten.

and sixth, sprints are used nearly everywhere i go as lockstep sync points, which is exactly what i don’t want anywhere in my org if i can avoid it.

on balance, then, i prefer to de-emphasize and even eliminate sprints altogether wherever i can. they are not inherently-in-theory a bad thing, but they seem commonly-in-practice a net negative. i reiterate though: i never walk into a shop and say, “wow, the biggest problem i can see is these damned sprints, we must all immediately toss our sabots into the sprint gears and destroy them!”

what would i do instead, in the rather unlikely event that i finally ascend to my rightful role as king-of-all-the-world?

daily 10-minute high-discipline standups. a physical board showing all and only WIP and blocked WIP. product decision-makers living w/geeks. backlogs maintained away from geeks. half-hour retros every week. no stories >2 days in length.

so i guess i’m a pull guy. i understand the theory of sprints. i have seen them help. but i believe the theory-practice divide means they don’t help enough or cheaply enough or often enough.

Not Trying & The Fabric Of Coaching

we’ve got this long (and still probably partial) list of reasons why people don’t try new things.

in recent weeks, i’ve gone pretty far afield around coaching. i picked out four or five threads separately and ran with each, separately. if it seemed a little incoherent to you, well, you know, join the club. analyzing individual threads isn’t necessarily the best way to analyze a fabric. i confess to feeling a little bewildered as i *wrote* it. i get you might feel that way reading it.

that list of reasons, tho, is the result of me struggling to understand how several different themes, the ones i constantly harp on, are in fact deeply interwoven. i’d like to mention each of the themes and mention in a line or two how it all connects.

i offered at one point “a list of gerunds”, describing (always partial) the list of activities that i use when i’m coaching day to day. they connect to the list of reasons in two ways.

  • first, they are quite varied exactly because the list of reasons for not trying are so varied.
  • second, they are all activities with the focus of opening up the trying. i do those things because those things have led me many times to places where people who were not trying a new thing became people who were.

those moments where the change happens? those are related to my stumbling efforts to get at “finding yes”.  answers, it turns out, are relatively easy. trying new things, any new things, are relatively hard. that theme of “finding yes” is about focusing on the hard part.

third, and by far the most coherent of any of these, is the conversation around always-small-always-improve. the ASAI expression has two terms, and it connects on both of them to that list of reasons.

always small because it’s easier to try things that are small than to try things that are big. small often (not always) correlates well with easy, and easy-to-try is big plus in the try-selling business. always improve because s great many of those reasons have to do with proof, and some have to do with faith.

proof happens after the trial. if trying something new doesn’t actually improve things, why should we do it? faith happens before the trial. if prior tries have improved things, one’s sense of faith that trying new things is good goes up quite a bit.

my broad mistrust for branded methods isn’t associated with any given post, but is visible by the absence of advocacy for one or another, and a certain mean-spirited tone in my occasional pot-shots at method-warriors. the methods seem, far from easing opening the world up to trying new things, to contribute in a variety of ways to actually trigger some of those most common reasons from the reason list.

they are almost uniformly “cities on a hill”, large palaces made of words, located far away from here, and often sourced far above here, both factors that trigger some of those reasons. they rarely if ever provide a transition route. they are vested in having all and only their own parts present. they often fail altogether if any one element is still done “the old way”. they seem also to lend themselves to misunderstanding, another factor in some of those reasons not to try the new thing. and of course, they guarantee flavor-wars, gross generalizations, and reasoning around abstractions that are 5 and 10 hierarchichal levels beyond the concrete.

so there we are. that list of reasons underlies, overlies, intertwingles, with the whole fabric of coaching as i grasp it.

there are other threads to pursue, and i’ll probably get there. (already formulating a muse on “sociotechnicality” and why it’s such an important concept.) but to be honest, i want to do some more traditionally geek stuff for a while. i need geekery like i need music, to thrive.

thanks all for the various inputs, and for hanging in so long to read all these damned things. feel free to poke & prod, comment, question, critique.

Why They Don’t: Reasons People Won’t Try Something New

yesterday i asked my timeline how they would answer “why don’t people do what my software development method says they should do?”

I am not remotely surprised that the answers i got were almost exclusively thoughtful and sensitive. the people i hang with are just like that. i want to review the answers, but i’m going to do it by re-framing them all in terms of “trying a new thing”. after all, as coaches, we are kinda in that business. no doubt, this will involve some word-twisting, and it may involve some intent-breaking. i trust you to holler if i go too far.

some of the answers seem to focus on “trying”. others are about “new”. a couple are about “now”. <– yes, i realize i forgot to put “now” in “trying a new thing now”. my bad. a couple of people went pretty meta-, and one or two seem to have thot i was asking “for a friend”, and offered advice about what “my friend” should do. 🙂

there are a lot of reasons people don’t try a new thing now.

  1. they don’t know there’s something else to try. that is, they are currently unaware that there is a different way.
  2. they don’t know how to try it. that is, it seems so far from what they do now, they can’t see a way to start doing it at all.
  3. they believe they are trying it. this is what happens when there’s a disconnect between “what i said” and “what you heard”. (it’s not all saying and hearing, so take that as metaphor.)
  4. they believe they tried it, and it didn’t work for them. note: they might have tried it and it didn’t work, or this could be the result of the previous item.
  5. they believe it won’t work, so is not worth trying. this is especially common when the new thing does not seem intuitively correct. like turning into a skid, say.
  6. they can’t try it *now*, because they are mid-stream doing an old thing and they feel pressure to complete.
  7. they believe they can’t afford to try because local failure will lead immediately to global failure.
  8. they believe they can’t afford to try because local failure — regardless of global impact — will be punished.
  9. they don’t want to try my idea because they don’t like me. (rarely mentioned, but be real: not liking the suggestor is a common reason to not try the suggestion.)
  10. they don’t want to try my idea because they’ve experienced many failed ideas from me. note, this is different from 9. here they have or believe they have a trend of real experience with you.
  11. they don’t want to try the new idea because it comes from above. this is the feeling that autonomy is being violated.
  12. they don’t want to try because the new thing seems incompatible with what their peers are doing.
  13. they did try it and it isn’t working well because it’s new. it’s hard to do things a new way, and hard to tell when you’re still climbing the learning curve vs when you’re just doing a thing that doesn’t work well.
  14. they did try it and it doesn’t work well. i know, this crushes our spirit as coaches, but it happens all the time. our methods just aren’t that reliable.
  15. they can’t try it because it requires a technical pre-requisite. (it is very hard to do CI/CD w/o a certain degree of automated test coverage, for instance.)
  16. they hate new things. the act of change itself — any change — is experienced as unpleasant.
  17. they feel they can’t try anything because life is busy macerating them. again, rarely mentioned, but it’s routine to encounter people who are wrestling with challenges in their lives that far outweigh anything happening in their work life.

oooooookay. damn. that’s a lot of answer, eh?

yesterday’s abortive chiropractor appointment is today, and i need to take a break and go get snap-crackle-popped. further, this is a good pausing point.but i’m not done. i asked that question not knowing for sure what i’d get back. and i started this list not knowing what the point of it was.

but the point developed as i worked on the list and thought about the answers. when i return, i want to knit together some things. 1) always-small-always-improve. 2) the gerund list. 3) my oft-stated distaste for software development methods. 4) finding yes.

until then, have at it. remember to take deep breaths and chuckle at yourself.

Coaching, Facilitating, & Training: Differences & Similarities

a respondent asks about the differences between coaching, training, and facilitation.

my answer depends on just how narrowly i treat these things. with a narrow view, they are all quite different. with a wider view, they have many similarities in activity, outcome, and intent.

at its narrowest, training speaks to me of formal settings & structure. a person (or usually badly, a machine) is the instructor, and some other persons are the students.

conceived narrowly, facilitation is a session of active disinterested leadership. the one person isn’t the trainer, but the “meeting runner”. she’s responsible for setting structure & tone of a given meeting or set of them, to ensure some kind of optimal experience. in both of those modes, the others grant, in advance, considerable control to the one. we limit that control in the former case to the subject domain, and in the latter case to the management of the meeting(s).  the one is “in charge” of the others by intent and de jure.

trainers are not “in the game”, and their activity isn’t performed in the game, either. a facilitator’s activity is very much in the game, but the facilitator herself is usually explicitly not vested in any particular outcome.

narrowly, a coach is limited not so much by subject domain — she can go wherever she wants — nor by disinterest — she can and does want particular outcomes, but by range of control. coaches are not in charge, at least not de jure. they are more vested in outcome than facilitators, but they are not themselves usually in the game. (the analog to coaching sports, which i presume is the origin of the term in the geek trades, breaks down here. sports coaches *are* in charge and *are* deeply vested.) interestingly, coaches aren’t in the game, but most of their activity takes place while the game is going on around them. odd.

so there are differences there when we’re feeling narrow-focused. they have to do mostly with how control is handled and partly to do with when the activities take place and partly with special role’s vesting in outcome. of course, as soon as we open the aperture, all this pilpul turns into the kind of nonsensical neo-platonist bs we tell ourselves to justify whatever recent act needs it.

the most successful trainers, facilitators, and coaches all intermix these modes more or less freely to achieve their ends.

i not only often begin coaching gigs with a few days of training, i also hold tiny training segments all through the engagement, and i am regularly called upon to facilitate meetings. trainers love it when they get the chance to create materials right out of the client’s code. facilitators often start sessions with exercises designed to train their attendees.

i suppose, in the wider view, these differences are actually more about how the consumer views the producer than they are about how the producer views herself.

if you are a pro, someone pays you. that someone brings to the table many expectations. it is not necessary to fulfill them all, it is necessary to please those someones. very often, nearly always, the first challenge i face in a new gig is precisely to shape those expectations so that both sides of the arrangement walk away happy. i’d have to be a pathological liar beyond even my current level to suggest that i always succeed at this. 🙂

but it’s a routine part of every gun-for-hire’s job, not just mine or ours. plumbers, doctors, congressfolk, actors, authors, all start every engagement by framing it. coaching, training, facilitating aren’t any different.

seen narrowly, almost any human activity can be dissected this way. seen broadly, almost every human activity is a vast flickery assemblage of skill and attitude and local context. coaching, training, & facilitating are different and alike. 🙂

thanks, @dhommel, for the nice trigger. always good to have someone stir the soup on a lazy sunday afternoon.

Coaching As Improv: More On Saying Yes

Okay, coaches, where were we? Oh yeah, I remember. I had a long list of gerunds, then a long (weak) chat about “yes”. Let’s take another swing today.

I grew up on stage. I started acting in community theatre at age 6, and I became instantly fervently addicted. I wanted to very much to be an actor, and I studied it as I study everything, pretty much ‘all in’. Among many other fascinating enterprises, I studied and practiced improv. In this form of theatre, a couple-three of us are given a situation, and we aim to collaborate together, without script, to act out a scene without setting.

In improv, the key skill is opportunistically forwarding the scenario in direct response to the lines and actions of the other other players. One actor makes a move — a line, an action, something — and the other players add to that move their own moves, with the goal being nothing more than carrying along the scenario wherever it goes. At any given time, an actor is called on to take all that is going on and finding a way to take another step. There are patterns to this, but lots of twists and turns and exceptions. If you’ve never taken an improv class, I highly recommend the experience.

In modern improv theory, we say that each individual actor is “saying yes”. This shorthand term is how we say that the purpose of each new action is just to extend, enhance, elaborate, elucidate, elevate the flow of action that has preceded it. It’s a very odd thing, improv. In some ways, it seems and feels quite hard. In other ways, it’s almost ridiculously easy.

It’s hard because no one is in charge, no single vision guides the action. All improv scenes are in a permanent state of uncertainty. If you’re a control freak — I am — this takes quite some getting used to.

It’s easy, tho, too, because saying “yes” isn’t a singular thing. There are always lots of ways to do it. An individual actor is presented with a shifting array of choices. Because we don’t have that single vision, the emerging performance is made of all of our visions, and all of the choices we take. This means that any given singular choice is (relatively) low-weight. Think of the scene as “distributed” across each line from each actor. No one line is the most important line. No choice is the critical choice that must be correct. It’s quite liberating, this relative per-decision unimportance.

Now, I don’t mean to suggest that all improv troupes or sessions are equally successful. Some seem plain. Some go quite south. Some rocket beyond our wildest expectations. There are a lot of factors involved. There is the emerging unity of vision. Tho we start with only the slightest sketch of a scene, the best troupes feel each others’ direction out quickly, and soon we’re headed in a direction we all broadly agree to. (“Broadly” is important here.)

Part of that emerging unity is simple trust. The kind of pro improv troupes you’re used to seeing have often worked together for quite a while, and besides which, they all believe in the process. That helps a lot.

There are also themes and archetypes. These are the patterns, of plot and character respectively, that experienced improv’ers rely on as invention engines.

And of course, a key factor is the capabilities and taste of the individual actors. Skill counts, here as in all human endeavors. The most skilled comedy improv folks are simply stunning.

To coaching, then.

Do you begin to see how coaching works for me? I see myself as being in an improv troupe. I seek to be the best improv artist I know how to be. I seek to say yes to the lines of the other actors in the scene, to find all the small ways by which to forward the scenario. If this analogy is to work, we have to say some words about the scenario. In improv, that scenario is a lightweight sketch of a few sentences. It is the lightest of targets. In fact, sometimes an amazing thing happens: an improv session will take a scenario like this and completely break out of it, spiraling into something far outside the basic sketch.

But if you’re a growing coach, well, oh my. Your head is most likely full of a very large and very detailed scenario, your prescription for excellent software development. (for the purposes of this discussion, it doesn’t really matter what decal you paste on your flavor of software development method. In this, they’re pretty much all alike.) The “scenario-in-the-head” is in more or less continuous tension with the ‘scenario-unfolding”. And how we navigate that tension defines us as coaches.

The recurring question: is it more important to adhere to the scenario in the head — the method, framework, endpoint — or is it more important to take that scenario as a launchpad and build and support the fluent unfolding of the improv scene? The good news is you don’t have to answer it just once. That’s also the bad news. It has to come up over and over again, and that’s exactly right. And the broad trend of your various answers is a critical part of defining how you fare as a coach.

By now I’m sure you know where my own answers trend. I favor the fluent unfolding of possibility over the stricture of adherence to method. I do this for reasons that are practical, theoretical, philosophical, and above all firmly based in my 20 year experience of doing all this.

Practical: This works better in the sense of creating more on-the-ground happiness from others with my work.

Theoretical: Our methods just aren’t that reliable, that I should be insisting everyone around me adhere to them. I simply don’t know enough or strongly enough to force adherence to a scenario I’ve sketched.

Philosophical: I’ve never met a formal scenario structure for any mildly rich sociotechnical domain that I haven’t also seen utilized to cause untold harm to its practitioners and their neighbors. I have come to believe they are impossible.

Wrapping up: The long list of gerunds is about the many different behaviors I use to say yes — to create and foster improvised opportunistic “better” with the troupes of geeks I work with for a living. If this is all too foreign, here’s a couple of homework assignments. Watch a couple of episodes of “whose line is it anyway?”, US or UK either one. Read a book on improv. Watch an episode of critical role from geek and sundry. Listen to Dixieland.

You could also go to your favorite restaurant with your three most trusted friends and watch the conversation unfold. Or you could watch virtually any pro team sport with a camera above the action.

A Brief Rant On Forcing People

I heard from a coach yesterday, of another coach in a room full of coaches, suggesting that they fire a couple of geeks to wake the rest of the team up to following instructions. (I wasn’t there. It’s possible that this didn’t quite happen, possible it was a joke, possible it was a very junior person, and so on.) This, coupled with yesterday’s brief interaction around the word “imposition” w.r.t. scrum vs. a generalized stance towards embracing change, lead me to a crabby place today.

“Pour encourager les autres”, “imposition”, and if you check your nearby agile stream, you’ll see plenty of variants of these ideas, this is just not the stuff of coaching, or for that matter of agility.

I would go further. I would say that forcing others to your will is exactly the anti-coaching, and more broadly the anti-agility. There are a huge variety of excuses, a whole civilization full, that you can use to justify command and control. I won’t enumerate, as parts of my downstream will surely help with that later. I’ll just ask the question I think of as the Beck question: How’s that working out for you?”

I’m not gonna take this any further for now. I’m too sputtery-annoyed.

Do I ever fire? I have, and I will again. Do I ever order? I have, and I will again. When you see me do these things, folks, you are watching me lose. You are seeing a coach give up.

For those who wish to coach and learn coaching, I’ll leave you with a mission this morning. As you go about your business today, watch for the various applications of force in your workplace.

Consider, as you do…

  1. What consequences arise?
  2. What alternatives are present?


Coaching is X-ing: Things I Do When I Coach

i’ve got more to say about interactions between humans at that level just above behavior and just below openings, lots more. but i’m going to jump ahead, then circle back.

i want to list a bunch of things i do during my coaching days. it’s likely only a partial list, and as always, i reserve the right to change my mind pretty much at will. this list is made of gerunds. gerunds are verbs turned into nouns for grammatical ease. that choice is willful. coaching (a gerund) is active, not passive.

there are a lot of them. that represents the fact that there are a lot of different kinds of work i do when i’m coaching. i mentioned yesterday, and reiterate today: none of these things i do *to*. they are things i do *with*. words around this distinction are not easy and obvious. i will do my best, and i ask you to give the benefit of the doubt if my terminology can be interpreted both ways.

one more thing: some of these words are unusual in this context. again, not an accident: tho they name actions that in some cases have other common labels, i prefer a slight sense of jarring. okay, blah-blah-blah, no further ado.

these are things i am likely to be doing on a day when i’m coaching.

  • narrating — the stories we tell ourselves about our experiences dramatically affect those experiences, and narrating is about shaping those tellings.
  • canalizing — sometimes content, emotional, intellectual, spiritual, needs channels into which it can flow. canalizing is creating, often just being, one of those channels.
  • moderating — formal gatherings of peers often benefit from disinterested leadership, aka facilitation.
  • water-winging — trying a new thing you don’t know how to do can be hard, and i often hang out with someone doing that, calming them and keeping them afloat while they start to swim.
  • view-merging — closely related but not identical to narrating, this is the work of taking two seemingly disparate views and reframing them as unified.
  • fish-eyeing — it is ridiculously easy to fall in to the trap of attending to faraway things while ignoring nearby ones. fish-eyeing is about keeping the next thing at maximum magnification in our vision.
  • joking — yeah. just plain old making laughter.
  • peering — being a proper legitimate peer, neither above, nor below, nor outside, but fully in, just another one of the folks being in the team.
  • scouting — our work very often needs people who are a couple of chapters in front of us technically. when i’m scouting i’m geeking ahead a little. (a little.)
  • backfilling — when we discover a technical thing that works, we’re often so excited to keep moving that we don’t tend to all the old stuff, catching it up to our new conception. doing so is backfilling.
  • celebrating — things sometimes work, and when they do, we gain strength by noticing that. enjoying small victories with the right intensity is a critical coaching activity.
  • grasping — a very great deal goes on in and near a team, above and below the surface. i invest huge resources in sensing this activity and guessing its meaning.
  • jarring — sometimes, in order to re-center, it helps to be moved to take a shocking or surprising idea seriously. jarring is the expression of such ideas.
  • ignoring — there are numerous snarky words for one who rises to every bait. i frequently choose to ignore — for the moment — issues i’m not ready to engage on.
  • failing — i take great pains to reveal the times and places where i’ve fucked up, because being wrong is an ordinary and fundamental part of being great.
  • resting — i not only rest to conserve energy for times when i can’t rest, i also do it to look away from a problem and let my background processes work on it.
  • truthing — i tell the truth by and large. i believe nearly everything i say. i don’t say nearly everything i believe.
  • hand-sitting — when my team makes a decision i don’t agree with but can live with, i sit on my hands. it’s very often more important that they decide and act than that they be making the “right” decision.
  • pronouncing — sometimes i am genuinely asked to pronounce on some topic as an expert. and sometimes i do.
  • complaining — when a thing is within my or our local grasp to change, and i don’t like how it is now, no one around me remains unaware of that. a team of mine called it the CBM — the continuous bitching method.
  • debriefing — nearly every day i spend 30-90 minutes reviewing that day. i talk it over, with my brilliant and sensitive and highly skilled wife, or my beloved ex-, or my colleagues, or my close friends in the trade, or my notebook.

wow. that’s a long list, and i’ve little confidence i hit the most important things!

i don’t do all of these things all of the time, but i do them all a lot, and i regard them as an ordinary part of my work. they are flickery. i jump back and forth between them. i don’t for the most part schedule them. rare indeed is the day i do just one or two of them all day.

from here, i will later circle back. these words capture some of the kinds of interaction i do during coaching days, but i want to connect it all back to that mission we discussed, creating openings. soon, soon.

narrating, canalizing, moderating, water-winging, view-merging, fish-eyeing, joking, scouting, backfilling, celebrating, grasping, jarring, ignoring, failing, truthing, hand-sitting, resting, pronouncing, complaining, debriefing.

for me, this is all coaching.