Sooooo, I saw a couple folks arguing earlier about what is or isn’t Agile.
That’s okay. People do that. Analytical people *thrive* on doing that. Anyone who’s gotten to the level of journeyfolk in any arena will seek to define that arena. All very healthy stuff.
Nowadays I tend to avoid these arguments. I have my reasons.
First, there is no definition anywhere on earth of anything that can’t be abused or misused willfully or not. There is no compelling conceptual locus that can be framed in mere words such that we can use those words to decide what’s inside the area and what’s outside of it.
Second, I get bored easily. Remember, these wrangles are nearly 20 years old now. Spend some time at Ward’s Wiki. We discussed extreme everything. Extreme banking, extreme housebuilding, extreme *everything*.
Third, I don’t myself use “Agile”, except in uncomfortable situations.
Two Poles and a Broad Spectrum
There are two poles in most such discussions, with a spectrum between them.
One pole says “agile” means subscribing to the spirit and the letter of the document known as the Agile Manifesto.
One pole says “agile” means whatever the speaker thinks is best.
That second pole includes many folks who believe they have a grip on the spirit but aren’t necessarily even interested in the letter. It has many other folks — I’d say many more — who have solid connections to neither the spirit *nor* the letter.
Some Actual Cases, Bizarre to Me
There are folks who think there’s an agile way to hire lots of crummy geeks, pay them shit, and use control technique to make it work. They want to call this agile.
There are folks who think agile doesn’t require working software frequently released, or testing, or any given one or several of the original pillars.
Yesterday I heard of a team that does agile planning much more quickly by cutting out all the discussion.
There are many people who think agile means hour-long standups and month-long iterations.
I know folks who believe scrummastering is just another word for coaching, and others who think coaching means spreadsheet maintenance for management. Chat about it on twitter for a bit, and you’ll see tweets from people who sell “agile” tracking systems that count hours for management.
Companies like Microsoft claim agile. *HP*, saints preserve us. and many other hulking command and control giants. Hard for me to take.
Not so long ago I spent 5 months obtaining a thirteenth computer for a 12-person team that is the only team in their department that’s shipping successfully, at a Fortune 500 company with a whole agile software delivery department.
I am not imagining this. Unlike a lot of folks, I work with these people for a living. Not just one company or team, but *many*. This list isn’t based in my reading, but in things I’ve observed directly or from one step away. It’s the vantage of being a well-known external coach.
Me and Agility
What I call agility is a mental stance, a kind of philosophy of geekery.
And tho I bitch at the Agile Manifesto a lot, it does in fact do a reasonable job of describing that philosophy.
There are a couple of things to remember about “agile” as a term. It emerged at a time when the folks using it were noting and seeking a unity between some disparate methods. They were also seeking mindshare. In those days we were all hungry for mindshare, because mindshare meant sales and sales meant we could keep doing this cool thing we were doing.
We wanted mindshare. We got it. To get it, we softened our case. We made hard things seem easy. we spread the word. Along the way we muddied things by changing — rightly — our behavior and our prescriptions and proscriptions.
And yes, we invited in and even encouraged hucksters and lightweights.
And if we — I — now regret that, well, hell, I’m reasonably confident it won’t be the last thing i do that I regret.
[…] so that they know just exactly how a thing of beauty is a joy forever and forever and how it never never can quite fade into money-losing nothingness.
That’s Ferlinghetti, speaking of art directors and their relationship to art. (Read the whole poem, as it’s my favorite by him and one of my top half-dozen or so all-time poems. It’s meant to be declaimed, so declaim it.)
What I Do
I help teams find paths to becoming more like the people they wish they were. I call that “coaching”.
I don’t attend much to best. Instead I spend my time focusing on next.
I live with teams, learning what they do and how they do it. And I open them up to possible changes, in technique, in organization, in social behavior, in goals, in ways to think about problems.
I don’t — can’t — make anyone change. I never give orders. I only propose, describe, demonstrate ideas. Over time, teams ask me for ideas, cuz the ones I’ve offered that have been tried have helped.
And I wanna stress, they’ve helped in practice. That is, real problems the team experiences have been mitigated. Problems don’t happen to teams in theory, they happen to them in practice. That means the solutions have to, too.
This is what I know: I know that if you show me a hurting software development team, I can often, by no means always, help them not hurt.
I also know I do that by things that go largely unmentioned in any manifesto, agile or otherwise. I act-then-listen. I experiment. I attend. I am kind and, roughly speaking, cheerful. I got mad geek chops. I am fundamentally a silly person full of odd habits and odder passions.
Am I An Agile Coach?
Is that agility? Am I an agile coach? Are all the changes I propose “agile”?
I don’t care if that’s agility.
I don’t call myself an agile coach if I can avoid it.
The ideas I propose are based on my experience and my philosophy. Both have been influenced by the agile movement. But they’re not mostly “agile”, they’re just good local stepwise answers to bad local stepwise problems.
What does “agile” mean to me? It means “a set of insights that gradually morphed into a nearly empty abstraction”.
Not Hating the Arguers
I get it. I get it why it makes people angry to have the word mean just any damned thing at all.
I get it why some folks want to extend the notion of agility to cover agile-spirited ideas.
I get it why one would argue when I hear some would-be agilist advocating behaviors that don’t seem even conceivably to match the spirit.
I get it even more more more when I see that feeling coming from a manifesto author. Yes, it was a marketing and business decision, but it was also a heartfelt effort to collaborate in sketching a way forward in a very broken world.
Arguing About Agility Doesn’t Help Much
I Focus On Helping Much
 That’s not just an intellectual stance for me, but a daily one: I really don’t have the experience that truth fits in language, so I don’t spend a lot of time trying to make it do so.
 I’m not talking about a super-computer here. I’m talking about a computer that would have cost less than one day of my billing to get. And yes, Virginia, I did offer to take the day off and show up the next day with a new box. I always do. They always decline.
A remarkable amount of geekery-advice comes in the form of rules & slogans accompanied by appealing. intuitively correct, theoretical reasoning using simple logic applied to pre-existing abstractions.
I’m gonna pull a GeePaw-ism here and relabel “appealing, intuitively correct, theoretical reasoning using simple logic applied to pre-existing abstractions”. I’m gonna shorthand these to “Preasons”.
So. We get a lot of preasons in our trade. And they’re applied at every level, including but not limited to Coding, Designing, Tool-Using, Planning, Teaming, and Managing.
Why do we use preasons at all?
Well, simply put, we’ve no choice.
If I don’t know how to do a thing I have to make a guess about how to do it. If I am remotely interested in success, I have to have get some preasons, choose among them, and give my favorite a try. There are lots of ways to gather preasons, including making them up myself. (There are even preasons about the best way to do this.)
The only possible fix for that is to always only do things one knows how to do already.
But doing only things you already know how to do is a losing proposition. It will lose in business. It will lose in geekery. It will lose in management, and so on and so forth.
We have to change to win, and that means we have to have preasons to guess which change will work.
Why do the geek trades use so many?
I’m told by people in other trades that it applies to all trades equally. I don’t believe it.
It’s true I have only a passing familiarity with most other trades, so I could be wrong. But in my experience, preasons dominate the geek trade like no other. I see this every day in my work with teams all around the world. I see it in my RSS feed and I see it in twitter. I see it extensively in hucksters and third-rate thinkers.
I have come to believe there are a variety of factors that cause this huge reliance on preasoning in geekery in particular. But if I lump all of these factors under a single rubric, it would be this one:
Ignorance-Discomfort: we don’t know how geekery works yet and we really don’t like that.
So what’s wrong with preasons, anyway?
Nothing is wrong with preasons. Something is wrong with how we use them.
Regardless of whether any given preason has merit, there is one thing that every preason lacks, by definition. Preasons are always “pre-“. Pre-experience. Pre-results. Pre-data. Pre-implementation. Pre-local.
Preasons don’t account — can never account even in theory — for the actual experience of the actual team that is actually acting on them.
Now, this isn’t the fault of the preason. We absolutely have to have preasons when we don’t know what to do. There is simply no way around them. We cannot know with certainty the result of applying a given preason to our given situation until we apply it.
The sin isn’t in using a preason. It’s in not reviewing the result from using it.
Preasons don’t become reasons automatically.
I got this theme, you’ve already heard it: Act-Then-Listen is the fundamental template of successful geekery.
What I am aiming at with that theme is a failure pattern I see again and again. We grab for a preason, use it to justify an action, then grab another and do the same, ad infinitum, ad nauseum, ad legacy, ad enterprise, ad ass-hattery on an intergalactic scale.
In the act-then-listen pattern, the listening has equal value with the action. In the preason-act-preason-act-preason-act pattern, the listening is what’s missing.
This missing step, the part where we listen to see what effects our action has, is how we can convert preasons in reasons. If we don’t listen to our own results, preasons never become legitimate reasons.
If we fail to do that conversion, in a world in which there’s so much we don’t already know, we’ll create something as awful, useless, demoralizing, and largely ineffective as — well — the geek trades.
So How Can We Change This?
There are lots of things of specific things we can do differently, depending on the various domains and preason-based actions. But generally? These things:
Suspect all systems for developing software. All of them. Suspect anyone claiming to have a drop-in system for you or your team. Anyone. We do not know how to geek, still less can we tell people how to geek using abstractions applied from a great distance.
Suspect “try harder” answers to negative experiences. I am not saying here that you don’t have to try, or that you don’t have to practice. I’m saying at some point, a long sequence of “try harder” has to be replaced with “try different”. How long? It depends on context, but my generalized advice to the mode of the bell curve: shorter than that.
Suspect large resource commitments to preasons. Large resources include millions of dollars, your entire software development enterprise, any step that takes longer than a breadbox. Even if your current preason-experience with a project or a sub-team is positive, roll it out one step at a time.
When You Don’t Know What To Do,
What To Do Is Act-Then-Listen
(Note: Lightly edited and adapted from a twitter thread, where I’m @GeePawHill. Noobs be advised, I speak freely there.)
Accuracy in estimating software development times is a powerful example of forty years of “try harder” not producing any positive results.
Now, given some small change X and some substantial knowledge of the current state of my software, I can usefully estimate short-term work, from a few minutes up to a 50% hit-rate around about a week. This is because I have been a successful independent programmer for 35 years.
Without making any ridiculous boasts about my mad geek chops, I can still say this: I am good at programming, and very experienced. I am telling you that my estimating skill starts having more misses than hits in units measured in single-digit days. And that is when I have strong knowledge of the existing code base.
A week. Maybe two.
I Have Seen This
VLCAs routinely spend weeks estimating things that are months away. And they do it over and over again in spite of the lack of consistent value.
Companies spend millions of dollars on this waste, then won’t buy hardware for their teams, even teams that are currently winning. (I am not exaggerating for effect. I know I often do, but I am not doing so now. Sometimes I say such strange but true things that I have to make this clear.)
The dollar waste is truly staggering. And dollars don’t begin to capture the cost in team stress.
It is to laugh. Or cry. I can never quite decide.
This Theory Is Bunkum
They patiently explain to me, as if I were a goodhearted but somewhat simple neophyte, the theory of how their planning works. It’s centered around the sophisticated concept of something called “addition of numbers”.
Sadly, the numbers are a) made from whole cloth, b) made entirely without consideration of each other, and c) not able to take into account even minor changes in market.
Why are people so resistant to the dramatic evidence that comes from every side of our trade? I think it’s a combination of confirmation bias and third-rate thinking.
People have any two successes in a row and they think they’ve discovered a method. Sometimes it’s just one partial success. When they have three in a row, they give it a catchy acronym and pretend it’s a system others should pay to learn.
A Cheap Experiment And A Proposal
Flip a coin and see how long it takes you to get 3 heads in a row.
That’s what a 50% success rate looks like.
When it happens, do you believe you have invented a new technique for coin-flipping, require it of all future coin-flippers, and start buying up clever domain names to advertise it? If so, I have any number of wagers I’d like to make with you. I will travel, if the stakes are sufficient.
For a small handling fee, I’ll even procure your domain names for you.
What Do We Do Next?
Meanwhile, in that same part of the forest, VLCAs constantly ignore the far more urgent question: what is the next most important change we should make?
Not only is “what’s next” more important than “where’s it end when”, it’s also vastly easier to determine. No one can describe the state of their software a year from now. Everyone has an idea about the next important small bit.
Now, given that we have failed at this accurate-long-term-planning thing ten thousand times, maybe we need to rearrange things so we don’t have to do it at all any more.
You can know where you are now and where you will be tomorrow. I mean, literally, “tomorrow”, not metaphorically.
It seems strange to have to coach giving up, but that’s what I do. Please give up trying to predict the state of your software a quarter from now, because it can not be done for less money and time than spending a quarter getting there.
They say, “If we don’t know the future we don’t know the optimal way to get there.”
I say, “You can’t know the future and you can’t know the optimal way to get there until it is past.”
Change your business model so you don’t have to reliably predict the state of your software more than a month ahead. There are myriad ways to make this happen.
Or continue to spend hundreds of millions of dollars every year to not get what you want, in service to some over-simple theory, in the absence of consistent real data that the theory is valid.
Optimize Knowing What To Do Now
 VLCA is a GeePaw-ism: It means Very Large Corporation of America, an allusion to the Monty Python short called “The Crimson Permanent Assurance”, typically but not universally shown as the opening short film before “The Meaning Of Life”.
