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.
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.
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?
This article was originally written as a learning tool in April of 2018 during my studies of OrgMindset, I/O psychology, Human Factors, and working with Alex Yakyma on the OrgMindset body of knowledge. The article isn’t technically in a finished state since I write and learn iteratively and incrementally (so, look for updates in the future). The concepts presented here are based on empirical observations and so I wouldn’t consider this a scholarly article.
I decided to publish the article now to thank, recognize, and honor the significant and amazing contributions of Alex Yakyma. He has pushed everyone he interacts with forward in our learning in the change management and organizational transformation space. Alex is a creative and passionate, deep thinker who is a blessing to the world.
I have personally learned and grown professionally as an OrgMindset Enterprise Coach under Alex’s tutelage over the past few years. My hope is to share some of what I learned to enhance your continuous learning journey. I also reserve a hope that one day Alex will continue to develop and mine the gold and diamonds that are the OrgMindset body of knowledge. So, please share this article widely. 🙂
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: