check out this awesome book of anti patterns.
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?
#Scaledagileframework #safe #productmanagement #learning
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.Continue reading “Team building patterns for SAFe®”
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…Continue reading “Coder Culture – Crazy and Crashing”
Why on earth do we do that?
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.Continue reading “Planning Defects into the system”
A thought from a thread that Al S. started.
A craftsman knows how to use the right tool applied to the appropriate task. My grandfather was a master carpenter. He built hundreds of homes and also furniture and renovations. He possessed a garage full of all kinds of tools and hardware. Even many of a class of tools. Different types of hammers and saws and glue and nails and screws. His customers did not purchase his garage nor his tools. They were buying a finished product. A house. A table. A newly remodeled bathroom or kitchen. The product of, the intersection of the craftsman and tools, is where the value is captured and delivered.Continue reading “Agile Moment: I’m not impressed by your tools”