An apologist is defined as someone offering a defense of something controversial.
Since its introduction and emergence as a framework, within which a group of individuals can cohere and collaborate as a ‘real’ Team, Scrum has attracted both detractors and the aforementioned apologists.
I have just one question for the apologists, “Why?”
If you’ve studied Scrum, you’ve learned that:
- Scrum a lightweight framework with very few rules, and a small set of guidelines.
- Scrum is a minimum of “events” with which to apply a Shewhart-Deming iterative model[1].
- Scrum involves just enough discussion of roles to apply decision-making around an intent and direction towards an objective; focusing skilled individuals on achieving a shared goal and providing someone to teach, coach, and facilitate them together to “uncover better ways… ”[2]
- And within Scrum’s simplicity lies its only real challenge… that of the human propensity to either 1) not want to accept things that seem “too good to be true” (it can’t possibly work) or 2) to be afraid that there “might just be something to this” (shake up the status quo).
Thus, it’s not about whether it’s true or not (there’s sufficient evidence that empirical approaches to problem-solving work), but rather that Scrum’s intent is TO MAKE YOU THINK! The fault with most “implementations of Scrum” is that they don’t enter into the process with the intent of making you think; these implementations are trying to set up a process for you to follow. This is a mistake.
If someone approaches Scrum from a “this is a method,” “this is a defined process,” “this is a recipe to follow,” (and who doesn’t love recipes?) they will find much to dislike.
None of those are Scrum’s intent. If there is any intent built into Scrum, it’s to THINK about THINKING about how to improve ourselves in our professional practice (whatever that professional practice may be)… thus improving how we focus on how that professional practice produces some valuable outcomes; both for those carrying out those objectives (Do-ers) and those receiving the “thing or things” that result (stakeholders,[3] clients,[4] customers,[5] etc.).
If someone has demonstrated to you their misinterpretation of Scrum by applying it in a way that doesn’t help you think about “Why are we doing what we’re doing?” (understanding intent) and “Is what we’re doing helping us uncover better ways?” (carrying out those intents) then that not only isn’t what Scrum is, but it’s also not what Scrum is about. For that, Scrum has no need to apologize.
As I’ve described, if that’s your experience, someone may want to think about asking for an apology. Or someone may want to think about apologizing for their misinterpretation, misattribution, or misapplication. But why apologize? Use the opportunity to re-think your understanding of Scrum. After all, Scrum is about individuals and interactions uncovering better ways.
Scrum doesn’t need apologists because it has nothing to apologize for.
Notes and Sources
1 Foundation and History of the PDSA Cycle. Accessed September 19, 2017. https://deming.org/uploads/paper/PDSA_History_Ron_Moen.pdf.
2 “Manifesto for Agile Software Development.” Manifesto for Agile Software Development. Accessed September 19, 2017. http://agilemanifesto.org/.
3-5 “Stakeholders,” “Client,” “Customers.” ScrumDictionary.com. Accessed October 10, 2017. https://scrumdictionary.com/.