There’s a common thread to the first two parts of the HAHSIYOLPS (HSP) transition. The third element is driven by the same force:

There’s Not Enough Time…

Development teams are never given enough time to build the skills and attitudes we need for agility.

XP is intentionally minimal, but it still has a lot of moving parts.

What about adaptation? Couldn’t we just adapt XP until it’s right for us? Isn’t that a key value of agile systems?

Yes, but there’s a problem. A team that’s new to agile does not have the experience needed for adapting it. (Tho they always try.)

…AKA There’s Too Much Work

Agility itself tells us not to say “there’s not enough time” but instead to say “there’s too much work”. We rarely slip deadline, i.e. time, we just slip scope, i.e. work.

The transition to agile represents a lot of work. We have to solve one helluva lot of challenges at once: legacy code, legacy meetings, legacy priorities, legacy brushfires, legacy matrix management, and yes, legacy process.

We need to generate for ourselves the awesome XP experience, while simultaneously keeping our day jobs afloat.

Me, Looking Down Some Railroad Tracks

Enter The Perfectly Slow Track

The perfectly slow track is a story track in which the team takes as much time as it needs to do perfect agility.

So there are two story tracks: the regular one, and the perfectly slow one. On the regular track, the team does all the stuff they normally do, done the way (mostly) they normally do it.

The perfectly slow (PS) track has these properties:

• work-in-progress (WIP) limit is one story at a time;
• a single dedicated pairing station, ideally with projector;
• guarantee from team it will be worked during all core hours;
• random pair rotation every two hours at most;
• work is production work, i.e. pair freely commits;
• and most of all, the PS track adopts agility perfectly.

There will still be judgment calls, even in a PS track. When the story is pulled, the coach may want limit its perfection in some way. But once under way, any “non-XP” judgment call must be validated by the coach.

Perfectly Slow Success

Before long, the team will start clamoring for the perfectly-slow track to be their only track.

In the mind of an agile noob, the strange ideas of agility seem either wasteful or impossible.

The perfectly slow track is ideal for giving people real agile experience without having to break through the fears and misunderstandings that propel the ‘day-job’.

Notice that perfectly-slow fits with sit-in-your-own-lap. We can take the regular track, do partial adoption there, and still park anything we don’t think we can handle into the perfectly slow track.

In real life, as we know, developers will learn how to work effectively using agility, and their techniques, moods, attitudes, and humor will spread out from the PS pairing station to infect the whole rest of the team.

When The PS Track Succeeds,

The Rest Is All Downhill!

For most folks, tho, another question comes burbling right away when they consider doing an agile transition. They’ll want to know which practices we are doing and what order we’re going to adopt them in.

I’m So Glad You Asked

Have you ever sat in your own lap?

It’s that goofy cooperative game where we put everybody in a circle and have each person sit in the person behind them’s lap. Check the video above if you’re not sure. And, no, I’m not one of those touchy-feely coaches who makes teams get in touch with their inner lives by doing silly things. Mostly.

Now read these professional lapsitting guide instructions:

Everyone turn to your right. Step in closer to the centre and put your hands on the waist of the person in front of you. In a moment, we are each going to sit on the knees of the person behind us keeping our own knees together as we do. Concentrate on guiding the person in front of you to sit comfortably on your knees, and trust that the person behind you will guide you, too. First we will have a trial run. On the count of three we are going to bend down, touch bottoms to the knees and come right back up to make sure we are all standing closely enough together.

Whoa!  Metaphor central!

I know, right? There must be ten different ways we could use this metaphor to talk about transitions. But I’m going to limit myself to just one.

Sit-In-Your-Own-Lap means that we are going to adopt all the practices at once, in steps..

All At Once…

Agility is purposefully a minimal system.

Take one part away and the other parts are certain to be less effective, and quite likely to fail altogether.

We need to get the whole kit into place to get maximum value. Half measures tend to have worse results than just not changing anything.

Need an example? In the agile approach, we use a practice called collective ownership. Anyone can change anything anytime.

Successful collective ownership depends on continuous integration and a microtest driven development approach. If not, we’re looking at massive merges and brutal regression failures.

