If you are using agile or lean to manage your work, you are limiting work in progress. Agile limits work in progress by timeboxing--if the work doesn't fit into the timebox, you don't start it. Lean limits work in progress by limiting the number of items in any given state (started, in development, in testing, whatever).
When you limit work in progress, you give yourself a chance to finish one thing at a time. We, as human beings, are better at finishing something and going on to the next thing than we are at having many pieces underway. We miss problems with lots of work in progress. We are more likely to see problems when we finish (as well as we can) a given piece of work for now. If we have to return to it to make things better later, that's ok.
You can limit the work in progress regardless of the kind of project you have. If you are starting a serial lifecycle, explain that you want to finish the highest priority work first and then move to the next batch of work. You may have to ask the requirements people to timebox their work on requirements so you can move on to analysis and design. But even if you can't change the front of the project, there is nothing to stop you from implementing, integrating and testing as you go, once you are in development. Even in a serial lifecycle, there is no law against continuous integration!
Now, you and I both know that it's no longer a serial lifecycle if you start integrating and testing as you develop, but that's ok. Your customers, managers, and other stakeholders will be happy you did.
My experience, and I'm sure it varies from yours, is that once your stakeholders see the documents for requirements and architecture don't care much about your functional specs or other documents, such as design. Those documents are for the technical people. So if you must, start a project with a serial lifecycle, and then move into prototyping so you can understand the architecture, or, at the least, move into delivering chunks of work.
The lifecycle of "get some requirements, decide on an architecture, implement by feature, integrating and testing as you proceed" is an incremental lifecycle called staged delivery. It's a great way to limit work in progress and see your project state as you proceed. It's not strictly serial, but it works. And, isn't that what they pay us to do?
