Why Agile Transitions Fail?

Why do Scrum transitions fail? A wise man who sold Jell-O once said, "In order to succeed, your desire for success should be greater than your fear of failure.
" Yes, this man was comedian and well known actor, Bill Cosby, and he certainly had a great point.
This type of desire is imperative for success, but isn't the knowledge of how not to fail, just as essential? It is definitely the case when it comes to Scrum transitions.
As humans tend to be creatures of habit, patterns begin to form from one agile transition to another.

Some of these patterns are healthy and others if left unspotted can most assuredly lead to failure.

The following are five patterns those making a Scrum transition should familiarize themselves with.
Pattern 1: The corporate cultural shift has not fully occurred yet. The organization needs to start moving from its command-and-control type behavior to instead embracing it's required, supportive role. Also, from getting swept up in politics and covering it's ass(ets) to one of trust and cooperation.

Now, Scrum does not expect everyone to join hands together and sing Kumbaya, but it does require a steadfast commitment. A commitment to the values that will harness trust within an organization, such as: RESPECT, FOCUS, COURAGE, OPENNESS, COMMITMENT Pattern 2: Agile is deployed without any consideration for the different areas and the dependencies between them. This will then block teams forward mobility.

Therefore, it is critical that every deployment require both an outlined engagement model and an Agile delivery model. Such information helps both clarify and reinforce, to teams, how they will interact with other areas and what will be expected of them while sprinting. For instance, deciding upfront who will be participating, such as QA, and what sort of testing they will be doing inside a sprint is valuable to the entire team. Other possible examples could translate to Architecture or Design.

As you can see, in order to achieve success, it is key that interactions and dependencies between departments must be understood to obtain the workflow. Pattern 3: A project that is in progress, or a high risk project is selected to go Scrum. Commitment to the success of the Agile framework waivers due to project priorities and timelines.

Issues keep creeping up because this project has just been flipped 180 degrees and Scrum is blamed for its failure.
Allow those projects in progress to complete the way they started because going agile in the middle will not solve its issues. Select an ideal pilot project, one that has not started.
You could call it a clean slate really.
Some of the characteristics of an ideal project to apply Scrum to would be: One with a duration of approximately four months, one team will be required, and one with high value and low risk.

Pattern 4: Senior Management continues to request business requirements (BRD's) and timelines.
Once again, this is due to lack of understanding of what it takes to be Agile.

Business requirements are written in the form of User Stories and timelines are not set in Scrum. While Agile release planning is practiced it is not necessarily a Scrum practice. Consistency here is required to keep teams, management, and executives all on the same page. Pattern 5: The lack of Business presence or commitment becomes a project risk.
This could be due to volume of work or disinterest. In either case, it is a serious risk.

They understand the customer and own the organizations' vision, only they can explain requirements.

While Agile is customer focus and helps align Business to IT, it requires commitment.

Looking for signs of these negative patterns in Scrum transition, finding them early, and fixing them is definitely the next giant step in the right direction.
Why fail due to the more easily remedied issues, when already headed the right way? After all, the first step towards success was transitioning to Scrum to begin with.
Pave the way!