Your question seems to suggest that TDD is bound by development life cycles. I’m not sure I agree.

The answer to flexible, changing requirements is iterative development. TDD has nothing to say about this, or about software schedules; it is a tool for developing software within whatever requirements and schedule you do have. If the requirements change, so does the software. This goes for the unit tests as well.

TDD does not develop requirements, even though some proponents suggest that it does. Rather, the requirements drive the units tests, which in turn drives the code that is written. You don’t grow an architecture from tests, nor do you develop requirements with tests. Instead, the tests are an outcome of the designated architecture and requirements.

If requirements are changing at the atomic (method/unit test) level of software development, then I would suggest that your requirements are too granular. Requirements should specify what the software does, not how it does it. How the software meets the requirements is the domain and responsibility of the software developers, not the principal stakeholders.

To put it another way, I don’t tell the customer or business owner how to run his company, and he doesn’t tell me how to design my classes.

Changing requirements are a normal thing, but when they are changing on a daily basis and changing the requirements in the middle of a sprint then this is not an environment conducive to software being developed in any meaningful and qualitative way. In other words, TDD is the least of your problems here, they are more fundamental.

You mention sprints, meaning that you are performing some kind of Agile development, which is a good thing. Handling development in short quick sprints works well on projects for when priorities and requirements are volatile and could change in the middle of the project. The serious issue is that you have requirements drastically changing on your development and test teams in the middle of a sprint.

The sprint priorities should not change once the sprint has started. The sprint is supposed to be an agreement between the stakeholders and the development team that the following agreed upon features and user stories will be delivered and tested by a specific date. The stakeholders do not uphold their end of the agreement when they start changing their expectations for the sprint after development has begun.

So the stakeholders weren’t being careful or thoughtful of what they were asking for, so they will change their expectations immediately. Do the developers then have the luxury of pushing the delivery date for the features? Often not. At best the stakeholders were being negligent or incompetent and the developers pay the price in overtime to meet the date anyway. Sometimes even the stakeholders do this purposely knowing that they can get more work out of their salaried developers.

What should honestly happen when the core requirements change to the point where the current work for the sprint would be useless is to immediately halt sprint development until a new sprint can be planned based on the new requirements. There is certainly no reason to continue on for the next week and a half developing software that the business has already told you that would not in anyway be useful to them at all.

What is happening really is that the business stakeholders are failing the development team by not maintaining or meeting the sprint commitment. They demonstrate either complete lack of competence in determining what they want in software or they have a complete lack of respect for the development team and how quality software is produced.

The only way that business groups like this earn a respect for how software development really works is to hire an outside consultant company or software vendor to develop software for them and pay by sprint. Once they lose money on a few sprints worth of development that they cannot use then they will start to gain an appreciation with how important it is to maintain their commitment as stakeholders and be very careful and specific with their features and requirements.

Without getting into specific agile terminology, it looks like the fundamental problem is a lack of understanding and/or commitment to the client’s responsibility during an iteration: once the set of implementable items is chosen (by the client, agreed to by devs) for an iteration, the client agrees not to change their mind until the end of the iteration.

This gives the devs a stationary target for a short time.

If the requirements are so unstable that they cannot survive a day alone, the project has problems far beyond the methodology… In that case, step back to the goals of the project, and reconsider the proposed features.

I don’t think the rest of the business is going to help because they have no sense of development life cycles, and requirements get changed all the time within a single sprint.

One thing that business generally listens to is anything that has an impact on the budget. If constantly changing requirements is being done frivolously, then you will want to create an argument with detailed examples to show how such change impacts team efficiency, creates overlapping work, and costs the company money. If on the other hand, the changes are necessary and could result in a loss to the company if not done, then you may simply need to wear it, and find a way to deal with constantly changing requirements.

It’s been my experience however, that when things are changing at such a high rate as you have suggested, it may be for the following reasons:

• The concept is experimental, in which case you may wish to be spiking all of these changes rather than implementing them directly into production code.
• The concept has not been thoroughly analysed, which suggests that the product hasn’t really been thought through and the requirement is to code the product while it is being thought up.
• Constant market and competitive pressures result in knee-jerk change
• A poor relationship between project drivers, managers, and the implementation team, in terms of the ability for all of the stakeholders to communicate freely about the need for change.
• Poor prioritization of tasks, and this can be a fault of both management and implementation staff.

Sometimes project owners don’t really know how the product is supposed to work, because they have a basic concept in mind, however they feel they need to see how it works first before making up their minds. This can be because the problem domain isn’t very well understood, or because they haven’t really thought about how a business function will translate into a software-based solution. Prototyping can be beneficial in such cases. You can easily prototype GUIs with mock objects if the changes are cosmetic, or you can use unit tests as a means to test and tune changes that are algorithmic. The key though is to ensure that changes are applied as systematically as possible, in order to keep the process relatively lean and less costly.

We have suggested setting up processes to dodge those requirement changes and educate the business about development life cycles.

This is a good start and allows you a means to engage with management to try and effect positive outcomes in a measured and structured manner. Education is the most effective method for dealing with problems where developers and management are out of sync ideologically. However, in order to get the greatest benefit, the education needs to be two-way, as does the communication. You need to teach yourselves and management to communicate your needs, and to help each other to understand the motivations which drive those needs. Saying that it’s “too hard” or “a lot of work” or “a time waster” will only come across as complaining and being “lazy”. Your reasoning needs to be clear, and in a language that will show that you are working to achieve positive outcomes for the company and the product you are working on, and that your motives are with these best interests in mind. Likewise, you may need to learn to accept the reasons that the suits give you for why they feel the need to change things so rapidly. Perhaps between you you will be able to find a good workable middle ground when both sides are able to understand each other’s point of view.

What if the business fails to get the idea? What would you do?

If you don’t achieve the outcome you are hoping for, perhaps the timing isn’t right. Perhaps your arguments need to be made differently. Perhaps you have it all wrong and need to learn more about what the other side is thinking. Ultimately if your particular approach fails, it’s up to you to decide how important it is to you to have dealt with. However, rather than concern yourself with what may or may not happen, think positively and simply decide what you can do about today. Tomorrow’s problems aren’t necessarily guaranteed and not worth the stress of worrying about until they actually occur.

One final point to consider. Your CTO is possibly concerned about many of the same problems that you are. Certainly having a decree to adopt TDD suggests to me that this may very well be the case given that TDD is highly effective in situations where the code is often subject to change. In a test-first scenario, tests don’t become useless the next day because the provide you with a safety net to work within, allowing you to apply changes rapidly and confidently. However, you will still need to find a way to manage the expectations of the people requesting changes in order to help to manage change efficiently.

To make it more clear, a requirement requires the site to be able to
upload an image and resize to below 500kb if actual size is over
500kb.

Requirement change might be this feature is not needed (most of the
time is after they have seen it, they realized they don’t actually
need it)

We have suggested setting up processes to dodge those requirement
changes and educate the business about development life cycles. What
if the business fails to get the idea?

First, it sounds like you might need to do more dummy prototyping. Meaning working, clickable mockups who don’t actually store or retrieve any real data, but who emulate what the software would behave like. So for webapps, this would mean fully done HTML/CSS/JavaScript that lets user ‘click through’ the software, even though you have very little coding done. Perhaps that can help users see what it is they are asking for before you invest the work in coding it up.

Next, its really not up to the IT department to decide how the business does it’s work. And it could be that the business values nimbleness over reliability for its software needs. So getting something changed TODAY is more valuable that making sure a given feature works 100% of the time, as opposed to 95.5% of the time. Only the business itself can decide this. Unless your department is getting slammed for quality issues, perhaps you should consider that the business is totally OK with shifting requirements and non-test-driven code. Your CTO/CIO says he wants you to be “test-driven”, but if the business requirements are routinely “get this change done by 4pm” then you just can’t have both.