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.
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…
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?
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:
Or are we still working in the blacksmith shop? Will it take AI to bridge the gap?
In Lean manufacturing companies that build physical things have been able to improve quality consistently and dramatically since the dawn of the industrial age.
Here many of us are in the post-industrial, Information Technology or Digital Age.
When we change the channel to knowledge work, companies struggle mightily to match the pace of quality and outcomes of physical manufacturers, even to this day. Why?
XP, Agile, Scrum, DEVOPS, Kanban for Software, Scaling Frameworks
Are these practices, methods, frameworks, and guidance really helping the knowledge worker factory catch up with companies that make physical things? Perhaps there is some evidence to support the claim. Continue reading “The Knowledge Worker Factory”→
If you read it and found some value. Please share it: