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.
