Why I Would Never Go “Enterprise Scrum”
I’ve had some recent debates regarding whether we should start an “enterprise Scrum” initiative, i.e. WE WILL BE A SCRUM SHOP. I would have completely supported this several years ago. Now, I am completely against it.
In an organization of any significant size or age, there typically have been methodologies that have been introduced, pushed, then they fade away into the far recesses of everyone’s memories. One characteristic of these methodologies is that they have very specific rules. You can’t add to, change, or remove any of the rules. Why? Well, because you wouldn’t be “doing” X methodology!!!
People have a habit of dogmatically following whatever methodology management makes them follow. Now let’s say we are doing “Enterprise Scrum”. This means that you are performing the following ceremonies:
- Release Planning
- Sprint Planning (every sprint)
- Daily Scrum (every day)
- Sprint Review (every sprint)
- Sprint Retrospective (every sprint)
And, you have the following roles:
- (1) Scrum Master
- (1) Product Owner
- Team (self-organizing)
And you will have the following artifacts:
- Product Backlog
- Sprint Backlog
- Burndown/Burnup charts (some say Scrum requires these, I don’t think it does as it’s not clearly articulated and varies by source)
So we’ve gone enterprise Scrum. We’ve introduced this “by the book” Scrum. However, we’ve also preached “inspect and adapt”. But, in Scrum, the above items are non-negotiable…you can inspect and adapt all you want, but you can’t change the ceremonies, artifacts, and roles. Can you add to them? Sure, but you can’t “change” them. And, in reality, making “inspect and adapt” a cultural “habit” is spectacularly difficult and rarely truly attained.
What if we have a Scrum team that wants to do a retrospective every other sprint instead of every sprint? Blasphemy!!! <finger-pointing> YOU are doing SCRUM-BUT!!! </finger-pointing>. Really? What if the team, Scrum Master, and Product Owner are all cool with it? Now we have a bunch of stress, spinning, and politics because we want to make a change to our enterprise standard Scrum. In reality, this is perfectly okay. However, since we’ve pushed “Enterprise Scrum”, we have totally boxed ourselves in. There will even be people who will not want to add techniques because “Scrum doesn’t say so”. Do those people truly understand the essence of Scrum? No. But they will cause disruption and waste
What if you don’t want to do iterations? What if you want to deliver continuously instead of iteratively? No Iterations?!?! Blasphemy!!!! <finger-pointing> YOU are doing SCRUM-BUT!!! </finger-pointing>.
You know all of this could have been avoided? By NOT saying we are going “Enterprise Scrum”. I believe the best way to roll this out is by pushing Agile and Lean and what makes sense on a project by project basis. Along with this there should be some foundational elements that are standard regardless of the methodology/toolset that is used. In addition, there needs to be a COE that can ensure that consistency is maintained without bureaucracy, and that knowledge gained is effectively utilized to continuously improve.
Please don’t misunderstand my intention here. I am not bashing Scrum. I LOVE Scrum. I always use Scrum when I execute projects. However, I’ve had rare cases within the same company where Scrum was NOT optimal, but Kanban was. I was very thankful that Scrum was not the required standard.
About Andre Simones
The Lean Agile Guy Blog 
Any time that you have rules, and not guidelines, you set yourself up for bureaucracy. If there is a conscious decision to vary from the guidelines, made with full understanding of the implications of that decision, then it is a wise decision. However, if you don’t have the knowledge, wisdom or experience to understand the ramification of that decision, then you are setting yourself up for trouble. There is a clear reason why some of the required/suggested ceremonies and artifacts exist in Scrum. They are based on the wisdom of a lot of people with more experience than I have. I may think that the guideline to change my oil in my car every 3,000 miles is silly. I once went 7,000 miles and nothing happened. Why bother at all? So, in the case of the oil change, am I making a wise decision, or am I just being plain old lazy?
Also, an informed decision is one that considers the implications on others as well as your team. Many teams run with the lean concept that whatever doesn’t add business value is waste. It is a great principle to help guide decisions. But taken too far, you end up with project teams that tend to communicate the message “I will be done when I get done”, i.e. don’t ask me to forecast, take measurements or provide any feedback regarding how much money has been and will be spent. Too often, the extreme agilists forget that they are not working for themselves. Corporate fiscal responsibility and accountability can’t be tossed out the window in the name of waste. I see that mindset too often with less mature project scrum masters and project managers.