…In Steps

On the other hand, agility also isn’t a switch. Many teams (and coaches) have tried to do things like adopt every practice to its fullest extent on a given official start day.

That doesn’t work.

Take a gander at those instructions for lapsitting up there. Notice that the pro lapsitting coach actually takes several very explicit steps on the road to the final sitdown.

Bingo.

Which Steps?

The steps vary from team to team, as so many other features do. But here’s a typical example:

Our website product uses struts, naively, so that the action code is virtually uncallable without the surrounding database connections and webserver running. There’s a natural target there for a double-dawg-dare, so in the early weeks of a transition we’ll figure out a layering solution that works for us.

Once that’s available, we can take a solid step towards TDD: The team must use the layering solution for all new action classes, and they therefore must be 100% TDD’d.

Teams will say to themselves things like “we’ll TDD in every situation that we can”. Which is a lovely idea, but often fails. The team doesn’t see TDD the way a coach would, so it winds up doing nothing at all: as far as the team is concerned, they can’t TDD anything. That’s why the coaching is so important.

Run Your Transitions Sitting In Your Own Lap!

Yin of Teaching, Yang of Coaching

I want to introduce you all to the:

Half-And-Half Sit-In-Your-Own-Lap Perfectly-Slow Agile Transition

But I can’t, at least, not in a single blog post. So instead, I’m thinking we’ll approach the HAHSIYOLPSAT (okay, sure the HSP transition) one element at a time.

Today, we focus on the Half-And-Half part.

When planning a transition for a new team, most coaches prefer teaching to the rough-and-tumble of just joining the team.

Courses Help

Starting things off with a class is a very common approach for coaches. This approach has many positive features:

• Technical Learning: That’s the obvious one. There’s a lot of technique to learn.
• Safe Practice Space: It is far easier to learn something when you’re not under shipping pressure.
• Teacher As Leader: Unlike consultants, a teacher is granted a presumed competency in both the subject and leadership.
• Excitement: Classes well taught usually get their attendees all fired up.
• Assessment: It’s far easier to assess a team when it’s solving problems the coach has prepared in advance.

Even Good Classes Have Faults

There are some drawbacks to classes as well:

• Work Stoppage: If we’re in class all day, we aren’t shipping code. Many teams have to leave class at 5 and then go do their day jobs.
• Missed Focus: Course materials are written for a generic situation, not the specific one the team is in.
• Teacher Time: Teachers have little opportunity to explore the actual challenges that confront the team.
• Too Much: Classes usually pack way more content than the students can handle, because they don’t have ways to integrate the new skills into their normal job.

So?

Morning Class, Afternoon Work

During the first three weeks of an agile transition, we divide the team’s day in two. In the morning we have class. In the afternoon the coach either 1) pairs on daily work, or 2) pairs on transition prep, or 3) pairs on course materials.

With this approach, we still have all of the benefits of a class, but we also fix or at least ameliorate the disadvantages:

• Work Stoppage: Yes, I know it has the same actual effect. But it doesn’t have the same psychological effect at all.
• Missed Focus: Course materials improve dramatically, as the coach now has time and permission to tighten their content.
• Teacher Time: About the same in time, but much more effective and interesting and productive.
• Too Much: Every afternoon, the students are using the new ideas they’ve just learned. This means much better absorption.

The half-and-half approach comprises seven whole days of instruction, but in a way that management can accept, the team can use, and a coach can drive to create maximum effect for the transition.

Half-And-Half

Optimizes Learning & Teaching

• Core hours: the team picks 3-5 hours as “no meeting” time, when everyone is expected to be present and working in the open workspace.
• Standups: the team holds a 5-15 minute standup meeting every day, to foster first-order communications that can lead to impromptu meetings.
• Leave At Will: if someone is not actively learning, teaching, or deciding during a meeting, that person should quietly leave.
• Same Bat Time: the team starts on the universal clock, regardless of who is or isn’t present.
• Two-Hour Limit: the maximum length of a meeting is two hours, with a 10-minute break in the middle.

These five practices together amount to a pretty tight set of constraints, which is very much the idea: over and over you’ll find organizations that waste countless thousands of hours a year in useless and non-productive meetings.

