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.
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:
The fourth tool created to date by blogagility.com forthecommunity!
This handy starter kit is for Scrum masters that are using the Shu Ha Ri paradigm for team development. Good coaches help new teams avoid the pitfalls of added complexity involved in “Agile Lifecycle Management Tools” and instead push for good old-fashioned manual BVIR’s, Kanbans, Scrum boards, et cetera. Change is hard enough in a CAS without adding to the problem by also complicating the way of working. Continue reading “Lean-Agile Team Metrics Starter Kit”→
If you read it and found some value. Please share it: