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.
Product management is a wholly immersive experience. It simply cannot be done effectively through shortcuts and half baked effort. At scale or for your mom and pop shop… success means hard work and building deep and wide connections with those who buy and those who build as you make the economic decisions on which slice is the highest value and priority.
I recall observing industry competitors wrestling for feature priorities for the OpenDataPlane project (and others) at Linaro Connect. The dynamics of that competition are exactly what your organization needs to build through intrepreneurship. I’m still learning from the past. Are you?
Here are some patterns to think about the next time you are planning an Agile Release Train (ART) launch. The ART launch should be preceded by a successful value stream identification workshop. Even still, old mental models may prevail that are deeply embedded in the culture of the organization.
Mechanical Scrum is bad for everyone.
You cannot force or assign shared ownership. Management must learn to trust her people and the system. An appropriate quote follows.
Edward Lorenz’s original metaphor for a chaotic system—the world’s weather where the nonlinear nature of forces potentially makes it possible for a butterfly in Beijing to affect the weather a few days later in New York—managers today seem to be living in fear of butterflies.
A potential misstep in launching an ART is allowing management to “assign” team members to teams based off of an overly simplistic view of the value stream or a set of unmanaged assumptions. If the knowledge workers know the work best, then leadership and management should allow the team to be part of the conversation and part of the decision-making process (SAFe Principle #9) for organizing and aligning the ART to the value stream.
This involves a process of self-organization. It is more than just a sequence of steps. If an organizations creation is facilitated mechanically through process steps, then the result will be uncommitted teams and forced misalignment.
At a Product Owner Community of Practice event a few months ago I had a very interesting conversation with some great folks. We were discussing the topic of testing on an Agile team. During the discussion, someone mentioned a recent coder comment along the lines of, “I was hired as a developer, not a tester.”
Hell, I’ve heard this comment numerous times in my career! Agilists are crying. The DevOps folks are considering a jump! Call the police! Heresy!
I pointed out that as an “evil” Scrum master I would want to comment to this “developer” that, “what I am hearing is that you are a programmer, not a developer.” Now, we shouldn’t let our own emotions drive our behavior in this way so I wouldn’t recommend saying this to anyone. There are constructive ways to address bad philosophy and behavior in the system. Moving on from the shock and awe…
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.