Cargo Cult Scrum
"Cargo cult programming is a style of computer programming characterized by the ritual inclusion of code or program structures that serve no real purpose. Cargo cult programming is typically symptomatic of a programmer not understanding either a bug they were attempting to solve or the apparent solution (compare shotgun debugging, deep magic).[1] The term cargo cult programmer may apply when an unskilled or novice computer programmer (or one inexperienced with the problem at hand) copies some program code from one place to another with little or no understanding of how it works or whether it is required in its new position."
Cargo Cult Scrum
Cargo Cult Scrum is a style of Agile Project Management characterized by the ritual inclusion of ceremonies, tools and reports without understanding the purpose or meaning of these ceremonies, tools or reports. Performing a complex dance of prescribed processes and tooling in hopes that one day Great Productivity might be delivered from the heavens. To someone only marginally familiar with what Scrum entails, they might believe that the rote performance of these actions is Scrum. But to a Scrum professional, it looks as silly as the "airplane" in the header image and has about as much chance to fly.
Scrum is not a process. It's a philosophy. If you don't understand why you are following a process or using a particular tool, you will inevitably miss critical nuances of the system and continue to perform a hollow facade of Scrum. Team members will become frustrated and managers will ask "Where is this great productivity boost Scrum was supposed to give me! I'm doing the dance and having the meetings and moving issues around on Jira! Scrum must be bad!"
Scrum \is\ terrible when it's run as a series of disconnected and misunderstood policies and processes with no meaning or understanding supporting them. The good news is that "Cargo Cult Scrum" can be avoided.
The Pillars of Scrum
The pillars of scrum are the basis for it's empirical model.
"Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation."
These three sentences above answer the question "why" that lies behind the Scrum ceremonies and artifacts. This simple foundation of Three Pillars of Scrum supporting the empirical model are tied directly to the Scrum ceremonies and artifacts that we sometimes take for granted.
Why do we have daily Scrum meetings? To inspect our progress towards the sprint goal and adapt to any challenges and changes. If your Daily Scrum meetings are just an empty status with no analysis and no input from the team on how to adapt to challenges and changes, you're not doing Scrum!
Why do we hold Sprint Reviews? To make the result our product increment transparent to all interested stakeholders. If you are holding a Sprint Review but the work that is produced is not being shared with users and stakeholders in an honest and transparent way and feedback provided directly back to the team, you are not doing Scrum!
What is the purpose of Sprint Retrospectives? To inspect our process and adapt to the project at hand. Scrum is not a static process. The process is owned by the team to shape and adapt to the challenges at hand. If your Sprint Retrospective consists of complaining about the process but never doing anything to fix the problems, you're not doing Scrum!
What is the purpose of Sprint Planning? To optimize predictability and control risk by planning only a short increment of work. To make the best decisions possible based on our current knowledge and experience. If your Sprint Planning consists of just blindly piling in items from a 2 year roadmap that was created 6 months ago.. you're not doing Scrum!
If your work isn't being inspected at short regular intervals, if your goals and your product are not transparent to leadership and stakeholders, if you are not adapting to challenges and changes, you're not doing Scrum, you're just going through the motions. Scrum becomes a superstition, not a science.
Scrum is a science. A Sprint is an experiment. A Scrum Team examines the experimental results of the sprint and decides what to do next based on what has been learned. If you're not being responsive to feedback or even being transparent enough to get feedback in the first place, you're not doing Scrum! If you're not inspecting your product increment, you're not doing Scrum!
The way to avoid "Cargo Cult Scrum" is simple. Be empirical! Be Transparent! Inspect and adapt! Do Scrum, not the process!