If you are a scrum master or team coach, you’ve probably felt the frustration of laying out a sound set of Agile practices only to find team members lack your enthusiasm for diving in. With some people, it’s overt – questioning, challenging, complaining about the time spent planning vs coding; in others it’s more subtle – they go through the motions but don’t bring their full selves. They remain silent in planning and retrospectives, and give perfunctory updates in standups. Task estimates are more the CYA type, and in general they put as much energy as they can into maintaining the old ways in the new container. As a coach I’ve seen this across all roles – developers, analysts, testers, even scrum masters.
All coaches have their own ways of dealing with these issues, and they vary a lot in both approach and effectiveness. Some rely on listening, in 1:1s and retros – some are more firm, laying down the law. Others seek to find common ground, modifying the practices to be more palatable. All of these techniques can help address the specific concerns and lead the team to smoother operation, ensure the team data is current, improve readiness, quality and velocity.
Agile without agility
What can be missed in this give-and-take alignment of people to the practices is the deeper work of helping a team – and the individuals that make it up – develop a truly Agile mindset. Through hard work, it’s possible to reach a point where you are hitting all the marks on your maturity assessments, without capturing the real power that brought Agile to the attention of the industry 20+ years ago. I call this Agile without agility, and the reason it happens is not different than the reason certain pernicious software bugs persist despite attempts to fix them – the focus is usually on the visible aspect of the problem, without understanding the root cause of the issue.
To unpack this, let’s reflect on Agile’s origins – where did it come from, and how did it arise?
A brief Agile origin story
Back in the ‘90s (and earlier in some places) a bunch of talented software engineers and leaders working in different places recognized that the prevailing command-control, predictive process control (“waterfall”) management practices were not producing good software results. These were highly skilled professionals, yet when you assembled them into a team they produced poor results. They began to question the existing ways of working; to “uncover new ways of developing software by doing it and helping others do it”.
I was fortunate to be on some of these early teams, and the spirit with which we experimented with short development cycles, self-testing code, incremental design, refactoring and improving previous deliverables was exciting, new, scary, and kind of rebellious; we were operating at, or beyond the limitations placed on us by management. We would present our successes to management, together with our customers who were “in the room” with us as much as possible and had unprecedented visibility and involvement in our day to day decision process. Not all of our efforts brought success… but those that did really stood out. Projects that initially appeared to be way over budget were brought in under cost, with more and better features than initially planned. This was happening all over the industry, in pockets, and being written about on USENET (kind of like reddit) and magazines like The Smalltalk Report, Software Engineering Journal and others (what we now call blogs ☺). And eventually, people started to hear about these practices in other companies, write books and create frameworks to guide others, and finally many of these people came together in Snowbird, Utah to agree on a unified set of principles we now call Agile.
What kind of people created Agile?
The reason I’m telling this story is to highlight the attitude and motivation of the early adopters of what became Agile. Each team member, leader and customer was:
- Motivated by a recognition that “what we have been doing is not working well enough”
- Committed to finding a better path to success
- Willing to break rules to find it, even at personal career risk
They did not need to be convinced, cajoled, or aligned with a new process – they were process innovators, experimenting and refining what worked and sharing it with each other. And many of today’s Agile leaders, Scrum masters and Coaches come from this same DNA – they “get it”, see what is possible, and we want to share it so that others can be similarly empowered to find what they have found – the power of true agility.
As we begin to share it, by setting up practices and processes, training team members, and running sprints or Kanban boards, we smack into what we call “resistance” again… somehow the things we are teaching and facilitating are not creating this same excitement – it’s a different set of emotions. It feels messy, like herding cats, and it can be surprising and frustrating. We call it resistance because that’s how it presents, but the root cause can be more fundamental, and understanding this can help us “transcend”, rather than “break through” it. We can break through an obstacle, and may achieve our immediate goal of compliance or understanding … but only can when we transcend it can we achieve what we are truly aiming at.
Transcending resistance
To transcend resistance, I use one of the tools from Integral Theory – the 4 quadrant perspective. Essentially it invites us to look at any aspect of an Agile from two perspectives: Internal/External and Individual/Group. Crossing these perspectives gives us 4 quadrants.
This diagram shows that any subject (what Integral calls a Holon), such as a Team or Individual, can be seen from within (subjective, interior perspective) and from the outside (objective, exterior perspective), as well as from the perspective of the subject itself (the individual) or from the context (or holon) it is a part of.
All four perspectives are complementary, rather than contradictory. Each by itself offers only a partial view of reality. Together, they allow us to thoroughly understand what we are observing, by building a picture from multiple perspectives and thus have a better chance to uncover the root cause.
Applying Quadrants to Team Resistance
Now let’s apply this to resistance – specifically resistance of individuals on a team. The external (observable) aspect is “Diana is not giving thoughtful task estimates”, or “Gregg is giving perfunctory, not team-oriented standup updates”. We can fix that problem on the external side by explaining, cajoling or insisting that the process be followed. And if it truly is a matter of lack of understanding, then the root cause and the perceived problem are both in the same quadrant so the intervention will likely be successful. But what if the cause is on the left (internal) side? What if there is a mismatch in beliefs, values, trust, safety? Then we will only get compliance without buy-in, and agility will remain elusive.
To make this concrete, let’s contrast the motivations and background of the initial Agile innovators to those of the team members who today participate in Agile transformations.
Most modern Agile transformations are a set of culture and process changes initiated by management to alter the capabilities of an organization or set of teams to achieve measurable improvement, or at the very least, buzzword compliance. They are initiated by the organization, and brought to the teams as the new direction. Team members usually have been working in the organization for many years, and while they may see, to a greater or lesser degree, the limitations of the existing processes, they have addressed these by adapting themselves to the status quo, and have learned how to succeed by making the best of it, sometimes with high degrees of success. They
- Know how to work the current organization and process to achieve their goals. The status quo “works for them”.
- Understand what will bring recognition or place themselves at risk
- Are reluctant to break rules, rather they work within the rules to smooth out obstacles
These are the polar opposites to the motivations of the Agile innovators, and to the coaches that come from their DNA and are inspired to spread what they have discovered.
This is fine, and necessary when you are at the forefront of change in an industry. Geoffrey Moore explores this phenomenon in depth in Crossing the Chasm where he points out that the motivations and risk tolerance of the early adopters and innovators are diametrically opposed to those of later adopters … and that companies that fail to recognize this by adapting their approach risk falling into the chasm between these groups.
Falling into the Agile chasm
Without this awareness, it’s really easy (it’s happened to me more than I care to admit) for a well-meaning coach or scrum master to blunder in changing everything. Essentially the implicit message is: “Hey I’d like you to stop doing a lot of the things that you’ve discovered work for you in your career and this organization and instead try some stuff that seems kind of edgy … you won’t be able to keep the things (like detailed up front designs, BRDs or padded estimates) that have protected you all these years from looking like a failure; instead you’ll have to be transparent with your team members (who you might not trust) about what you do and don’t know. And, by the way, every 2 weeks we’ll showcase what you’ve done to your big scary customer who’s the main one you’ve been protecting yourself against blame! Oh, and if you don’t listen to me, I’ve got the ear of your boss and you’ll be labeled a resistor”. Aaaack!
An Integral approach to overcoming resistance begins with inquiring into the upper left quadrant of the team members … to discover what motivates them, what they believe in, what level of trust they have in themselves, other team members, and management. Once we discover this we can now begin to bridge the Agile practices that may have seemed daunting at first to the true concerns of the team member.
Putting it all into practice
I was working with 3 teams in a biotech company a few years ago, and I ran straight into a mix of both passive and overt resistance. On the one hand, the team was more than willing to hear about better and clearer ways to author requirements with their customer, since they were having problems in this area. But the team members overall, and the technical lead in particular, were not at all open to sprint planning, daily standups, or end of sprint demos. They gave a lot of overt reasons – time, dependencies beyond their control, and the specifically rigorous nature of the software (they were working with lasers in mass spectrometers). Initially I went down the rabbit hole of addressing these concerns specifically. But the more problems we solved together, the more objections they would present.
I realized I was playing “whack-a-mole” on the wrong side of the Integral quadrant, so I pulled back and began to talk with team members individually about what it was like to work in their organization, focusing on how they felt about themselves and their other team members. I discovered that the technical lead did not trust the rest of the team to do their jobs properly, but he was deeply invested in the success of the product and company – so much so that he would remote-in to review and re-write their code on a nightly basis! This was a very strong signal so I dug deeper, eventually having dinner at his house. He asked me a lot of questions about the WHY of Agile, as opposed to the HOW I had been focusing on. At some point in the evening the light bulb went on and he realized that sprint planning and daily standups would help him guide his team technically, by making visible the key activities each day and helping him evolve from supervising/correcting their work to mentoring and supporting them with his technical knowledge. The next day his energy had shifted completely and in the ensuing weeks he became one of the Agile champions helping to drive the transformation. Months later, the project was humming along and even beginning to project Agile leadership into the other teams with which they interacted.
By recognizing the signs that I was barking up the wrong quadrant, so to speak, I was able to pull back and consider all angles of the problem. If I had stayed the course I probably would have managed to cajole everyone into doing the right activities, and in time they would have habituated to them, maybe even come to like them. But this Agile transformation would have lacked the power of belief from within, and I am certain it would have stagnated at a much lower level of agility.
Further down the rabbit hole
There’s much more to cover – I’ve only discussed team-level resistance seen on Teams here. Stay tuned for further installments of this series where we will apply an Integral perspective to the Team of Teams, Organization and Enterprise levels. And if you’d like to dive more deeply into how Integral Theory can make Agile transformations more effective, checkout this interactive guide.