There are a few Formula1 videos around the web that we use to teach about the economics of batch sizes, particularly in the SAFe, where the teachings of Don Reinertsen are embedded in the body of knowledge. I found this new video on LinkedIn today and thought I would share them with the community.
Remember, we are trying to reduce the transaction cost of a batch. In these videos the older pit stop people, process and tooling resulted in a much higher transaction cost compared to the modern pit stop with automated tools and swarming. This can be done through automation, architecture, tools, kaizen of process, and through new ways of thinking and working, and even new ways of feeling. We must pay particular attention to the relationship between tools, people, and process as optimizing one without tuning the others may not improve anything (systems thinking).
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.
I read several articles on the subject after having a short discussion during class this week with a fellow student (and amazing person!).
#noestimates does not seem to address the rather common difficulty in achieving a consistent, homogenous backlog with deterministic job durations and delay costs in a CAS. The #noestimates solution fails in the same ways that story points can fail. Yin/Yang. Red vs. Blue. Black & White. Whoopee.
Teams need to learn the artful skill of slicing features into stories a related to their business context and domain purpose. A typical anti-pattern is for teams to waterfall their iterations, as described in the next two scenarios.
The first iteration we will gather all the requirements, the second iteration we will design, the third and fourth iterations we will build, and the fifth iteration we will test…and so on…
Another derivation of this anti-pattern is to order up another form of phony business agility and/or Scrum.
In this iteration we will pull “requirements gathering” stories first. When those are all finished, we will pull the “design stories”, and then “build” stories…
The next common anti-pattern related to intra-waterfall is for dev team members to pull stories and work on them independently. This is a siloing ant-pattern, indicating the team is not cross-functional and is simply a collection of silos and individual waterfalls. Continue reading “Paradigm shift: Slicing Features”→
If you read it and found some value. Please share it: