Have you seen the type?

Many would-be leaders, including coaches, are one-trick ponies. The only trick they have for coaching is to clothe an idea in a thin tissue of “reason”, then use it to beat every nearby person about the head, neck, and shoulders. The saddest ones even do it to themselves.

Here’s the thing: There are many and complex ways for one person to influence another person’s behavior. An overweening rationality is one of the weakest. If you really want to be a great coach, you’ll investigate and experiment with them all.

Rational Bullies Are Still Bullies

Being right is not guaranteed by being rational. Further, even if you are right from time to time, being right doesn’t — shouldn’t — automagically make the people around you follow your lead. This is not philosophy, here: there are sound reasons why humans don’t jump to a rationalist’s every tune.

If being “rationally right” is the only thing you got going for you, give it up.

That’s all for today.

Oh, weekend homework: think of a *specific* geek you can help with a *specific* approach other than “logic is my handgun”.

I have felt for some time now that I had no good place to stand.

I’ve been an “XP coach” forever, since the earliest months of that movement. Over the years, the rigor of the XP concept faded into the misty vagueness of “agile”, through the efforts of many proselytes, including myself, to make it seem palatable.

The results have generally not pleased me.

Bob Martin pointed out the other day (via tweet), that the Agile Conference this year contained fewer than 10% technical presentations. I shot him a rude remark about it having been true for some time, but after apologies (Bob’s pretty strong on code, after all), the spurring fact is the same.

I may not know what the exact right mix is, but I surely know it’s more than 10%.

XP Is About The Balance
Lose The Balance, Lose The Movement.

Upon a time, once, I heard a critique of XP that said “It’s too code-centric.” Then and now, I visualize the guys at the Road-Building Universe conference being busted for being too “asphalt-centric”.

Meanwhile, setting aside cheap shots (temporarily), I soldiered on.

I’ve been talking for the last year about braiding together geek joy and business value as an approach towards excellence.

But you can’t really call it braiding when it’s just two strands. Braiding two things together is twisting, not braiding (Props to Tracy Kaleidic for reminding me of that again.) I needed that all-important 3rd strand.

Meanwhile, Back At The Ranch…

I kept inserting little articles  about, well, you know, humans and how they are conditioned by both their species history (evolution) and their development (ontogeny). You know, blah-blah-blah. I knew it was important, so I kept (unconsciously) trying to sneak the idea into the door.

Not so, anymore.

Towards Excellence: A Three-Stranded Braid

My belief is that success in the world of software development — excellence, if you will — is a matter of braiding three strands together: geek joy, business value, thrown agency. (Eh? What was that third one again?)

If all that comes at you a little fast, no sweat. I have a *lot* to say about this, and I’ll be saying it here for the foreseeable future. Just to get the mind wandering, let’s do some one-liners and call it a day:

• Geek Joy means finding ways to maximize that sweet spot where technical workers can frequently experience that awesome pleasure that brought them to their trade in the first place.
• Business Value means finding ways to be constantly aiming at the things our surrounding corporation needs from us the most.
• Thrown Agency means working in full awareness that we’re constantly bound by being real humans in a real universe.

Gotcha on that last one, didn’t I?

No matter, there’s plenty of time going forward to explore thrown agency at length.

That’s it for today, except I have one more definition to throw at you:

Braided Means We Need Three Strands:

Geek Joy, Business Value, And Thrown Agency.

Miss One, Miss Excellence.

I want to end that silence starting today.

See, I’ve written the first two paragraphs of many draft posts, but I haven’t posted them:

1. Too tentative;
2. Too minor;
3. Too insufficiently cooked;
4. Too illiterate;
5. Too damned embarrassing;
6. …Too this and that and the other thing.

My Best Laboratory For Exploring Foolishness, Again.

That’d be me.

There’s an ancient saying about “the best being the enemy of the better”. I use that saying and its conclusions all the time when I’m working with other people.

But see, that’s different. In those cases, the timber of those poor benighted excellence seeking souls is far far larger than my own itty-bitty-tiny mote.