Buy-In Is Easy…

Me, Watching Some Boring Guy At A Meeting

The gist of the meeting discipline concept is that meetings are extremely expensive, therefore we need both to reduce their quantity and increase their quality. This is an easy sell: there tends to be a near universal agreement that meetings are a problem.

I usually introduce the idea at the largest possible meeting, specifically so that it’s more likely senior bosses are present.

As always with me, there’s a joke. Once we discuss the leave-at-will practice, people will already start to wonder whether they can really pull it off. I tell them I have a guaranteed technique they can use to leave meetings that aren’t working for them. Then I jump up, cover my mouth with both hands, and run out of the room. “Nobody ever stops a vomiter from leaving the room.”

…Actual Practice Can Be Tricky

All well and good, as long as the meetings in question aren’t  my special important meetings. It’s a rare meeting-maker who believes her own meetings are long, irrelevant, boring, and generally regarded as a waste.

This is a good place to play the temporary fiat card: for the next three iterations we’re going to adopt the meeting discipline as an absolute and unbreakable rule. At the retrospective for the third iteration, we give ourselves permission to change the agreements if we like.

Once the agreement has been made, it’s critical that we publish them up the hierarchy as far as we can. Print the agreements, plus the temporary fiat adoption of them, and go around and talk directly to every boss up the chain. Explain what you’re doing, and ask them to be tolerant or even participatory in the discipline for the three weeks.

Most will bite. Some won’t. Little to be done unless you have access and approval from their grandboss.

Modeling Is Urgent

No matter how much we know that some given meeting is going to be useless, it is extremely hard to leave or ignore a meeting called by your great-grandboss.

Here are some good modeling opportunities:

• Leave a meeting, having prepped the leader in the pre-meeting chatter.
• Hold a meeting, sort the agenda from most to least important, and have at it. If anyone leaves, thank them later.
• Be ferociously stern and controlling at standups that start to drift into problem-solving sessions. If we really need a problem-solving session, call it for immediately after standup.

The real key to all this modeling is to make sure people see you doing it. Don’t be afraid to go meta- with them about why you’re doing what you’re doing.

If You Pull Meeting Discipline Off,

They Will Love You Forever

Me, Experimenting

The Experiment

In the late seventies, the social scientist Ellen Langer performed a set of experiments about asking for small favors and receiving them.

The context is a library’s coin-operated copying machine. The subjects are people who are about to make a copy. As soon as a subject sets material onto the machine, but before the coins are inserted, an experimenter approaches. The experiment asks to go ahead of the subject, a small but real favor.

The variable in the experiment is how the experimenter asks. Here are two straightforward variants:

• Request-Only. “Excuse me, I have 5 pages. May I use the xerox machine?”
• Request+Explanation. “Excuse me, I have 5 pages. May I use the xerox machine, because I’m in a rush?”

Take a second to mull this one over. Will adding that little explanation — a lightweight but real one, a justification for the favor — work more effectively than just the bare request?

Does Request+Explanation Work Better?

I’m betting most of you say Request+Explanation does better, and you’re right.

Request-Only results in compliance 60% of the time, and Request+Because results in compliance 93% of the time. That’s quite a difference, isn’t it?

The take-home lesson hardly needs stating: you’ll do better at getting compliance if you provide a simple explanation.

I hope that this is just a reminder and not a surprise to most of you.

But We Ain’t Done Yet

I cheated, as, in fact, I often do. See, there’s a third variant:

Request+Because. “Excuse me, I have 5 pages. May I use the xerox machine, because I have to make copies?”

This one’s kind of a mix of the first two. Like Request+Explanation, it has a clause that begins with the word because. On the other hand, there’s no more actual information provided than was already present in Request-Only. That because simply adds more words to describe the already obvious situation.

One could say Request+Because provides a placebo explanation. The because is there, alright, but it’s informationless. The explanation is a fake one.

So? What result? This time I expect a bit more shock and surprise.

The Request+Because success rate is 94% successful.

What’s This Mean?