I’ve been having a lot of trouble getting to sleep lately.
I go to bed cuz it feels like it’s time. Sometimes my body won’t settle, itching and twitching and such like. Sometimes my mind won’t. Usually it’s a mixture of both. So I get back up. But then I’m tired as hell, and it seems like I’m sleepy again, so I go back. Rinse, lather, repeat 3-5 times.
Eventually one of two things happen. Either I finally manage to pass out, or I get up and move out to the deck and sleep on the couch. Sleeping on the couch by myself seems to help.
This is Molly, freshly be-coned from having been spayed yesterday. She, her little brother Wobbles, and my wife all share the bed with me. Since Wobbles is still just a little one, 11 weeks old, we close the bedroom door at night, to prevent accidents and chewing out in the rest of the house.
Sometimes when I get up Molly will come with me, other times not. If I move quickly she just stays in bed and then the door closes and she doesn’t pursue. It’s openable by her, but not readily. It’s kind of a “press-fit” and takes some effort.
The other night, I was having a particularly hard time, very dark blue.
I did the now-usual up-and-down thing several times, without Molly. I finally decided to try the deck. I curled up out on the couch and settled in to mope my sad self to sleep.
A couple of minutes later, Molly came and curled up — unusually — at my chest, where she spent the night, or at least until I slept. She had decided she would force the door, and she decided the thing to do was sleep at my side, not, as she usually does, down by my feet with a foot of space between us.
So there ya go, a simple story of a boy and his dog.
There is nothing spectacular or miraculous going on here. It’s common to almost all dogs that they’ll sit quietly and nuzzle a sad owner.
This story gives me four things to marvel at:
First, I marvel at the wonder of nature. Clearly, the body of the dog — of all dogs — is made to respond to a set of clues from the bodies around it. Stuff we’re used to calling our “emotional state” is included. (I realize I’m begging the question of my materialism here, but I don’t care: I’m a strict materialist most of the time.)
Second, I marvel at my long-term and ever-growing sense that I am not in charge of me. That is, the thing-that’s-conscious is not in any easy sense in control of the thing-that-acts. That’s a very long story and plays a part in how and what I coach.
Third, I marvel at the apparently naked-to-her-and-others intensity of my need. We cue the world constantly in ways we don’t understand and can’t see. Somehow I cued my need for what she did. Somehow she sensed and responded to that cue.
Finally, I marvel that I can think all these things without unweaving the rainbow of my affection for this little dog. Knowing we’re talking about things far beyond the control of either of us, believing they are physical and organic not mental and will-driven, in no way undermines our love, not one tot.
In many ways, this is a continuation of my former work over at http://anarchycreek.com, which you should take a gander at if you want to know where I’m heading.
This blog is about three topics, usually intermingled herein;
- Programmers — People who create software for a living.
- Code — the actual stuff that programmers write.
- Thinking — the part of programming that is the hardest.
That’s it, for now, but my next steps are to move the DoubleDawgDare series here, finish it, and launch a new one.
Enjoy, and comment, and subscribe, and write me!