Agilists are not to be divided into divisions or sections but rather be united under one manifesto. Common purpose is off course the same: uncovering better ways of developing. However, since the publication of the agile manifesto, there have arisen distinctions into schools of thought, methods, traditions, and related practices. Furthermore, the same organic and natural emergence of fragmentation happens also with Scrum.
Since the publication of the agile manifesto, there have arisen distinctions into schools of thought, methods, traditions, and related practices.
While implementing Scrum in an organisation, there is always a discussion about the implementation of rules and the level of flexibility. Some practitioners argue that all best practices must be followed as literally as possible and that it is otherwise not Scrum. Other practitioners argue that the essence is important and that the practices are all up to individuals to follow, change or set aside. While the description of a practice can be very clear, the implementation in practice may still differ from team to team. Like a religion we can say that there are interpretation and perception differences caused by the context.
These differences in explanation, understanding and execution results in various "types" of Scrum. While this is already recognized, I must say that most of these observations tend to be negatively treated. Any deviation off the perfect implementation is quickly labeled as Cowboy Agile, Agilefall, Waterfall or Scrum But. Such an approach leaves little room for openly admitting and recognizing problems without being alienated. The acknowledgement that there are types of Scrum also doesn't mean that Scrum should be separated and promoted in branches and they should be taught separately. It only means that in practice there are discrepancies.
The three basic types of Scrum
The types are not in sequential order. A company can execute "Pure Scrum" and due to changes such as demand or product, a team can consciously or unconsciously decide to do "Social Scrum". The types of Scrum can be compared to the Nokia test. But there is definitely a difference. The Nokia test tries to clarify how "Pure Scrum" is implemented. The score of 1 doesn't define "Social Scrum". The recognition of the type of Scrum implementation can therefore be used besides the Nokia Test.
1) Social Scrum
Often the superficial practices such as the daily stand-ups are done. There is a Scrum Board with colored post-its but these are not negotiable User Stories. There is not really a Product Owner. The team needs to distill the User Stories out of a requirements document or there is already a design that needs to be build. There is not a definition of done. The team changes the status of their User Stories to done, when they feel it is done. If the Sprint is not completed on time, the Sprint can be extended for couple of days. If after the Sprints things need to be implemented or changed, the team will do the tasks. Scope of the project is determined by predictive methods and the overall vision of the organisation is that the desired optimal state is a "batch production process" and reducing the batch size and changeover times are the primary goals.
Pros: Easy and fun (no conflicts), Better motivation, Potential for more adaption
The team does not bother anyone and doesn't demand a much change for the organisation. The heavy processes of the organisation can continue peacefully. It is fun to do the meetings not sitting and it reduces paper work and meeting time. Some difficult questions can be answered by "because we use Scrum". Social Scrum can really easy and fast develop/sustain high motivation. Management supports their initiative because they see people are less complaining. It is also cool they can see progress and that everybody is really working and busy. Fostering creativity and innovation is really difficult but it is more then before Scrum. The team sees potential for more adaptation and they can exercise and prepare for more Scrum practices.
Cons: Nobody accountable for team results, Can result in micro management, No performance improvement
After a couple of Sprints, it can be difficult to hold the atmosphere. Some team members can be skeptical because they can't make any choices but are sometimes responsible for the end result. There isn't a working build after every iteration and the product is not according the Requirements Specification Document and thus still needs to be finished. The needed ad-hoc changes in priorities and incoming requirements can result in a lot of managerial interference. Important decisions need to be taken by people outside the team. There is still a need for a heavy change management but there isn't any because of Scrum. The gained performance improvements are lost by the inefficiencies introduced by Scrum and that can lead to a negative reputation for Scrum. Minimizing confusion/coordination is still a huge problem.
2) Pragmatic Scrum
A lot of the practices of Scrum are implemented except the really difficult ones like determining the Sprint Backlog. The team commits to the Product Backlog and tries to complete as much as possible. One of the most important characteristics of Pragmatic Scrum is that Authority to manage the work is not by the team because it is really sensitive. Pragmatic Scrum has many similarities with Kanban but should not be confused with it. While Kanban only tries to visualize the flow of workload and reduce work in progress, "Pragmatic Scrum" tries to produce incrementally as a team. Scope of the project is determined by predictive methods and the overall vision of the organisation is that the desired optimal state is a "continuous flow process" and standardization, cutting costs and increasing the output volume are the primary goals.
Pros: Quick productivity improvements, Better communication, Fast start
Because Scrum ensures that the startup time of the project decreases there is really appreciable productivity improvement. The focus on complete upfront design of the product is not needed anymore and the focus is on faster increments of the product. The defects of the early iterations are still unacceptable but the overall performance is better. The daily stand ups and the retrospectives do really help to improve communication and a good meeting before a Sprint is a proper idea anyway. The design is still done as much as possible before the Sprint but doesn't need to be perfect anymore and can be adjusted within the Sprint.
Cons: No organizational improvements, Can't determine the capacity, After the quick wins it can become worse.
The big impediments are seen as inevitable side issues and can not be changed. This ensures that there can't be made fundamental improvements. There is often still not a clear direction because crucial roles like Product Owner and Scrum Master is not fully understood and implemented. If "Pragmatic Scrum" is bad managed, it will make things worse on the long term because multi tasking will be increased as a result of the faster startup times and unfinished work.
3) Pure Scrum
The team understands the context of Scrum and has the competencies and authority to operate independent. The experts are cross functional and there is a dedicated Product Owner with a viable vision that tests the User Stories and gives appropriate feedback. The Scrum Master removes the needed impediments and there is almost none upper-management interference. Before each Sprint the team debates about the possible impact of the changes and the needed refactoring of the framework and commit for the timebox. The team and the Product Owner consult about the distribution of time to the specific User Stories and the possible scenario's that it will induce. Uncertainties of the added value of the Sprint is carefully considered and adjusted accordingly. Scope of the project is determined by adaptive methods and the overall vision of the organisation is that the desired optimal state is a "job production process". Innovation and quality are the primary goals.
Pros: Self managing, Innovative, No overhead costs
The team can operate fully independent and is able to assess the possible value creation by implementing a User Story in a specific way. The overall direction of the project is changed if needed without permissions outside the team. Team is able to learn from their choices and can change the organisation to optimize the whole. The experts have enough room to experiment and innovate solutions that have a ROI. Because the team size is small the costs are really low without overhead costs. The financial income and expenditure are easy to calculate.
Cons: Architecture and infrastructure, Need a change of engineering practices, Doesn't provide any guideline on a lot of (hard) questions, time-consuming, Potential for conflict, Costly to build
The investment and the generating revenue is a huge challenge at the beginning. Because the overall project outcome is uncertain, it is difficult to justify why the project should be funded. Not everyone or every project is suitable for "Pure Scrum". The team members need to change their workflow and need to be able to deliver working software continuously which is sometimes not possible. Difficult problems like how to validate a product vision or how to forecast budgeting is not answered by "Pure Scrum". If the desired outcome is not achieved it can be time consuming to decide when the time is right to end the project. Team members can in conflict between each other (For example a conflict between the Scrum Master and the Product Owner) and there is not a solution to resolve it.
Conclusion
It is not my intention to fork Scrum in 3 branches. I only want to make conscious that the implementation of Scrum can vary according to the situation. Being aware what you are doing is then very important. And maybe this model and terminology can help you with it. Ken is every clear about his vision of Scrum. He says: "The word “framework” means that much is not specified and must be devised by those using the framework. However, you are playing the game of chess, so you don’t have the option of changing the rule book. If you change the rules, it’s not chess any longer. Just learn how to play the game with excellence, which is enough of a challenge." and "If you don’t like Scrum, we welcome and invite you to devise something else. Just don’t call it Scrum."