Belief and Behavior: A Two-Way Street
During a project kickoff session at a client in Phoenix, the systems architect was determined to use a suite of UML diagrams to document his architecture. He said it would take two months. I said, “You have two weeks.”
He grumbled about the time constraint but produced a viable architectural starting point two weeks later. Four iterations into the project, he came back to me, “We had a major revamp of the architecture. However, two months ago, I would not have considered the current architecture, no matter how much time you had given me. I finally understand the benefit of an iterative approach, even with architecture.”
Does belief (our mindset) drive behavior (our practice) – or does behavior drive belief?
Virtuous or Vicious Cycle?
Actually, it’s not a “Who’s on first” question. Implementing behaviors (practices) in the right way leads to belief changes—creating a virtuous cycle. Implementing behaviors (practices) in the wrong way doesn’t lead to belief changes—creating a vicious cycle. The crux of whether you create a virtuous or a vicious cycle lies in the phrase, “In the right way.”
Consider the systems architect mentioned earlier. He cycled through a process of acquiring knowledge, gaining experience, reflecting on his knowledge and experience, and finally adapting his approach to architecture work. He initiated a virtuous cycle by reflecting on his behavior which in turn began altering his belief about the value of shorter iterations.
Too many organizations are creating vicious cycles because they practice “prescriptive agile,” dictating a set of behaviors (practices) but failing to reflect and adapt. This leads to executing a set of behaviors by rote and failing to nurture the belief (mindset) change to agility. Implementing behavior changes without a corresponding mindset change leads to Fake Agile, resulting in negative consequences for both the organization and the agile community.
“It’s easier to act your way into a new way of thinking than think your way into a new way of acting.”
— Dr. Jerry Sternin, Harvard Business School
Constraint Versus Creativity
Consider another phrase in the systems architect’s story: “You have two weeks.” That sounds suspiciously like telling or controlling. People might say this approach is anti-agile because agile is supposed to be collaborative and empowering. But sometimes as a leader, you must tell people what to do to get started. In this story, the dev team was willing to try this “agile stuff,” but the architect wasn’t. However, I didn’t tell him how to do his job. I didn’t take away his UML diagrams. I simply provided a constraint – two weeks – which left the rest up to his creativity.
Just as agility demands a leader balance the reinforcing loop between behavior and belief, it demands they balance between “command-control and agile leadership, but that’s a story for another time.
About the Author
While Jim Highsmith retired from ThoughtWorks in 2021, he continues to share his 60+ years of expertise, wisdom, and insights from roles across the industry as an IT manager, product manager, project manager, consultant, software developer, and storyteller.
Jim has been a leader in the agile community for 30+ years, notably as a co-author of the Agile Manifesto, founding member of The Agile Alliance, co-author of the Declaration of Interdependence for project leaders, and co-founder and first president of the Agile Leadership Network.