Those people are opposing an increment of improvement because they’re too enamored of some currently unreachable goal. I, on the other hand, are simply, that is, I mean, what I’m doing is, ummmm, different, in that, my, errr, behavior, is –

Fine.

The shoe fits. I’m wearing it.

When you notice a team stall improvements on the grounds that they’re not perfection, what is the correct recommendation to give?

The correct recommendation is that today’s gain in insight is far more important to us than tomorrow’s, next weeks, next release’s, next quarter’s, next year’s.

As penance, I will do my best to post some short-but-real every other day henceforth, regardless of its readily apparent imperfection.

I Hate This Business

The main TDD disabler we’ve already met: a broken or too-slow build/run/result flow. If your team has that issue, throw all your weight at it, and do not try to launch TDD itself.

It’s very important that the team’s initial experiences with TDD are not blocked by externalities. Whether its easy or hard to roll the first few microtests, the difficulty needs to be focused on the pre-TDD code, not the process itself.

If you have a disabler, your coaching story is clear: we can’t do TDD until we fix it. Once the disabler(s) are cleared, we need to turn to the various factors that don’t quite stop the show: the inhibitors.

Inhibitors

An inhibitor doesn’t block TDD, it just makes it harder to apply.

(Don’t relax: if you pile a few of them on, you’ll long for a good old-fashioned disabler, because it would at least have kept you off the TDD road until  you tackled it.)

Inhibitors are usually about technique.

(And still don’t relax: you can’t simultaneously introduce 82 slightly different variants of technical solutions.)

Let’s take one detailed example, then sketch a few others with their related solutions.

The Promiscuous Database

The promiscuous database is an inhibitor I’ve found very common, especially in IT shops. It’s easy to spot: just grep the source for “SELECT” and inspect the results. In a typical nightmare, virtually every source file will contain explicit SQL.

(Sometimes there is some awful framework in place, that makes the grep not look so bad, because the actual SQL is in some bizarre xml file. Same problem, different grep.)

The promiscuous database does its damage by forcing all microtests to rig up the database and then connect to it. How do you spell heartache?

Moving The Database Out

The solution is straightforward: extract each SQL statement, or each hardwired database statement, into a separate class named for the intention of its calls. Now we can easily use a hand-rolled or automagic fake.

Some details:

• Name the class for its intention, e.g. GetOutstandingLoans, not ComplexSQLCmdWithThreeParameters.
• Pass the parameters in the constructor.
• Return typed containers.
• Discover, don’t pre-implement, shared code to pull up.
• Consider a hierarchy based on command return-type rather than ‘tables touched’
• You may want to use a factory approach for getting the actual command.
• You certainly want some way easy way to slip a fake in. This can be done at the caller’s constructor, or just use a factory method that can be overridden.
• Wonderful side-effect, it often shows you more dup than you thought was present.

I hope this solution isn’t too telegraphic. If so, holler at me in the comments. The real point here is that we’re talking about learning and using programming technique to solve most inhibitors.

Readily != Painlessly

It is readily possible to solve the promiscuous database using coding technique. But readily doesn’t mean painlessly in the beginning.

Everyone who’s got work in the caller-class has to be able and willing to do these extractions. It can be done, but until a few tries are under a noob’s belt, it will feel like a useless formalism.

This is the general tenor of working against TDD inhibitors.

Let’s sketch a few more inhibitors and their solutions.

The Very Large GUI Of The World

GUI classes that do frighteningly complex work are the bane of any team working legacy TDD.

The problem here is tremendous and obvious: you can’t test the functionality without launching the GUI itself. Say goodbye to rapid feedback.

The answer is easy, or easy-esque: create a class whose lifetime is exactly coterminous with the GUI class, then rework your GUI class so that all non-graphical work is done by the shadow class. Turn the GUI class into a specialist who removes GUI-isms before passing on to worker, then puts GUI-isms back in on the way out.

The Hardware Distraction Layer

Direct calls into the hardware are everywhere. This is a hallmark of the embedded scene. Look for globals.

Solution: You need an adapter that fronts just the calls that this particular client needs. Work to make that adapter really hide the underlying dependencies. Once done, you can readily fake the adapter as needed.