When we interpret an experiment like this, there are lots of caveats we need to acknowledge. The size of the favor is very significant. The samples were not huge, and in any case selected from a very not-random set. And so on, and so on, blah-blah-blah.

Still, foolish GeePaws rush in where angels fear to tread.

People respond to the presence of an explanation as much or more than they respond to that explanation’s content.

Use A Because-Phrase,

Because Because-Phrases Work.

Yes, There I Am

I sat around a table with about a dozen people,  six weeks into a transition, and there was a particular fellow. He was, you know, that fellow.

He’d argue at great length against any new practice, how trivially stupid it was. When we decided to adopt, he would quiet down, but then he’d sabotage the practice by applying it in half-measures. He would then, in high humor, ruthlessly point out how his results were a clear indication that the practice would never work.

So, big deal, I had a fierce resister. It had happened before, and it would happen again.

No, you don’t understand. This guy had me down. His every word — every look — found and pressed one of my buttons.

Anyway, at this particular meeting, I finally leaned forward, and using my masterful coaching wiles, I said:

“Would you care to step out to the parking lot so we can discuss this further?”

It’s true. I really did challenge one of my coaching clients to a fist-fight in the parking lot.

We’ll never know who would have won, because the manager stepped in and got me out to the hallway to cool down.

I was reminded of this ridiculous episode recently on Twitter because three different coaches talked to me about episodes of losing it, all in the same day. None of them were quite the caliber of actually beating someone up. But they were still pretty serious breaches of the ol’ agile love protocol.

Every coach, sooner or later, loses it.

It’s true.

I can’t tell you when, or how. I can only guarantee you that your patience will run out, your temper heat up, and you’ll behave in a way which is not only wildly improper and possibly illegal, but — and this is the best part — also entirely visible to the public for miles around.

Everybody does it eventually.

If you coach for long enough with enough teams, it will happen to you someday, too.

Dealing With Having Lost It

In another context, I once called Ron Jeffries to tell him about a coaching situation that had me in tears. (There was no violence involved that time, I swear it.)

Now, not everyone sees Ron as a sweet and tender sort of guy, but his reaction in this case was wonderful. He said three things:

• There, There. You know what? You’re going to live through it. It will be alright.
• Get Some Rest. Go home, turn off the alarm, and get a good night’s rest.
• I Trust You. Once you are well-rested, decide what to do, then carry on.

How’s that for masterful kindness?

You Know Who You Are

I’m certainly not going to call out my friends who recently lost it at a team meeting. As it is, the embarrassment is practically fatal.

By all means, apologize when needed, but not only should you not beat your clients up, you shouldn’t beat your self up, either. Life goes on.

So if you’ve lost it recently, then take Ron’s advice, and take heart.

And If you haven’t lost it yet, then print this out for later..

Important Notice To Future Clients:

I Never Try To Beat People Up Any More

(but I still think I could take him)

Some are quite minor, a moment’s brain-fart, some mis-typed code, forgetting an obvious factor and being reminded, typically by everyone on the team. Today I want to talk about these minor ones.

As coaches we deal with mistakes through a combination of situating, inviting, and modeling.

By way of situating, push the judgment principle to the forefront, early and often.

Judgment Principle:

We Completely Irrevocably And Happily

Rely On Individual Judgment

The judgment principle is one of the strongest concepts the agile world has going for it.

Most methodologies describe software development as basically a machine where you put requirements in at one end, turn the crank for a while, and get software out the other.

The agile family development models are the first I know of to actually include living, breathing, occasionally mistake-making human beings in their process.

This is an epic win, so step up and say it loud.

Mistake-Responses Are A Kind Of Inviting

Many teams carry around a huge lead weight called Get-It-Right-The-First-Time. This ludicrous idea is still endemic in our business.

(Why ludicrous? Because we have shown over and over again for fifty years that it presents an unachievable goal. Basing real practice on unreal beliefs is ludicrous.)

“Make it, fix it, keep moving,” is much more attractive for most people than “Oh my God, you forgot to think of everything”.

Think about this for a second. If most teams are too tense about making mistakes, but your team is okay with them, you have created a better party, which is the essence of inviting.

Modeling Mistake-Making Is Key

