Bringing Agile to Large Companies - Purist vs Pragmatist

The thread started with Barb Vandenberg's "Agile for Big Companies" video where she shared her insights as Scrum certified Business analyst. 

René (last name withheld for member anonymity) replied:

I really like that there is a company like NVISIA. I do not fully agree with what Barb is saying in the video though. Yes, you can plan the production of documents or other company wide process deliverables within your Sprints, but the culpritt is that it hampers being Agile. Big waterfall oriented companies tend to have first a 'complete' set of requirements before they even think of doing the development. But Agile is about embracing the fact that life is not perfect and while you strife for perfection your vision about the product is improved cyclically each Sprint at least. 

So having design and test documents at the end of the Sprint is fine as long as its the last step you're doing for your product and based on the latest agreed upon version (demo!) , but the requirements phase must not be that strict anymore. This part must be a collaborative and interactive process. If need be, you can also write down a requirements document as the last step before your product delivery as a kind of reverse engineering.

Paul commented:

Amazingly valuable insights in this video. This really drives the point home how you can become really agile, leaving everything inhibiting it intact. 
I love it!

I commented:

As you probably know it is a challenge to "move the needle" toward Agile in a large company. Barb's insights come from 16 years of moving waterfall development organizations forward from the dark ages. We were a IBM/Rational Software partner for many years, bringing large organizations to the world of risk managed, iterative and incremental development ala RUP and we learned a lot about taking (bold) baby steps. For the last 10 years we shifted toward agile and Scrum. Sort of like the architectural facade pattern, where from the stakeholders point of view the changes were fairly minor, while within the development team, the changes were much more significant. 

Organizational change takes some patience and pragmatism. Taking a purist stance, expecting the entire business to adopt the Agile manifesto usually ends up in a prolonged political struggle where nothing is accomplished. So it is usually a good idea to build critical mass within the development team, while bridging the initial gaps to your incumbent "M"ethodolgy milestones and gates. It's not ideal. It's not the most efficient. ..., but it will probably work. 

By the time the rest of the organization realizes that you are moving to agile, your results are starting to speak for themselves. They will realize that Agile is not a gimmick or the flavor of the day, but something that has improved the development teams results. 

I will ask Barb to review this thread and post a response on her blog.