Kanban in traditional environments

I was reading this article in Forbes, that created a lot of etraffic:
http://www.forbes.com/sites/stevedenning/2012/09/25/what-exactly-is-agile-is-kanban-agile/
It is an interesting point of view and I can't say he is completely wrong or completely right. I like the comments a lot, because you can see how some of the Agile community members responded or tried to clarify some areas.
I was trying to figure out how Kanban is helping my current company to move to Agile.
No longer than today, while I was on a meeting with one of the teams I am coaching, I heard ideas like: We can consider a feature done when developers are done, since testing env. has issues. Or the need for consistency on how teams function and consistency on roles on all projects. I know some other project teams decided to cancel daily standups in front of the board when they were in the last sprint to release a project that was running late.

This reminded me the point this article was pushing when saying that "...Kanban is a set of practices that can be implemented even with traditional culture of command-and-control hierarchical bureaucracy.  It doesn’t necessarily challenge the existing culture. It can work within the existing culture, whatever it happens to be."

If I had chosen to agree with the solutions my team was trying to have, would I still be implementing Kanban with them?
Well... the work will continue to be visualized.  WIP will somehow still be limited for developers, and will be 0 for testers. Throughput will be split between dev throughput + test throughput + defect fixing throughput. For a traditional leader, this would be ok. The reports on the project status would probably be something like:
"Developers are progressing well and 80% of the work is done. Waiting for the testing to start when the env. is ready for us. Business is being kept in loop and they are ok with the current design and flow. There is a problem with the testing env. but we are trying to start testing 1 month before release in order to have time for defect fixing, business verification and deployment to production. The project is Yellow"

But would that be ok for a Kanban leader? The report would be something like:
"Developers are working and there is a big QA debt created. Due to the fact that the testing env. is not setup, none of features done by developers is tested, not even smoke test. The team was supposed to deliver 1 feature/week and we are already week 6 with 0 delivered. Business is giving feedback based on mock ups from designers and not the work done. We hope the design will not face issues when developers will start working on it, since we don't have a design B to fall back. Since this is a new team working together, we do not have historical data on the return-of defects per feature. This means we can't predict the amount of defects we will face when testing will start. Testing is not automated so it is expected to be slow. We will be asking Business to work closer with us while we start testing and prioritize defects. Do not have their commitment on this yet....Project is bright Red"

So, although I can see how Kanban can be used in a traditional company, I don't think it can be successful if the people that read the reports will continue to read traditional status reports. It can't be successful until people measure Success in a traditional way. It will be just another case where traditional leaders will expect to "be Agile, deliver earlier and cheaper" but, when will face the need for "Business to be involved frequently, testing should start early, developers should not pile the work done", they will call it "yet another failed Agile project".