It’s a commonplace to say there is no “silver bullet,” and everything we do in the software field has to take context into consideration. In fact, this is quite true. TDD is a useful technique to know. To know TDD well, you must understand why and when it is useful, and how to do it correctly. If you apply TDD for the wrong reasons, in the wrong places, or in the wrong way, then it will not yield any value.
Many of the complaints people raise about TDD and about unit testing in general boil down to a misunderstanding or a misapplication of practices. Some complaints, however, are completely valid. You have to make your own professional judgments about such matters. To be equipped to make such judgments, you need to understand how TDD can add value in your work; and when it will not.
There’s something I started to notice around 2011, but didn’t quite understand until recently. Now I think I have a handle on it.
From time to time I hear agile coaches describe a particular client company as a place where agile thinking never penetrates, or where agile methods are never properly adopted. It seems as if most of the larger markets have at least one such company or governmental organization.
One (that I know of) is known in its local market as “the place where agile goes to die.” Coaches in other markets have been less poetical in their descriptions, but many of them are aware of at least one client company that has a similar local reputation.
I’m not a salesman for, or even much of an enthusiast for Scrum, and yet I keep finding myself in the position of defending it (or appearing to do so). A survey was posted a few weeks ago entitled “What’s the Problem with Scrum, and How can we Fix it?” (capitalization theirs). They’ve published the results, and so here I am again, appearing to defend Scrum.
What I’m actually defending is the idea that if we want to criticize a thing, that at least let’s criticize what the thing really is, and not a strawman version of it.
Many larger organizations are considering adopting an Agile scaling framework to help them extend contemporary practices beyond the proof-of-concept stage. Plenty of people stand ready to help them choose an appropriate framework. Or maybe it’s more accurate to say, to help them choose the framework the helper wants them to choose.
I put together a short ebook that addresses the problem of choosing a framework from the point of view of someone who has no product to sell and doesn’t care whether you use a framework at all. Maybe it will help you and maybe it won’t, but either way it’s cheap, and it doesn’t try to sell you anything. See https://leanpub.com/choosing-an-agile-scaling-framework.
As an agile/lean coach and “change agent,” I often find myself working with dozens of individuals at the same time at any given client. I’m not a great fan of “assessments,” but I do need some practical way to keep track of where everyone stands and how they tend to think and collaborate. To do that, I consider the following factors.
Do people resist change? The consensus appears to be that they do.
Well, with all that consensus floating around, I guess resistance to change must be a Thing. It’s hard to argue with a million articles that all say the same things.
On the other hand…not everyone sees it that way.