The In-House Framework Of Universal Despair

The colossal ass-hattery known as “our in-house framework” is often an inhibitor par excellence.

The framework provides needed services, such as a database connection, that we don’t know how to get access to without launching the framework.

In this case, usually we’re seeing significant work done in a class that derives off of something from the framework. The trick here is just another variation on the theme of ‘take away frameworkisms on the way in, and put them back on the way out’.

Coaching On Inhibitors

The meta-pattern for inhibitors is simple.

Coach two or three teammates through the process of working around a given inhibitor.

This will give you two key advantages: the ability to show multiple instances of ‘problem-solved’, and the support of the teammates who actually lived through the solution.

So? Use lottery learning, or some other meeting, to introduce the problem and its solution. Show them the two or three. (Without the show you’re just being an abstract chatterer.)

In early days, just make the team aware you want to be tripling any time that problem comes up.

Ultimately, early days pass, and you can say with some confidence that your whole team knows how to finesse the solved problem.

After that time, and only after it, the team can raise their standard of excellence to say “files like this are hereby declared TDD’able”.

Inhibitors Are Crushed By Experiences

Go To It

You should.

For those who haven’t yet, a code retreat is a long day of programming, constrained in such a way as to create an open-ended opportunity to learn.

The formula is simple: we do six sessions of paired TDD. Each one is on the same problem, but with a different partner. The code is destroyed at the end of each session. That is, each session starts entirely from scratch.

That’s all there is to it, or so I thought going in.

Getting Hooked

The remarkable effect of the constraints is to focus a very high intensity onto the problem domain and its potential solutions.

You care.

The problem itself is readily understandable, but its potential solutions are really not. They are just one hair too complex to hold in your head all at one time, which is brilliant.

A toy challenge would not work nearly as well.

On the other hand, if the challenge were harder, you wouldn’t, or at least I wouldn’t, approach it with the easy certainty that you know the solution already. The experience wouldn’t be nearly as valuable without the scorched arrogance.

Test First vs Test Driven

The certainty of solution starts boiling off in the first round, and somewhere in the third it runs out altogether.

This is good, partly because the smell of burning ego is good for the soul, but also because it makes it much easier to open one’s heart and mind to learning.

Once I got opened, I learned many things, some small and some not-so-small.

After the sessions, we talked about what, if any, lessons were learned. Perhaps the single most common statement was that the participant learned that having a pre-formed solution in mind could cause lots of pain.

Corey Haines calls this ‘pre-conceived solution’ thing ‘test first’, as opposed to ‘test driven’. It’s an excellent distinction.

The idea is that in test first you solve the problem in your head, then write a test to force that solution, then type it in. Truly driving by tests, on the other hand, means typing in the test with beginner’s mind, and starting to solve it only after you’ve written it.

That’s exactly how it should be in our daily work.

Old Friends and New

It was fun to see some old friends, my pal George Dinwiddie, and my until-now-twitter-only-friend John Stoneham. I knew Corey Haines from the scene, but mostly also on twitter, and it was a blast to get so much good time with him.

But it wasn’t just my old friends. Many of the folks there came from one or more of the sponsors. The local hosts, Gustin Prudner’s Entryway, did an amazing job. They procured and prepared two excellent venues for our sessions, and everything went off without any hitch.

I won’t list the new friends I made, but I was delighted to hang with so many people who clearly care about excellence in software development.

Geek Joy — *Shared*

The most important lesson was one I re-learned rather than encountering for the first time: to share geek joy is delightful, intense, and absolutely revitalizing.

I feel like I need to rush right out and do good geek work today.

I’m already on record for saying that what the industry needs most is to learn how to intertwine geek joy with business value. But to be reminded so forcefully is just terrific.

Go Sign Up Now

It’s Cheap And Amazing!

Me, Hunting For Yabbits

Ever get the yabbits when introducing a new idea?

Oh, wait, maybe I better define my terms first.

Yabbitting is when people go through a sequence of resistance statements, where each statement begins with the words, “Yeah, but…”.

