Clarifying the need for FScrum

Thanks to some great discussions on other sites, I realize that I have to clarify why I thought there was a need for something like FScrum.

Scrum is currently under the Agile Umbrella and is labelled very much an Agile Methodology. Hence in its implementation, we cannot voilate or be in conflict with the Agile Values and the Agile Principles clearly mandated by the Agile Alliance.

Therefore implemting Scrum as an Agile Methodology in a predictive (fixed scope, fixed time, fixed cost and fixed quality) plan-driven, defined process enviroment with traditional management structure (supervision and control) is a definite no-no, will be very hypocritical and treated as anti-Agile.

If we can use Scrum outside the Agile Values and Principles, in such contexts as illustrated above, and still be acceptable as in order by the Scrum Alliance, then we do not need FScrum.

However in such a scenario we may need to clearly distinguish between Agile Scrum and non-Agile Scrum. This is what I was trying to formalize and call FScrum (Formal Scrum) or Scrum for Waterfall.

Further to make this work in formal (non-agile) environments, we may need to modify Scrum Principles slightly so that it is in sync with "Waterfall" culture. Scrum Practices however (Roles, Ceremonies, Artefacts) can remain the same but "who does what and how" may need to change a little so suit a "Waterfall" environment.