Single Minute Exchange of Die or how to counter "this will not work"

Just learned some details about the software development process of a big german enterprise. They have a 4 month iteration cycle, where any project has to run through several (3-4) of these iterations from idea to live. Thus an ideas takes something around 12 to 16 month to go live. And only one iteration is actually working on the code. The others are analysis, specification and testing and deployment. Then (hopefully) every 4 month the whole system consisting of a lot of components will be deployed.

Thinkng about this situation I wonderd how it would be like, to try to convince the responsible people to reduce this cycle time and / or decouple the components in terms of their release cycle. In this discussion I expected a lot of "This will not work" statements.

Changing an enterprises mindset to replace "this will not work" with "we currently do not know, how this can possibly work but we will give it a try" sounds like a good first challenge to take in such an organization. Especially as it felt like the middle management was not very much looking for a change in this process.
This change in langauge could bring discussions and focus more on the "how" than on the "if". Unbelievably they changed the process from three to four month just recently, which just sounds like a change into the wrong direction. Not following one of my favourite agile quotes "If it hurts, do it more often".

So how to convince a group of middle management folks to try this first step and get a change going?

That is, where I remembered the Single Minute Exchange of Die part of "just in time production" which I heard about in the context of the toyota production system. I would assume, that Shigeo Shingo experienced a lot of "this will not work", when he proposed his idea of changing a process that usually took hours or days to only take minutes. He definitely did not know the perfect solution when he started, they changed the process iteration by iteration to make it more efficient. But they started and made it a great success.

The previously mentioned process change from three to four month iteration interval additionally indicates a batch size or complexity problem. And still it seams to be counter intuitive for many people that smaller batch sizes are more efficient. I remember reading a blog post disussing batch size in a software development context, but unfortunaltely could not remember where I read it. When searching for batch size however, I found this article very helpfull. And the type of constraints section from this page on the same site fits even better. Actually the whole site seams worth reading.

Maybe I should give Gordratts book What Is This Thing Called Theory of Constraints a try.