Scrum environments: supportive, indifferent, stagnating and hostile
Great chess players say that tactics and knowledge of the game is just 1% of success while 99% comes from strategy
Same applies for many other aspects of life including Scrum.
Success, stagnation or even failure of the whole Scrum project depends not only on knowledge and experience of Scrum master, Product owner and Developers, not only on 5 Scrum values, not only on techniques used by the scrum team. Also, and mainly, it depends on how the Scrum is implemented in the whole environment where it is exercised, and how well it fits.
Scrum literature is focused mostly on the work-frame of Scrum team, only briefly mentioning that Organization should complement and support Scrum and self management of the team, while Scrum master should promote Scrum within an organization, and help PO engage the internal or external stakeholders.
Without focusing on HOW IT SHOULD BE DONE.
As a result many Scrum teams are taking the support or organization and general environment for granted. It is presumed that once there is a decision to implement scrum the whole environment around it will gladly adapt and adjust to the values and foundation of the framework for mutual benefit while Scrum master will be respected as a guru across ranks, removing barriers and helping to implement and promote Scrum.
In reality the situation is quite different and challenging. The result of taking the support of the management and organization for granted are gigabytes of complaints at social media. Those complaints made by scrum practitioners who simply cant cope with the various sabotaging and harmful actions of their employers, sponsors or whole organizations. The environment where Scrum is implemented can be often very resistant to the Scrum or whole Agile thinking; and in some cases even openly hostile. This is happening for a variety of reasons, and there can be various techniques to establish both the source of the problems and strategy to solve it-of even consider it unsolvable.
It is crystal clear that the Scrum team should be constantly aware about the state of the environment where it exists, and the reaction of this environment to scrum, which is not always positive...
So figuring out the strategy to cope with an environment is vital. Judging experience of Scrum practitioners whom I had contact, and form own I have tried to establish some algorithm showing general attitude towards Scrum in various organizations
In a nutshell the reaction to Scrum can be scaled into four main categories
1. Supportive
2. Indifferent
3. Stagnating
4. Hostile
Supportive environments usually exist in the organizations(firms, personal enterprises, institutions) whose revenue, profit or well being in some way is directly dependent on the success or failure of the Scrum related project. Who are aware of benefits and possible disadvantages of Scrum framework. Who are willing to learn and are not resisting the concept of adapting new ideas and new ways of human interactions within their organizations. Examples are small businesses who need scrum to reduce risk and eventually increase falling profit, corporate branches or offices where sales are directly linked to the project success, the political parties or other entities who desperately need new subscribers or supporters and try scrum to make whole operations more efficient
Indifferent environments are those who don't mind Scrum implemented, or even encourage it but for the wrong reasons-like vanity, instruction of remote head office, or intention to try "new hot thing". Those organizations usually don't depend on the success or failure of Scrum teams-either because they earn somewhere, like musicians, writers or fashion celebrities, or simply because they have permanent sponsorship or funding not depended on their performance whatsoever-like many government institutions or non profit foundations. Some corporate branches have fixed budgets too...
Stagnating environments can seem similar to indifferent, but there is a significant difference. Those environments are often dependent on the success or failure of the project, but strongly resist the proper implementation of Scrum, or even force the wrong exercise of the whole framework. Usually the reason is strong unwillingness of the management to give up traditional command and control methods, insecurity about new ideas,
inability to trust the self management team as professionals, lack of respect towards employees in general rooted in company culture... Or even in a whole regional tradition,
Hostile environments are rare thing, but they also happen. Hostile environment can be any type of firm, institution or organisation where management is deliberately and constantly sabotaging the Scrum and its practitioners. Reasons are usually the internal struggle-for example someone from the management can feel that success of the Scrum might threaten his or her position, or there is some internal corporate struggle where Scrum team is used as a pawn. Or plain personal hatred for personal reason.
Eventually scrum projects run in those four environments also vary
Supportive environments usually have successful Scrum projects facing challenges which are well known and frequently discussed by Scrum practitioners. There is a risk that the Supportive environment may become stagnating at the Scrum team side, if Scrum team will not feel personal material benefits(usually referred to as money) from the value they help create, but this aspect can also be addressed.
Indifferent environments mostly have the thing which is known as "zombi scrum" or "vanity" scrum". It's a Scrum team performing a circus of prescribed 5 events, keeping and updating the artefacts and even producing occasional value no one cares about, but in general its the form and performance, not the essence or meaning what matters in such places. Teams are often very much aware of details and provisions of scrum, often very pedantic in following "the rules'', but in general have no idea WHY are they doing all that.
Stagnating environments usually present variations of botched Scrum which often can't even match the wildest fantasy. I have described one such practice at the previous post called "Scrum in the "Scrum - breaching" environment" but this is just one example how far the fantasy of management, and actions or Scrum team who have to submit and surrender to keep the job can go in such places. In fact half of complaints at this forums addresses to such situations
Scrum in a hostile environment is just a game of survival. Depending on the intention to torpedo the project, and the state cold war between the Scrum team, who want to survive, and figures in management who don't want it to happen, things can take unexpected turns. Events often enter uncharted territory, but ironically this can often even produce value-for example if the Scrum team decided to run "guerilla scrum" which was described by me at this forum, or if PO will use his existing power to just push things on.
Establishing what type of environment the Scrum team finds itself in, is possible by a variety of techniques. Starting from "estimation poker" where every member of the team is estimating the support or hostility of the organization by anonymous vote, giving the mark from 1 to 10; or during the interactions between Scrum master and the managers.
Techniques and strategy for surviving and being successful depending on the environment may vary, and it would be fun to discuss.