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:
Don’t limit your team to using just Scrum or Kanban. Don’t even limit yourself to using watered down versions of a combination of Scrum and Kanban. High-performance teams master both the empirical process framework and controls called Scrum, and the use of Kanban (system; Lean).
Continuous Learning (The Three Ways) & Empiricism
Continuous learning teams know how to scale these frameworks and systems using the SAFe and other scaling frameworks to suit the needs of the business and customer solution context (value). Learning teams know how to drive DEVOPS culture and practices through self-organization and self-management.
Scrumming it, the next step
If you are practicing Scrum, and using a Kanban to support the process framework it is helpful to walk the board during the Daily Stand-up (Scrum). Do this a few times a week rather than asking the three questions every day.
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.