Responding well to other’s mistakes is certainly significant, but modeling the actual mistake-making is even more powerful and convincing.

As a coach, you need to understand early on whether Get-It-Right-The-First-Time is hurting your team, and take effective action at once.

Modeling is far and away our strongest game-changer: So, make a mistake.  Acknowledge it, without justifying or excusing it, have a laugh, and keep moving.

The (Good Looking) Author

A joke will help.

I often remind teams that I myself mostly get by on my fabulous good looks, not so much the brain. For some reason, they think that’s funny.

Check Yourself, Sisters and Brothers

Coaching minor mistakes is almost easy. I say almost because I know that some people, including some of you, have an extremely hard time making mistakes.

Check yourself on this.

If you see that you’re not really able to handle your own mistakes, then get some practice. Try it in a safe place, like with your close friend or significant other. Tell them what you’re doing, and why. They’ll help. I guarantee it.

If You Yourself Fear Making Mistakes,

You Won’t Help Anyone Else.

Low S/N Ratio

There are some concepts in coaching that come up over and over, especially when you’re coaching noob teams. The notion of signal to noise ratio (S/N) is one of these.

Signal-to-noise ratio is a way to describe some channel of information into the team (or out of it, or both). For that channel, s/n is an assessment that compares the channel’s signal, i.e. useful information, to its noise, i.e. corrupted or useless information. The bigger the ratio, the better the channel is, and vice versa.

We don’t need any further technicalities: our sense of s/n in human channels is always a matter of judgment and approximation anyway.

Testers Have This Notion

Testers already use this concept all the time, under a different wording: false positives and negatives.

A false positive test is a test that says the program is okay when it isn’t. A false negative test is a test that says the program is broken when it isn’t. Testers regard either of these false tests as anathema, to be repaired or removed from their testing scheme ASAP.

Why do this? Ahhh, because a false positive (or negative) is noise. If they get enough noise in that channel (which is not very much), they will start losing track of tests that are true. Once that happens, the testing system becomes increasingly useless as an indicator of quality.

Developers Have This Notion

Developers know the idea, too. If they don’t think so, just remind them by discussing compiler warnings. Most teams use a warning setting of level 4 out of 5, or something similar. Ask them why they don’t crank it up all the way?

If your team is well-behaved and already keeps warnings at level 5 and fixes all warnings before check-in, then just ask them why they bother: they’ll explain s/n to you.

Some teams ignore all warnings all the time. They have implicitly decided that there’s little or no signal in warnings. (If they’re using meta-template programming in c++, they may well be correct.)

Why Coach This Topic?

What’s important about this idea is that it’s simple, it’s intuitively valid, the team is familiar with it, and most of all, it has a gazillion applications all over the agile process map:

• Compiler warnings, as noted;
• Intermittent test failures, as noted;
• Meetings longer than an hour;
• Evil evil evil boilerplate commenting schemes;
• Every-other-line commenting;
• Reports that show way more data than needed;
• Poor presentation skill;
• Team-member mis-communications;
• Results of some QA efforts;
• Staff meetings;

Everyone of these is likely to be a site where the signal-to-noise concept can help explain the desired improvements.

Delicacy

You don’t even have to be very rough about this stuff, usually.

After a ludicrous staff meeting, ask the boss what parts of it she considered most important. You’ll be surprised at how easy it is for people to tell you the important part of what they heard or said.

Naturally, the important part is just another synonym of signal.

Save Yourself Heartache

Coach Signal-to-Noise Early and Often

They Will Thank You

“Well, we had to drag him kicking and screaming to the first lesson, but now he wants to go twice a day.”

(Dragged kicking and screaming seems like a lovely metaphor until you encounter your first enraged 3 year old. Dragging a child who is kicking and screaming from point A to point B is no figure of speech, though it could be considered a ‘presentation’, since it usually occurs in a public venue.)

Anyway, I hijacked the phrase, and I teach it to my teams and use it as a kind of coded language.

It means that we resisted breaking a rule for as long as we thought wise, but finally decided to break that rule openly and explicitly.

Sometimes We Break Agreements

Moses Laying Down The Law