Like this: “Yabbit, our shop does shrinkwrap, so what works for some web app isn’t gonna work here.” or “Yabbit, we all work 80 hours a week, so we don’t need slack.” or “Yabbit, if you write tests + code, that’s more code than if you just write code”.

Let’s try again: Ever get the yabbits when introducing a new idea?

Yes, I thought so.

Aren’t Yabbits Annoying?

Yabbits can get a person down.

Worse, if the person has GeePaw-ish tendencies, yabbits can really bring out the sarcastic asshole:

“Wow, you’re right. No one ever mentioned that to me before. I should probably leave, now. Thank you. Thanks, thank you. You’ve saved me a lot of wasted time. Uhh, bye.”

But responding to yabbits like this is a grave error. (Trust me on this.)

A noob coach usually sees yabbits as a huge annoyance at best, and a wall of resistance at worst, but this is a big mistake.

Getting yabbits should please you. They sound like they represent resistance, but they actually indicate just the opposite.

The Economics Of  Thinking

How many times a day do humans choose one thing over another? Certainly hundreds, if not thousands or tens of thousands. Which socks? Left or right? Coke or Pepsi? and on and on.

Many of these choices are somewhat automagic: the answers to them have typically been made way in the past, and are not really ‘re-chosen’ every time the question comes up.

Others, on the contrary, are the result of full and thorough efforts to consider variant choices, project their results, and decide how we feel about them.

So some choices are virtually free, and others are quite expensive.

So what’s the most frequent choice made by a human?

It’s the meta-choice, of course. Whether you make a cheap choice or a pricey one is itself a choice. Cheap or expensive?

Yabbits Are A Heuristic

Yabbits are actually a tool for making the meta-choice. It works like this:

If an idea can’t defend itself against simple one- and two-sentence arguments, then it certainly can’t handle any serious ones, so I don’t need to investigate in depth.

Yabbits don’t always, or even usually, represent real resistance to change. On the contrary, they are probes, whose intent is to test an idea’s prima facie validity.

A person who offers you yabbits is typically more open to an idea than a person who says nothing at all.

Responding To Yabbits

The most obvious aspect of your response is just to note that, since yabbits are a good thing rather than a bad, you should prolly refrain from indicating displeasure.

Now, I can’t say you should smile when you get a yabbit, because that can easily look like smugness. But you can respond positively. Never hack at a yabbit. Instead, relax, and calmly show exactly how your idea doesn’t suffer from any trivial  flaws.

The rest of this page is just a set of common yabbits, pulled from various practices in the agile toolkit.

Notice that each one is just a few lines long. That’s on purpose: don’t overload a yabbit with a long response. That’s using big guns on small quail.

Yabbit, We Want 100% Load

Actually, no you don’t.

100% load means full stop for most of the team. Don’t believe me? Think about the last traffic jam you were in. The optimal load of cars for a highway is far less than 100%. More cars != more throughput.

What you really want is optimal load, which is the highest load for which actual throughput continues to rise.

Yabbit, It’s Just Until The Release

I always ask teams about their last release.

So what happened? You shipped the release, then everyone took two or three weeks off to catch up with their families, or take care of their mental or physical health? No?

For some teams, shipping on Friday means coming in Monday and starting the next release.

For many, maybe even most, shipping on Friday means coming in Monday and immediately jumping in to hot-patch mode.

Yabbit, No Pressure Means No Production

You mean, you hired a bunch of people who won’t work if you don’t constantly harass them? What a drag. Next time choose different people.

Of all the bizarre taylorisms in bad management practice, this one is the least connected to reality. We are called geeks precisely because we take so much joy from our work.

You don’t have to force geeks to do geek work, you have to get out of their way.

Yabbit, How Can We Assess Merit?

This one tickles me, too. The idea is that the marathon and village principles seem to work against the easy assignment of rewards to individuals. If we pair all the time, rotate pairs all the time, and all sit together and work, then how can management tell who to reward and who to punish?

You can assess merit by a) working with the individual, or b) watching the individual when she is at work, or c) asking the people she works with.

It is trivially the case that everyone on a team has a complete ordering of merit for everyone else on that team. Gather the orderings (not the votes, the orderings) anonymously, and you will certainly see a pattern. Use that pattern as the basis for your assessment.

Yabbits Are Your Friends

It is easy to think of yabbits as temporary distractions from the real game of changing behavioral patterns, but that’s a mistake. Answering yabbits won’t change anyone’s mind, but it will build confidence and support for your ideas.

Yabbits Are On The Road To Success

Use all of the coaching pillars to help instill the message:

• Situate by teaching and explaining the beliefs.
• Model by living them publicly.
• Invite by having fun writing microtests.
• Sort by leaving time for skill development.
• Release by letting them manage the ‘must-test’ list.

Required Understandings

Each of the sections below is a statement of belief we want all of our developers to be conversant and comfortable with.

Imagine your teammates talking to members of a non-TDD team. If they can spontaneously explain and defend their behaviors using these beliefs, we’ll have won most of the battle.

We’re In This For Productivity

You know my rant on this one. TDD is not about quality, it’s about speed.

I often use the comical fact of ‘night-coding’, i.e. programming for your own amusement.

When I’m night-coding, I rarely write storytests. Storytesting is expensive on code not built for it, and besides, storytests are really a collaborative tool. I already collaborate well with me, so I skip storytesting. (Some agilists are disappointed with me about this. I tell them to go to the back of the complaints line.)

On the other hand, I always use microtests, even for night-code. Driving development by microtesting is a productivity tool. Even when I’m in the privacy of my own back porch, I want productivity. Everybody wants productivity.

There’s No Free Lunch

But don’t kid yourself. TDD is not free.

Some ideas are simple facts, really. Once a C++ programmer learns why she should default to ++i rather than i++, it’s pretty easy to just always do it without much thought. Simple facts deliver their value instantly.

TDD is not a simple fact, it’s a whole way of programming.

Ask people how long it took for them to learn programming in the first place. The good news is that it will take much less time to learn TDD, because they already know the syntax, the tools, and the problem domain. This time they just have to understand a loose cluster of a couple dozen techniques.

But it ain’t free. Your team is going to have to practice practice practice. Make them — and their managers — completely relaxed about this.

We’ll Adopt TDD Sanely

Remember the sit-in-your-own-lap transition? How can we get TDD all-at-once-a-little-at-a-time?

We make a list of classes called the ‘must-test list’. If a developer is going to touch a must-test class, she has to use full-on TDD: microtests written before changes, the ol’ red-green-refactor-integrate cycle, the whole kit and caboodle.

Over time, we grow the must-test list in two ways.

First, we grow it by turning more and more classes into ‘must-tests’. We do that by fixing awkward dependencies, either at the class doing the calling, or the class being called.

Second, we grow it by learning the patterns of refactoring that can make a non-testable become a readily-testable. Each time we get the whole team to perform a new refactoring, we can add classes that would be testable if only we knew that refactoring.

Let’s do an example: many teams have yet to recover from the singleton pattern, so they have classes that depend heavily on global data. Using alternate constructors is a simple  pattern that can solve this problem. An hour of study and one successful attempt, and you’re good to go. Once the team has that pattern, we can add to our must-test list classes that would be readily testable except for their use of globals.

The must-test list starts life as a list you control. Think in terms of adding two classes a week in the beginning. Make the changes in the must-test list at the iteration break, say, during the planning. As the team builds their experience and excitement about TDD, you can gradually hand over management directly to the team.

Coach The Inner Game
Give Their Minds The Right Stance

Sometimes I do it by itself, as in the DoubleDawg. Mostly, though, I do it inline as part of the TDD discipline. I love it either way, and I can’t explain why.

Loving refactoring so openly is good good good when I’m coaching: other people can’t help but watch what I’m doing and then try to see if it’s really as fun as all that. (It is.)

But once a team jumps into the act itself, there’s a question that just has to pop into some minds, especially the ones who feel it’s very important to, you know, ship:

How Do I Know When I’m Done Refactoring?

“You’re done refactoring when the code meets our current standard of coding excellence.”

I’m always surprised when someone just nods their head to this and turns away, as if I’ve actually given an answer. I guess questions can sometimes be pro forma gestures, too.

Anyway, that’s a terrible answer, but on good days it leads right to the next question: What’s our current standard of coding excellence?

The Challenges Of Standard-Setting

Setting standards seems to cry out for the clarity and detail of a perfectly written set of rules. Ya know? If we just sat down and carefully listed all the things you can do, and all the things you can’t do, using maximum simplicity and maximum clarity, we’d have a perfect standard.

Then there are those of us who have either studied law, or babysat a truculent nine-year-old, or both.

1. We want our rules to cover everything, but only a small handful of situations can really be described that way.
2. We want our rules to be stable, but time and experience make mockery of our earlier attempts, time and again.
3. We want our rules to be axiomatic, but as Kurt Godel demonstrated, any such that are sufficiently powerful to be of interest are also suffiicently powerful to contain undecidable propositions.
4. We want our rules to be simple and no-nonsense, but as any handy nine-year-old can demonstrate, when it comes to misinterpretation, where there’s a will there’s a way.

So? What to do?

The Simplest Thing That Could Possibly Work

When I first studied the XP process, I was struck by Kent Beck’s ability to construct rules that were as perfectly detailed as they could be, but no further.

“Do The Simplest Thing That Could Possibly Work” is a wonderful example of this.

Without a rigorous definition of simplest, possibly, and work, a computer would find this rule absolutely empty. All the important words in the rule are left to individual human judgment. Defining them would take years and years and would still fail. (Read the XP list some time.)

But the rule works in spite of the uncertainty, because it contains an implicit ‘you’ for each of the ambiguous words. Simplest means simplest-to-you, and possibly means possibly-to-you, and work means work-the-way-you-want.

Notice that this kind of rule completely evades the problems list from above. Clever.

My Rule For Refactoring

You are done refactoring when you’re ready to project the code onto the wall for the whole team to see.

This rule works just like the XP ones: it is full of opinion, judgment, and you-ness.

This rule works best when its coupled with actual code projection, along the lines of a lottery learning session.

I like that we simultaneously release the team, empowering them to decide for themselves what’s enough, and also situate them, showing them that their coding standard is going to be super-local, theirs and theirs alone.

I also love that I get to watch the actual meaning of that rule change. Every actual projected code session makes changes to the underlying meaning, and so do most pairing sessions between a junior and a senior.

Use The Projector Rule

To Identify The Moving Target Code Standard

The automation principle is  one sentence long, but it points a dozen directions at once.

Teams are usually all-or-nothing in automation. Once a team realizes how lovely it is to not-think on no-thinking-required tasks, they jump right in and build or tune all their tools for maximum advantage.

Don’t you worry, I’m just sure your team will be one of those easy ones. If that’s the case, you can just skip this article and make a cash donation to the charity of your choice.

Urgency + Automation

Ahhh, yes, not one of the lucky ones, eh?

Your first challenge is just to decide what your first challenge is. The sheer number of possible automation stories is daunting: it’s one of the biggest reasons I advocate the half-and-half transition. A sizable portion of your energy can then be given just to tackling automation stories.

The Inner Cycle

The inner TDD cycle is always the most urgent target for automation.

We need a single-step for “save my changes, compile/link/copy, and if there are no errors, launch the microtests-of-interest”.

• Save my changes: Many almost-ready automation sequences shortchange this step, but it’s important. You never want to run your microtests against the code before your changes.
• Compile/Link/Copy: The two most important issues are the 100% problem (for optimal builds), and for some teams, the need to take binaries and put them in the ‘right’ place for running.
• Run Microtests-Of-Interest: some teams stumble here. The final step of the inner cycle is to run and examine the microtest results. Starting the actual program running is not a necessity.

It’s important to understand that we are not looking for three separate gestures here. We want all of the above action to happen with a single gesture.

Integrate It!

Next after the inner cycle is integration. This time, it’s not a single gesture:

• Show Me Everything I Changed: The output should be in the identical tree shape of the source. If you made some changes you don’t want, revert them here.
• Merge Out: Bring me everyone else’s changes, with a merge system for each collision between my changes and theirs.
• Run Inner Cycle: We’re not done merging out until the microtests run green.
• Commit Everything I Changed: Usually there’s another round of show-me here, followed by the actual commit.

When we can do all four of these actions with simple and thoughtless gestures, we’re in good shape.

The Trap Trio

The integration automation is a good place to consider the three most likely coaching difficulties, as they each can be found there. These are all noob problems: an experienced automater sees these situations all the time, but doesn’t fall for them.

All-Or-Nothing-At-All: Engineers, yo. They get trapped here because they can’t think of an automated solution that solves every conceivable variant. This is an easy one to resolve: teach them how to implement their scripts and macros as fail-fast. If our scripts can establish that it’s a situation they can’t handle, then they can fail right out. Sometimes 91.5% is just fine.

Mind-In-The-Middle: Automation can’t work because there are some sub-steps that absolutely require human intervention. No, that’s not quite it. It’s because there are a bunch of mind-needed sub-steps, spread throughout the process. This problem might fall as in all-or-nothing: automate what you can, don’t sweat what you can’t. But more likely, a clever person can smoosh the sub-steps in time, so that the mindful parts are all in the same place. Then we just leave that single hole in our automation and have everything else mechanical as can be.

More Controls = More Control: This one’s endemic. Folks who couldn’t code a fucking for-loop sitting in front of the jet cockpit of a universally-mandated fabulously-expensive entirely-wasted version control system like they have some clue what they’re doing. These systems justify their wretched excess on the theory that they give you every conceivable control over your integrations. Agilists in particular should not buy this theory. The resolution? It’s a combination of the two that just came: rearrange mindful steps, and settle for less than perfect solutions. In particular, don’t be afraid to write front-end scripts that quietly drive the VCS for the most typical variant.

A Radically Simplified VCS

Leading Automation Efforts Is

Perfect Releasing!

To me, the most amazing thing about the urgency principle is how I ever managed to live without it.

As an individual, it reminds me to stop screwing around doing stuff that is anything less than the most important thing. This works for me whether I am coaching, coding, writing, blogging, or doing home repair.

The quantity of empirical data that says multi-tasking is inefficient staggers a researcher’s mind. No one advocates doing two things at the same time. It follows, then, that if I’m not doing two things at once, I have to choose which one of those two is most important and do that one.

As For The Team

As a team, the urgency premise is all about sorting user stories – software development for the business – into a literal stack, where the most important story is at the top and the least important at the bottom, and every story between is more important than the one below it and less important than the one above it.

Many companies bucketize their work. They pick some small integer, usually 4, and divide all their stories into those buckets. They’re usually called “Must-Have”, “Should-Have”, “Like-To-Have”, and “Optional”. This technique has the rather remarkable property that it does not work in any way. Every customer voice in such an organization knows that the only way to get something actually done is to get it into Must-Have, and even that isn’t always enough to guarantee its inclusion. Optional is always empty, and Like-To-Have has one or two token stories.

Coaching Urgency

The key to coaching urgency successfully is to help the team understand why story-size is so important. Granularity is key, here. We want them to understand why we shrink the granularity of stories as small as we possibly can.

Take a look at these features (large stories) sorted by importance:

It’s pretty easy here to say that we should do our work 1-2-3-4, yes?

Same Order, Smaller Stories

But what if we take those same four features, but this time broken into smaller stories. Everything in the figure below that isn’t in light blue is lost value. If we follow the 1-2-3-4 strategy, we’re going to implement B and C before we implement D, and that’s clearly sub-optimal.

The Actual Optimal Order

The final figure below shows the same work as before, this time sorted absolutely by value. Do you see that by splitting and re-sorting we have dramatically changed our implementation order? So will your customer team.

The shape here is called the diminishing value curve. Producing stories A-D-B-G-E-H-F-J-C-I-K-L is far better suited as a strategy. If that’s not obvious, let’s take the same diagram and add a shipping date:

There’s room here for another whole conversation about the shape of a user-story. Soon, soon. For now, this will do:

Choose One Story, Hammer It. Repeat