Agile in a CMMI/Rigid Systems Engineering Process World

In a recent project, as a member of a large bureaucracy, I've had to deal with being held to a rigid systems engineering (SE) process. The whole nine yards, OCD, SRD, SFS, SRS, IRSs, the documentation list goes on and on.

SE Process can be a very good thing when implemented properly. My problem was that my team was being held to a higher standard than our customers and was being held there by the sponsors (an anonymous PMA).

So on one hand we had to adhere to strict documentation and review cycles but at the same time we weren't getting spelled out requirements. We were getting the requirements in an Interface Design Specification (IDS) and were being told that the IDS represented complete requirements along with a PPS and User's Manual. Can't tell you what the project was but suffice it to say, it was massive.

In addition to all this, the schedules were compressed and money was tight as usual.

Question: How do you implement a more Agile approach when your neck deep in process and in a compressed schedule with limited budget?

My solution: slowly reduce the documentation within your own process and push back on requirements and hope the PMA doesn't tell you to just get it done anyway and then start looking to blame you when the project gets into trouble, even though it was their fault for not listening to you to begin with.

Jon: I know for a fact you've dealt with this before...any advice?

Proposed next topic: "Agile-CMMI" It can be done but they seem to be at odds with "Working software over comprehensive documentation"

Hmmm. Tough situation for sure. Frustrating I bet, too. One idea... bring it up to the powers that be... See if there truly is a desire to succeed, or a desire to follow process regardless of actual success.

Another idea: make all of the tasks visible and blessed by the stakeholders. Make it clear as to what they are asking for and how much it costs.

And, be sure to check that you are doing truly useful documentation to the proper level to allow the team to do their best. But for "make work" documentation, try to get away with the bare minimum.