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.
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.
Any two-day course is only the beginning. In two days, you are getting exposed to a breadth of knowledge about Scrum. If you are lucky enough to learn Scrum from a provider that includes Bowman’s Back of the Room and/or Gamification techniques then you will also be exposed to a surface level experience of how Scrum is intended to work.
Check out the amazing things that high performance, motivated teams can do. This is business agility and Lean-Agile culture at its best. The transformation of my client’s organization is amazing. We are using Lean, Agile, Scrum, Kanban (and systems thinking), SAFe®, OrgMindset®, and other tools to inspire and persuade a positive change in culture at the FAA-ESC.
It is hard work, but it is worth every minute of it. It isn’t perfect, but the results are significant and measurable. The “why” was a burning platform. Now, just a few PI’s later, it is a thriving platform. We focus on the goals, not the tools to achieve positive business outcomes.
Congratulations to Team Armada for winning the “Relentless Improvers” innovation football for PI6.
Big kudos to John Wiese and his team for putting together an awe-inspiring PI System Demo.
Special thanks to the FAA-ESC, John Wiese, and teams for providing permission to publish the video under the safe harbor notice/policy. Also, special thanks to Matt Taylor for sharing a different video perspective as a content contributor.
Bill, Chris, John, Patty, and Wes walk into a bar to fret over the demise of their accomplishments…
If only they had conceived that constraints also exist outside of the IT manufacturing system.
All they accomplished was to build a faster, more reliable and better handling car for Steve to drive like he stole it. Steve’s behavior didn’t change, nor did the culture. The culture changed in the part but not the whole. Continue reading “A Phoenix Burns”→
If you read it and found some value. Please share it: