I updated the title of the article. I have observed a pattern over the past year or so of Scrum Alliance aligned folks like Certified Scrum Trainers (CST) and other certified Scrum folks writing articles and posts of varying degrees of criticism from valid debates over ideas (rare) to mostly disparaging misrepresentations, to openly hostile, to outright extremist comments like the picture above. I changed the article title to properly address not all CST’s. The original title was meant to address the pattern observed by many people in the industry of several unnamed CST’s making hateful comments about SAFe and the people behind the SAFe.
Remember, hate comes in many forms. All of it is bad, and unacceptable. I’ve lost count of the number of people that I have known, loved, and like that have died or suffered from cancer (and parasites). Attributing those words to the good people behind the SAFe is absolutely abhorrent, evil behavior. The picture above is just the latest attack. So, I apologize for the original generalization.
There are also two parts to this article. The first part addresses the hateful opening comment from Alexey. The second challenges the misrepresentations of the SAFe. These are separate discussions. Debating ideas is necessary. We should not ever accept hateful words or behavior.
Let me start by explaining why I even bother debating with hateful people in the first place. Because we must confront evil in the world. Yes, at its root this is evil, misguided behavior. If we want to move ideas forward to innovation they must be challenged in a respectful, professional manner.
Anyone that starts out a conversation by saying you or your thing is a “cancer and parasite” isn’t actually looking for conversation. They are being hateful and are probably ignorant on the topic of debate. If this were a political topic then perhaps the bad behavior could be expected because it has been normalized for millennia. Does it make it right? Emphatically, no.
I find it disturbing that extremists and their ilk who are supposedly exemplars for the Agile Manifesto and values of Scrum openly display behavior that is antithetical to the Agile Manifesto and Scrum. After all, “RESPECT” is a value of Scrum. And the manifesto has a clear purpose, “We are uncovering better ways of developing software by doing it and helping others do it.“
I couldn’t agree more. In nearly every case over my 20+ year career that I’ve been invited to help scale business agility, “to become Agile – in behavior and nature”, in an enterprise the organization was already struggling with achieving agility using just Scrum and Agile. This is the basis of my often repeated statement, “Agile is dead.”
To my dismay, it is also common for the great technical and business practices and concepts from XP to not exist in the lexicon of the organization. Or, only part of XP is used, often incorrectly. It is shameful that Kent Beck’s work is not more prominent in the space. I’m glad to see that he is becoming more active again recently.
A better coaching approach (than simply proposing Scrum and Agile in a CAS) is to understand the market of tools, best practices, frameworks, et cetera and how to apply them appropriately without bias to customer context to drive better outcomes for the business or organization.
As a continuous learner, this is also why I have so much respect Alex Yakyma’s work with OrgMindset. Thinking tools are needed to properly apply and use complex tools in complex organizations. Alex said something very important and interesting during our last discussion/debate about the topics of “Agile” tools and frameworks. Paraphrasing, he said, “I’m just using everything that I know and all of my skills and experience to help businesses make more money.”
This statement is important because often Agile zealots lose sight of the purpose of business – to create wealth – for the shareholders or beneficiaries of the organization. Agile and Scrum are not the goal.
Furthermore, we often forget that Agile and Scrum start out in a state of death. Agile and Scrum are literally just words on a page. They must be given life.
Team A, an Agile Release Train (ART), or the mythical Scrum team, has a lot of technical debt. In an effort to reduce the technical debt, management decides to create a bunch of new “container” “FEATURES” in the product backlog to address batches of defects. Because they want to understand the value of the (fixing) defects.
Except there is a problem. Defects are not new features. Well, in a sane software world we hope not? Defects are typically created while coding or configuring a new feature, right? Is it a defect yet? Not really. Fix it NOW, not later. If it makes it to production? What is the cause of defects making it to production? Poor coding, standards, quality and automation, et cetera? No DevOps? or do defects occur magically in existing features (real ones)? (not my code!!) We all know how computers have minds of their own…
I’ve seen that oddly familiar pattern of desire to package up defect fix/technical debt effort into a feature or story or a suite before. I call these “projects”, “probably to be implemented with waterfall.” That type needs project managers and factory workers, not Lean-Agile practitioners, creative knowledge workers driven by autonomy, mastery, and purpose.
It has been said that “Value is in the eye of the beholder.” Our perceptions drive our understanding of value, according to psychologists, and perhaps marketers. What makes great marketing at a company and positive sales can also have a negative effect on the product development organization itself. A double-edged sword of sorts, as humans and our perceptions, assumptions, and emotions travel with us to work. Long after that impulse purchase of the latest iPhone or other gadgets we are still creatures of habit.
The same behaviors that make us vulnerable to marketing manipulation also make product development companies vulnerable to diminished truth and performance in execution. The reality is that we are navigating complex adaptive systems (CAS) within systems. The system (organization) we work within, the product (a system), our team (a system), and ourselves (a system). The causes and effects of movement or change in and around the systems are where we must build discipline, manage assumptions, and rationalize, validate (/in-) through experiments. These validations become part of our imprint, our perceptions, or mental models (schemas). But what if our rationalization or validation was incorrect? Our experiment flawed. How would you know?
This is an organizational aspect too. The organization is the symbiosis of its people and their behavior and mental models.
For example, what is the value of a spare tire when you are purchasing a new car?
Awesome experience with a great group of students eager to learn about Scrum mastering within a SAFe portfolio. I really love teaching this course. 28 folks were in the class and thirteen agreed to take the picture to be posted here on LI. Thank you, team! My co-instructor, Giuseppe B. (left), was also amazing, as usual, as expected for such a great guy! The team chose (self-managed) to use the “Build a house” simulation rather than stock context sim so it was great fun to learn about and experience the awesomeness of PI Planning and the enterprise backlog model while planning a $1.5M mansion.
The teams also experienced self-organization and self-management in this course as they aligned to a common mission, vision, and strategy for their “construction company ART.” They learned how to write and decompose great features and stories.
The students also get near constant teaching and reference back to the value systems of the Agile Manifesto, SAFe, Scrum, Lean, and Systems Thinking. We spend lots of time talking about cognitive empathy, Human Factors, CAS, and culture transformation using the AM goal of “We are uncovering better ways of developing software by doing it and helping others do it” as a foundation.
If you read it and found some value. Please share it: