Twenty-one years ago, 17 software engineers published the Manifesto for Agile Software Development, more commonly known as the Agile Manifesto. Responding to the bureaucratic waterfall model of software development, with its linear phases and heavy documentation, these engineers advocated a more flexible approach, one that could adapt and succeed in a highly dynamic environment.
That simple declaration of values and principles has since spawned a global movement that has gone far beyond software development, gradually expanding to include under its umbrella a broad set of tools, processes, and functions.
Agile has fundamentally changed the way we build software. In my organization, for example, we scrum, run sprints, and far outperform the pace of development from the past. During the last 20 years, the agile movement has gained astonishing momentum, even outside of software development. There’s agile HR, agile project management, agile customer service, agile sales, agile operations, agile C-suite, and so on.
Thousands of organizations can testify that their agile efforts have paid off in terms of speed, quality, value, and long-term growth. But not everyone can say that — in fact, approximately half of organizations that undertake agile transformations fail in their attempts.
If your team has yet to reap the rewards of agile, you need to understand what’s preventing you from delivering the fast, frictionless, scalable solutions you envisioned. After evaluating several agile teams and conducting a series of interviews with leading agile experts, I believe the primary factor is disregard for the first value of the Agile Manifesto: “Individuals and interactions over processes and tools.”
Processes and Tools are Scaffolding
Agile processes and tools provide support, but the central weight-bearing mechanism of the agile approach is not the scrum or the sprint. Rather, it’s the team’s dialogic process — the way team members interact — that ultimately determines success. The dialogic process informs how the team harnesses intellectual friction (i.e., conflicting ideas) to perform interdependent work. Are team members able to give and take, push and pull, talk and listen, question and answer, act and react, analyze and solve? Or do they censor one another and end up in self-preservation mode? In essence, agile’s core technology isn’t technical or mechanical. It’s cultural. Agile teams ultimately rely on psychological safety — an environment of rewarded vulnerability — to have a collaborative dialogic process.
High psychological safety elicits a performance response with innovation as the goal, whereas low psychological safety elicits a fear response with survival as the goal. When team members stop asking questions, admitting mistakes, exploring ideas, and challenging the status quo, they stop being agile. How can a development team perform rapid prototyping, for instance, if it’s swimming in fear? Or how can an HR team make equitable candidate selections if they can’t safely point out actions that may be inadvertently driven by bias? To borrow a line from William Butler Yeats, without psychological safety, “things fall apart; the center cannot hold.”
When giving candid feedback, exploring unconventional ideas, and dissenting from the majority become sources of punished vulnerability, people stop doing them. How do you punish vulnerability? You criticize, embarrass, discourage, silence, shame, trivialize, bully, and intimidate. At that point, the team’s dialogic process breaks down and may ultimately collapse.
For example, I sat in a scrum meeting with a product development team that was in the middle of a two-week sprint. Unfortunately, the team was missing the core technology of psychological safety. Guarded and focused on self-preservation, the team ultimately failed because the dialogic process fell apart. As it became more emotionally and politically expensive to speak up, they gradually stopped doing it. They sabotaged their agility by punishing each other’s vulnerability. After the team was disbanded, I conducted a formal postmortem and interviewed each of the nine members. Ironically, every member of the team had been extensively trained in agile processes and tools, but those processes and tools couldn’t save them. Only psychological safety could have done that.
Here are five practical ways to increase psychological safety to foster a collaborative, successful agile team.
Frame agile as a cultural implementation.
Soon after implementing agile, many organizations revert to the default position of worshiping at the altar of technical processes and tools, because cultural considerations seem abstract and difficult to operationalize. It’s easier to pay lip service to the human side and then move on to scrumming, sprinting, kanbaning, and kaizening because these processes serve as tangible, measurable, and observable indicators, giving the illusion of success and the appearance of developing agile at scale.
Begin your agile transformation by framing agile as a cultural rather than a technical or mechanical implementation. In doing so, be careful not to approach culture as a workstream. A workstream is defined as the progressive completion of tasks required to finish a project. When we approach culture as a workstream within the context of agile, we classify it as something that can be completed. Culture cannot be completed. Yet I see agile teams attempting to project-manage it as part of the work breakdown structure, as if it has a beginning, middle, and end. It doesn’t.
Remember, there’s always the risk that a team’s culture will snap back to fear-based norms, so focus on individuals and interactions as the highest priority. Small and seemingly insignificant acts of disrespect, rudeness, or indifference can push a team back into withdrawal and personal risk management. If a team can identify and manage detailed behavioral terms of engagement, such as, “let people finish their thoughts without interrupting them,” they quickly become norms the team upholds through peer-based accountability.
Develop, document, and display vulnerable behavior/response pairings.
Hold a formal discussion with your team to identify the vulnerable behaviors they believe will be crucial to success. Team members will most likely begin by identifying common behaviors like asking questions, giving feedback, or registering different points of view. Keep going until you flesh out a longer and more nuanced list. Then identify positive response patterns for each behavior. For example, you might identify pointing out an error as a vulnerable behavior and then saying, “Thank you for pointing that out. What do you think the root cause is?” as a positive response to it.
Document the behavior/response pairings and display them in your meeting room. If you’re running a virtual team meeting, post them in the chat. Consider the list a living document and revisit it in your sprint retrospectives. Create a printed job aid of the list that team members can carry with them, and provide a digital version that acts as a prompt and guide in virtual meetings.
Focus on one behavior during each scrum and practice cultural accountability.
Now that you’ve jointly produced a list of vulnerable behavior/response pairings, pick one to practice during each sprint. When the team focuses on a specific behavior and response pattern, it provides a manageable scope for practice and activates peer-based cultural accountability.
If a gap emerges between the vulnerable behavior/response pairings and the team leader’s own modeling behavior, that dissonance will breed cynicism and erode credibility. But if the leader strives to model the behaviors and publicly acknowledges mistakes along the way, the team will make cumulative progress. The leader must make it clear that the members of the team are responsible for holding each other accountable for performing and rewarding vulnerable behaviors.
Formally evaluate your dialogic process in the sprint retrospective.
Set aside time during the sprint retrospective — the meeting held at the end of every sprint to review what went well and what could be improved — to formally evaluate the quality of the team’s dialogic process. Make this review a standard part of the agenda.
Discuss the quality of the team’s interactions and identify potential threats to openness. Ask questions like: Did you feel included in the process? Why or why not? What was the most vulnerable behavior you engaged in during this sprint? How did the team react to it? Was there anything you didn’t say or do because you didn’t feel safe? Does the team display a democratic pattern of participation and influence? Why or why not?
Conclude your scrum with a “question/reflection.”
Scrum meetings are meant to be fast-paced, daily coordination meetings in which team members review the backlog, identify obstacles, and prioritize tasks. We often do them standing up to keep them short. Though they’re not meant for brainstorming, you can use them to create time for reflection between meetings when necessary.
For example, if a team faces a difficult obstacle, pose a question about the issue and ask the team to come to the next scrum meeting prepared to discuss it. This approach offers more time for team members to crystalize their thoughts and encourages them to engage in divergent thinking. Reassure your team that you want to hear gut instincts as well as data-supported options.
. . .
If you drop agile tools and processes into a legacy culture that punishes the very acts of vulnerability required to be agile, you will fail. Environments of punished vulnerability — i.e., low psychological safety — leave organizations agile in name only, like the talented team that stalled and then failed.
If a team is struggling in its agile transformation, shadow it. Evaluate its dialogic process. Are members respectful? Do they tolerate candor? Do they protect and reward vulnerable behavior? If the answers to those questions is no and members are touchy, temperamental, or territorial, you’ve got work to do. You may be blessed with resources, expertise, and mastery of technical processes and tools, but ultimately, being agile relies on the ultimate enabler — psychological safety.
citation