Is This Really Scrum?
Every organization that attempts to adopt the Scrum framework is on a journey of continuous growth to improve their practice. No organization is perfect. While Scrum can be learned in less than 30 minutes, it takes years to master and adapt to organizational values and traditions. Scrum adoption is never finished. It is always ebbing and flowing with the needs and demands of the self-organizing teams that are the core of Scrum. If your Scrum practice is no longer changing, then you are probably no longer practicing Scrum.
The difference between an organization that is practicing Scrum and one that is not is the organizational commitment to the whole framework. The creators of Scrum say it this way: "Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum." (emphasis added) Thus, you are either committed to the full framework, or you are not. If you are not embracing all of Scrum, then you are not practicing Scrum.
If you are committed to adopt the "whole of scrum," every person on every team needs to reference the same definition. Most organizations reference the Scrum Guide as their standard. It is maintained by Ken Schwaber and Jeff Sutherland, who have been defining and refining Scrum for more than 20 years. While other sources and other tools provide additional value to Scrum and agile development methods, the Scrum Guide has emerged as the defacto standard for the Scrum framework. Even if you eventually write your own guide, you will still need to reference the Scrum Guide in order to honor the copyright terms of the Attribution ShareAlike license of Creative Commons.
Ironically, if you do not intend to implement all rules, roles, events, and artifacts of Scrum, it is even more important that you have a reference document for people to use for continuous guidance and planning. Your people need to know which features of Scrum are being followed and which are not. It also helps to provide explanation for why some features are not being adopted. Not only will this clarify organizational values and plans, but it also provides a continuous reminder to everyone that, "this is not Scrum." You may see it called "Scrum-lite," "Scrum-ish," or even "Scrum-but." Choose a label that works for you, but make sure you don't call it "Scrum" if you do not plan to implement it all.
If you expect one of the Scrum roles to function different than the official definition, then you need to make that information available for ready reference and consumption. If the organization has rewritten the agenda of the Scrum Review meeting, the new definition needs to be available including an explanation for the deviation. Your practice needs to be defined and explained so new team members can quickly adapt. Without a reference, they're likely to assume you're adopting the published standard. Variance can be confusing, costly, and include many unintended consequences.
It is important to understand that Scrum is a framework and not a methodology. There are many methods used by Scrum teams to improve their work. As a framework, it is extremely flexible and adaptable without having to be redefined. It is best to implement the full Scrum framework and only deviate if irreconcilable differences develop between the framework values and the organizational values. Even then, it might be worth finding a way to maintain the framework.
Ultimately, anything that is removed from Scrum will result in a loss of quality and invite waste. That is because the framework ensures that empirical values of transparency, inspection, and adaptation are applied continuously to all aspects of the work. Scrum has been around for a couple of decades. Changing the framework will cause unnecessary confusion and require re-education to be effective.
Finally, if you hire people with the job title of Scrum Master or Product Owner, then people will expect the organization to practice Scrum, unless otherwise defined. If you are hiring people to fill those roles in an adapted-Scrum environment, it is only fair--and exceedingly wise--to tell them in advance that your version of Scrum is different and help them to understand how the variance is managed. Asking a Scrum Master to join the organization and help to improve the Scrum practice only makes sense if you intend to adopt the Scrum framework. Asking Product Owners to fulfill responsibilities not defined in Scrum would be confusing if not defined and explained. Development Team members need to know what to expect in order to be effective.
To Scrum or not to Scrum? Are you being honest and fair about what you do?
Based on the Scrum Guide, ©2018 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http://creativecommons.org/licenses/by-sa/4.0/.
