One of the main challenges we (at Avaya) face in our agile adoption is dealing with agile anti-pattern behaviors caused by paradigms based on years of practice in the traditional (waterfall) software development domain. Anti-patterns are common solutions to common problems where the solution is ineffective and may result in undesired consequences. If you face the same challenge, keep on reading and hopefully you would find some of my insights helpful.
Avaya started a global business agility transformation more than a year ago (for software engineering, product management, and program management). We chose to create our own way instead of following one, so we have developed our own agile framework which we named AIM – Avaya's Agile Innovation Model (Agile doesn't appear in the acronym for a reason, but this is a story for a different post).
I was fortunate enough to be part of a great global agile core team (8 people from 5 locations), driving the global transformation worldwide. Serving in that position, I was exposed to different cultures, different technology domains, and different team structures. What I found common to all, is the way our brain is hard wired for supporting paradigms that are no longer valid.
Let's take a few examples.
- "I need to move people between teams for achieving the best utilization of my resources, which will result increased outcome for my group."
- "I want my engineers to focus on a specific technology aspect (I-shaped engineer as opposed to T-shaped engineer), as this is the best way an engineer would contribute to the group success."
- "Teams cannot operate efficiently without specific directions from a manager, and without frequent status meetings that would enforce those directions.”
You got the idea by now – those are the kind of paradigms I'm referring to. The big question is how we approach changing this state of mind. Obviously, those are paradigms based on years of operation in a non-agile environment. Breaking those paradigms is far from being neither easy nor trivial. I have tried (and keep trying) different approaches to help teams go through this paradigm shift, and I would like to share the approach I have found effective so far.
I move forward with teams in baby steps – one paradigm at a time. Each step contains a small batch of actions – starting with a rational explanation, moving to a behavioral change and ending with a short data-based reinforcement.
Last week I had the pleasure to have a long thoughtful discussion with Lola Rokni, an organizational consultant expert and a consultant for managers, which has put my thoughts into a visual model. She drew this model as a circle, which made a lot of sense to me. Each round will tackle one paradigm at a time. Each round is constructed of a few methods of convincing, each addressing one common rejects. These methods, working together in a specific order, creates an additive effect which is more likely to achieve the paradigm shift.
How to change a paradigm
I have sketched the model on a paper (see below). This is the Minimal Viable Product (MVP) of this model. Apologies for the hand writing.
Once I had the sketch on paper, I have sent it to Yuval Behar to review it. Yuval Behar is a cognitive behavioral psychotherapist and an organizational consultant. Yuval provided me some insights from his domain of expertise, suggesting that the order we should tackle the paradigms should be based on the anxiety level of the team for each paradigm. We can look at the paradigms as backlog, prioritized by anxiety level, where at the top is the least stressful paradigm. This way, we can gradually build confidence that help us tackle the more stressful paradigms. One more important input Yuval has provided, is that we should not invalidate the old paradigms, but rather state that the effectiveness of the old paradigms is now limited as the variables in the software development domain have changed (technology, frequent changes in market needs, competition, globalization, software development tools and frameworks, etc).
The rational phase
Step 1: Explaining the theory
This is a cognitive phase, where I introduce an agile pattern and explain the 'why' for that pattern, trying to achieve paradigm shift. Sometimes I use a game to demonstrate the effectiveness of the new pattern (and the dysfunction of the current paradigm). If the team rejects the pattern theory (e.g. "this pattern is wrong", "the game is not reflecting the reality"), I move on to the next step.
Step 2: Giving an internal success example
The next step is finding a case study from within the organization where the pattern usage resulted positive outcome. For example, indicating that team X has improved its value delivery since they start using the agile pattern (as opposed to the current paradigm). If the team rejects the pattern use case (e.g. "team X is not a valid example", "team X uses different product/technology"), I move on to the next step.
Step 3: Bringing research results
The next step is exposing the team to surveys that support the agile pattern. For example, VersionOne annual 'state of agile' report, Standish Group 'chaos' report, CA technologies 'the impact of agile quantified' report.
In most cases, this is where a mindset change begins. Thomas Kuhn (an American physicist and philosopher, which identified the 'paradigm shift' concept) describes this as a phase where enough anomalies have gathered against the current paradigm, which allows the adoption of a new paradigm. However…
The behavioral change phase
Step 4: Creating a different experience
There is a phase were talking is just not enough nor effective anymore, and there is a need to move into a behavioral change phase for getting experience with the new paradigm. This is where I found executive sponsorship helpful in moving teams into this phase. By executive sponsorship I mean management that sets agile-transformation objectives for the teams and follow up on those objectives.
W. Edwards Deming captured the essence of executive sponsorship very nicely by stating: “It’s not enough that management commit themselves to quality and productivity, they must know what it is they must do. Such a responsibility cannot be delegated”.
Even though, after management actions, the team actually works according to the paradigm shift, it does not mean the paradigm shift has actually happened, and there is more to do, to make sure not only the behavior has changed, but rather the paradigm underlying it has settled, so this behavior will continue in the future. In order to do that, I move to the next step.
The data analysis phase
Step 5: Data gathering and analysis
Leveraging the executive sponsorship, I escort the teams through the new paradigm implementation while gathering data that would support positive change outcome (after all, this is the main purpose of a paradigm shift and adoption of a new pattern).
It is important to come back with evidence-based data that indicates on an improved outcome. This should reinforce the pattern usage and should be the good-enough evidence that the new paradigm is effective.
Gathering the data is not always trivial and should be planned carefully beforehand. It usually requires participating as an observer in team events, perform follow up sessions with team members, and analyze the data provided by various supporting tools (e.g. Atlassian JIRA in my case).
Bring it all together
Although a paradigm shift is hard, it is essential for achieving an agile mindset that will work and last. Kuhn used the duck-rabbit optical illusion to demonstrate the way in which a paradigm shift could cause one to see the same information in an entirely different way. I feel it happens all the time in agile transformations.
I found that starting with a rational explanation (theory, use-case, survey), then moving to a behavioral change, and then coming back with analyzed data (that supports the paradigm shift) for reinforcement, works well in agile transition journey.
Remember, even though rejections are "irritating", they represent involvement in the process. They want to be absolutely sure before they move on. Those that give more rejections, once you moved with them through all their rejections, will often appreciate you more, and will be the most dedicated to the process.
What is your experience on that aspect? Which methods did you find useful for a paradigm shift?