I posted this yesterday to the extremeprogramming mailing list, newly risen on groups.io. Edits to the quote here are in [square brackets].

A thing that I think I’m observing more and more frequently, among the coaches I hear from, is a focus on a few practices that are sufficient in some particular near-perfect situation, perhaps the one they’ve helped to create wherever they are. [These coaches often deprecate other well-known practices which they’ve found not to be needed in their situations. That concerns me.]

There are many different relationships with “the business”, the “product owner”, the “customer”. There are many different levels of sharing of code, and of concerns. There are teams who are just beginning, teams who really have it in hand, and teams who used to have it in hand and are now a bit stale.

There are many forces that act upon us and among us as we work together to get things done.

Practices, such as pairing, mobbing, TDDing, micro-mini-macro-testing, stand ups, sprints, kanban boards … it goes on and on … practices are devised, not just to solve some particular problem, but to make a space for good things to happen. In addition, they are devised to be used by teams who do not have the luxury of having one of these excellent coaches with them.

The excellent coach, like some Aikido master, might just hold his hand just so and things get better. Us normal people, in the same situation, are more likely to trip over each other and fall down. Practices, like the stand up, create a space, with a certain ambiance, within which good things have a chance to happen. Teams are encouraged to adjust how they do that practice, before just dropping it, and the point of those adjustments is to move around in the space to give the good things a better chance.

So I believe[, for example,] that Woody [Zuill]’s mobbing groups may not need stand ups. I also believe that Woody does 15 kinds of magic that he’s not even aware of, as do the other people in the mob, and it [may well be] one of those tens of things, or five of them in association, that’s making the stand up unnecessary.

The upshot of this is that just as no decent coach would likely ever say “THIS PRACTICE IS MANDATORY”, it’s probably not desirable to come out too strongly against practices just because we no longer use them ourselves.

I want to emphasize this thought from above:

practices are devised, not just to solve some particular problem, but to make a space for good things to happen.

Example: Daily Scrum (stand up)

In Scrum, for example, the “Daily Scrum” is an opportunity for the dev team to look over the Sprint as a whole, and to think about how they’re doing against the Sprint Goal. The Sprint Goal, ideally, isn’t “get these ten things done”, but instead is a more abstract yet more valuable goal, such as “get credit card handling figured out and at least one flow implemented”. The specific backlog items should add up to that goal, but it’s the goal that is important, not the specific items.

The Daily Scrum is unfortunately often boiled down to the infamous “questions three”, What did I get done yesterday, What will I do today, What is standing in my way. These don’t really address the meeting’s purpose very well, though they are often the best that a newish team can do.

As time goes on, a team may – indeed should – find these questions boring and useless. One possible response is to stop holding the Daily Scrum. A better response might be to change what is being talked about, rising above nitty-gritty details on most days, and looking ahead to see how we’re doing.

The Daily Scrum provides a space, a moment in time, for the team to make a valuble assessment of how things are going. It is possible that some teams do not need that opportunity. It’s very unlikely that no team needs that opportunity, even a team doing some other wonderful practice like mobbing.

So I’d be against advocating against the Daily Scrum. I’d be more in favor of discussing various needs it might fill, and other ways that some of those might be filled. I’d like to leave use of the Daily Scrum as a well-known, respected practice that’s worth having near the top of one’s bag of tricks.

Bag of Tricks

I remember Kent Beck talking with us about the programmer’s “bag of tricks”, the various tools and techniques that a developer learns and squrrels away as they gain experience. Kent advised that a deep bag of tricks is worth having, because sometimes you really need something pretty deep down in there, but that most often, the really good developer uses tricks that are pretty close to the top of the bag.

That’s what makes the code of a great developer easy to follow, understand, and change: their code is mostly created using approaches that amost every developer knows and understands. Only rarely will we run across something clever, or some approach that we didn’t know. (And, of course, the great developer manages to make even things we’ve never seen before clear and understandable.)

I think the practices of Agile teams and Agile coaches are like that. They are a bag of ideas, notions, techniques, moves, that ideally serve at least two purposes. On the one hand, they address some specific need. But they almost always do more

Example: Pair Programming

We pair program because it delivers better code as fast or faster than not pairing. But pairing also moves information and ideas through the team more rapidly than people working alone. You might have five good ideas working alone, and remember to share two of them at lunch with whoever you happen to have lunch with. When you’re pairing, at least one person hears all those ideas, and they’re at least twice as likely to be shared.

Pairing is a space, a period of time, in which two people’s ideas merge, share, and build upon each other. That value, over time, is quite likely more important than the somewhat better code we get from pairing.

Example: Customer / Acceptance Tests

TDD is a very powerful family of ideas. We probably only know and understand half of them, even today, 20 years after it first began to become popular. In the hands of an expert, a system built with TDD can give great confidence that the software we’ve built is the software we want.

More than one TDD expert has come out, more or less strongly, against what XP calls “Customer Tests”, also often called Acceptance Tests, and referred to often in ATDD, by analogy with TDD. (Behavior-Driven Development is a cousin to these ideas, partaking of both TDD and ATDD ideas. (As I understand things.))

Now in a sufficiently high level language, it is possible to code up some capability using TDD, then sit down with business-side people, walk them through the tests and code, and give them the same confidence that the TDD expert has. Notice that there are some qualifications there. But wait, there’s more.

I’ve personally never seen a perfectly TDD’d system, and I’ve seen Customer Tests on real systems find defects that the TDD tests did not find. (The done thing, of course, is to figure out what TDDing was missed out, and do it, because we prefer the TDD tests to find things first.)

Customer Tests are generally prepared by different people from TDD tests, and they are generally more focused on the large-scale aspects of the application, while TDD tests are mostly – but not entirely – down in the details. This means that Customer Tests or ATDD provide a second set of eyes on what the application should do, and on what it does do. Just as double-entry book-keeping helps avoid accounting errors, this double entry testing can help to avoid specification, communication, and programming errors.

I mentioned communication. Quite often, the business-side “Customer” or “Product Owner” thinks they know exactly what they want, and thinks they tell the developers exactly what they want, and the developers think they understand exactly what they were told. And quite often, that turns out not to be the case: there’s slippage all along that path.

Customer Tests are concrete examples of “given this, the system does that”, with inputs and outputs specified in detail. Creating those examples as part of the process of moving from idea to solution often brings a concrete clarity to things, and can reduce the “he said she said” friction to nearly zero. We agreed on this test. It runs or it doesn’t. If it runs, that’s done. Don’t like the situation? Fix that test or provide a new one as needed.

Customer tests provide a space for clear communication, in a concrete form that’s hard to misunderstand. It can do that even with Customers who haven’t the time or ability to review the code, or in systems whose code is too obscure for mere humans to grasp. In addition, those tests provide a second safety net ensuring that the product does what is needed.

I’m advocating against advocating against this kind of test, even though I personally use them rarely. Why? Because they are sometimes useful, sometimes almost critical. So I’d prefer to see experts proceed carefully, either saying as clearly as they can when they would or would not use Customer Tests, or at least observing that in their situation such tests are not needed, for the following reasons.

We Did This And Survived

There are a number of blogs, emails, and talks that seem to come down to an argument like this:

I don’t wear a helmet, and I drive my cycle incredibly fast, and I crashed into an abutment and was run over by a train, and I lived. Therefore helmets are not useful.

Many projects deliver successfully against all odds, and using all kinds of approaches, using or avoiding any technique you can imagine. “We Did This And Survived” is not a recommendation for “This”. It might be something to think about.

Be careful what you advocate. Be even more careful what you advocate against.