New SAFe for Government course planned in DC!

Join us to learn about SAFe and celebrate getting back to work!

Sign up at EVENTBRITE using the special code: blogagility for a $100 discount for the first seven learners!

Advertisements

Team building patterns for SAFe®

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

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®”

Coder Culture – Crazy and Crashing

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”

Planning Defects into the system

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”

Agile Moment: I’m not impressed by your tools

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”

Learn how to install an innovation and learning rocket engine

Step by step instructions! 🙂

Sign-up using the blogagility.com discount code to save $100! Available for the first seven who signup using the code.

Pre-13th Annual State of Agile Report

The newest VersionOne (13th) Annual State of Agile Report will be released this spring. Last year the report was published on April 9, 2018. This year I will compare and contrast the various scaling frameworks growth and shrinkage and also discuss the missing elements for organizational transformation and whether or not the industry at large is addressing those challenges.

Read more