Looking at TDD through a lean-agile lens

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.
Continue reading

Where Agile goes to die

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.

Continue reading

What’s the problem with “What’s the problem with Scrum?”

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.

Continue reading

Choosing an Agile Scaling Framework

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.

Beyond resistance

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.

Continue reading

Take a walk in the desert

No one can see their reflection in running water.
It is only in still water that we can see. (Lao Tzu)

A friend of mine was telling me about the new apartment he and his family have bought. The building is under construction, and is located in a prestigious part of a major city. We got into a discussion about choosing where to live. He prefers large cities, and I prefer living far from a city (although I work in cities).
Continue reading

Should coaching be treated as hourly contract labor?

Often, companies try to balance staffing with the natural variability in IT workload by engaging contract workers. They don’t want to make a long-term employment commitment to the number of people required to handle their maximum workload. So, they hire enough full-time employees to handle their typical workload, and in periods when the workload is higher they bring in temporary workers on a contract basis. That way, companies can expand and contract staff to match the internal demand for IT services.

Problems occur when the parameters of the temporary staffing engagement are at odds with the nature of the work performed. Because “coaching” has not been a well-understood category of services, it has more-or-less accidentally fallen into the “hourly contract” mode. Is this appropriate? Does this model cause difficulties for any of the three constituencies that have an interest in it: The clients, the workers, and the middlemen?

Continue reading