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.
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.
Different people have different ideas about the current status of the “agile” movement in software development. Different people have different ideas about what “agile” even means. Having been involved with “agile” development since 2002, I’ve had the opportunity to observe an interesting trend: We’ve been gluing a lot of things onto “agile.” Now it may be time to pry some of those things off and get back to basics.
More and more frameworks for scaling “agile” software delivery have been appearing in recent years. The proponents of each are adamant that their framework is superior to the others. Yet, customers have difficulty understanding the differences.
This is because all such frameworks are based on the same general ideas, broadly speaking. Proponents insist there are deep differences because they are all competing for the same customers.
Here is a generalized version of conversations that might occur between a salesperson and a prospect looking for help with scaling “agile” delivery.
People who’ve been in the IT field for some years tell tales of the bad old days when every project ended in a Death March. Well, actually, no one died. Truth be told, no one marched, either. But we called it a Death March. Some call it the Death March Antipattern. It was, in fact, one of the reasons people became interested in exploring alternative approaches to software development.
Younger professionals have managed to avoid the Death March Antipattern, for the most part. When oldtimers tell their tales, many of the younger folk react as if they were hearing Monty Python’s Four Yorkshiremen sketch, in which four retired gentlement reminisce about the difficulties of their youth: “There were a hundred and sixty of us living in a small shoebox in the middle of the road.” “You were lucky. We lived for three months in a brown paper bag in a septic tank.” “But you try and tell the young people today that…and they won’t believe ya’.” “Nope, nope.”
But it was real. On a typical 12-month software development project, the first ten months would be spent preparing useless documents and snoring through useless meetings. With the deadline looming, the team would scramble to get as much of the work done as possible in the remaining few weeks. It meant working 24×7 until you delivered, and then crashing for a few days. That was the Death March. And it had much in common with modern-day “agile” development practices.
Submitted for your consideration: The simplest way to solve a problem is not to solve it at all, but to define it out of existence. Many of the challenges we face in corporate IT may be caused by traditional organizational structure. If it is true that structure begets function, then we may be able to define some of these challenges out of existence by changing the organizational structure.
Daniel Mezick confronts the elephant in the “agile” room in his post, Deviation from the Norm: “If current approaches actually worked well, then by now, thousands of organizations would have reached a state of self-sustaining, “freestanding” agility. Clearly, that is not the case.”
Pondering the question, several possible reasons for this result (or lack of) occurred to me. These are speculative and based on my own experience and observations.
Premise: Agile principles depend on biologically hard-wired limits on the effective size of collaborative human groups. For this reason, agile methods as such do not scale to “enterprise” levels.