Sometimes, we even break methodology rules, which are often considered more sacred than team agreements! But if you puzzle for a minute, you’ll realize that methodology rules are really just team agreements anyway.

Here’s a sample methodology rule: “We always split a story so that its parts preserve business value.” Here’s a team agreement: “We always reserve the big name changes until after 5 pm so most of us are safely checked in.” Not much difference, really.

Anyway, breaking one of these from time to time is both normal and healthy for teams.

It can be a way of pressing to find limits, places where the existing agreement doesn’t work. Often enough, we even discover new agreements while breaking or re-negotiating our existing ones.

In fact, a team that never breaks a rule is likely to be a team that is significantly slower to adapt and rise to meet the changing demands of a marketplace.

Breaking Rules Carries Two Risks

First, breaking a rule carries the obvious risk of just plain not-working-out. The team is not entirely stupid, nor is the methodology, and these agreements are usually made for a reason. This kind of risk is easy to see, examine, and recover from, if we talk about it.

The other risk is far more subtle and dangerous.

“Chiefly Honored In The Breach”

Have you ever seen a team that inherited one of those massive 200 page coding standard documents from the 80’s, but entirely ignored that standard all the time?

One could say that the coding standard agreement is chiefly honored in the breach, which is just high-falutin’ talk for “ignored”.

Ignored agreements can be deeply damaging to a team. If rule #21 can be quietly ignored, why not #4? Why not ignore any rule at all, if it suits a developer to ignore it?

Yikes. Teams live or die by their agreements. In fact, over and above the question of a rule’s actual efficacy, the set of team rules is a large part of that team’s self-definition.

Casually undermine identity, and your team will turn to mush.

And Yet, Sometimes We Break Agreements

So.  We’re damned if we follow team or methodology rules too rigorously, and we’re damned if we just quietly ignore them.

The trick then, is hidden in that word quietly. What if we went ahead and broke a rule from time to time, but never break a rule quietly?

Dragged Kicking and Screaming

To say that we are dragged kicking and screaming is to say that we did our best to follow that rule, but finally decided we had to break it, explicitly.

Harking back to our methodology rule above, if a team couldn’t split a too-large story so that it still provided business value, they would say “we were dragged kicking and screaming, and we wound up splitting it arbitrarily just so it had the right size”.

Development Can Not Be Rule-Driven

It’s astonishing to me how many folks think that all you need is some peon/typists and some very strict rules to develop software.

But that’s not how it works.

Break Your Next Rule Kicking And Screaming.

You’ll Improve the Rule AND the Team.

public int DoSomethingMessy()
{
    // ...horrific 15 indents and 300 lines of code...
                    MessyThing messy = Frustrator.staticMethod();
                    if(messy.requiresValidator())
                    {
                         doThis();
                    }
                    else
                    {
                          doThat();
                    }
                    // ... much further logic based on messy's values
    //...blah-blah-blah more tons of code
}

I’ll be pairing, with the target of bringing some or all of DoSomethingMessy under test. When I notice Frustrator and its annoying static method, I quickly choose and use one of the hacks to get around static calls.

It’s at this point that my pair wants to ctrl-click Frustrator and go see what it does on its way to creating a MessyThing object. Her logic is simple: if we don’t know how Frustrator loads a MessyThing, we won’t be able to simulate it correctly.

<CLICK> The knowing trap closes around her, all unawares. It’s time to coach not knowing.

The Not-Knowing Master

Is it necessary to know how Frustrator loads a MessyThing in order to test the extended logic that occurs after the call? Absolutely not. We can set the values we want based on that extended logic itself: if the calling logic uses messy.requiresValidator(), say, then sure enough, we need to test using both possible values, and so on.

On the other hand, is it expensive to know how Frustrator loads a MessyThing? Usually, yes indeed. As a general rule in legacy, you can bet on ctrl-clicking for hours as you read the code from Frustrator, AnnoyMatic, StinkingInconvenient, and GoodLordThisIsReallyStupid.

This is not knowing.  A developer working in deep legacy has to master the art of knowing just exactly the right amount, and refusing to be distracted by the rest.

Coaching ‘Not Knowing’

Is Key For Deep Legacy Work