Evolving the scrum: Creating cohesive engineering teams despite distance 

With 30 years in engineering, I’m well aware of the stereotypes most people associate with the field. 

Male-dominated. Sprint-driven. Video games during downtime.

These generalized notions of engineering work aren’t without merit. They exist, in part, because they’re rooted in truth. Coding is a craft that conjures clichés. 

And while neither I nor many of my colleagues fit the above stereotypes, we’re all familiar with them. For decades, many of these clichés have self-perpetuated, as most engineering teams have been built in a familiar and time-tested manner. 

We stick to the scrum system because we know how it scales, but also because we recognize that ours is an essential output. What we produce makes the business hum. Even as the world of work evolves, the engineering field remains resolute, assured of its ability to stabilize and support the broader organization.

But modern scrum teams face challenges that force us to revisit some long-codified credos. Colocation is no longer mandatory—in fact, it’s increasingly complicated, as talent becomes further dispersed and more particular about where and how they work. Rapid rates of digital adoption mean our skills are in especially high demand, including in industries that previously didn’t prioritize engineering. 

Balancing business needs with the coder’s creed 

Contrary to another cliché that often follows engineers, I’m a people person. Specifically, I’m an Altruist: supportive, sociable, and happiest when people work in harmony.

But being an Altruist is only one facet of my identity. At heart, I’m an engineer. I’ve been on the ground, tasked with solving critical challenges from the first line of code. I want to bring technical solutions to the business, without looking at problems in black and white. 

That’s a tendency many engineers have, with good reason. We want to do what’s right for the code, as opposed to making a simple fix in the name of keeping the lights on.

As a leader, however, I need to balance my engineering instincts with what’s best for the business. I often serve as a bridge—an intermediary who’s asked to reconcile our high-level goals with the team’s desired outcomes. That’s where my behavioral type comes into play: I have to be able to communicate effectively in both directions.

Doing so requires deft care, and an understanding of the people around me. You can’t communicate with everyone the same way—especially in a remote work world. 

Sometimes that means saying to our engineers: “Do the MVP [minimum viable product] so we can go live next week.” 

It’s not always ideal—and I understand the instinct to prioritize clean code—but it’s my job to help my team understand not only why we’re requesting something within a certain time frame, but also how that benefits the business broadly.

Explaining the “why” helps with team engagement. Engineers often want to build a Cadillac, and I’m here to explain why sometimes a Ford Focus is best. It doesn’t always have to be pretty—what’s most important is that it functions properly and efficiently. 

That message can apply to any project, from frontend to backend, and to anyone, regardless of title or tenure. And it resonates most when it’s applied consistently. 

Connection comes with intention

Basic scrum principles used to include an emphasis on colocation. The idea was that teams who are in the same place tend to communicate more effectively, and thus stay more agile. 

I’ve seen this theory play out to positive effect. Earlier in my career, I worked for a payment processing company. It was a special job. I went from team lead to director, with 30% of the org structure under my purview at one point.

We built a very strong team culture, and retention with engineers was high—something I’m proud of to this day. Even when the going got tough, we stayed together. We knew each other as people, and we cared about each other. We knew we had each other’s backs. 

I tried to be a vulnerable leader with that team, just as I do now. We were attempting to penetrate adjacent markets, and it was frequently difficult work. So when we were stuck, I would say things like “I don’t like it either,” or “I need you.” 

These are simple statements. They don’t necessarily move the production needle, but they do wonders for trust within a team. I learned to lead with empathy and compassion—an understanding that supporting colleagues was more important than having all the answers—and the experience has informed my approach ever since. 

If you don’t have that cultural bond, people start to feel like they’re free agents. Today’s engineering teams have to work especially hard to create that sense of kinship, because they’re often not in the same place. That’s the new reality.

So, today’s scrum teams must be intentional about the things they can control, like career pathing and training. They have to want to care about each other. And it’s not just about relating to each other’s work. You can move the needle with the soft stuff, too. I try to know everyone’s kids by name, or when someone needs to leave early for soccer practice. 

It takes effort and genuine interest. You can’t make that stuff up—it’s either there or it’s not. The feeling of a trusting, cohesive team cannot be manufactured. 

Agility, evolved 

We’ve seen seismic shifts in labor market dynamics over the past few years. The pandemic forced many companies to adopt remote or hybrid policies on the fly, challenging some of the principles upon which scrum teams were formed. The ensuing recession has seen many tech companies—and organizations in general—rightsize after over-hiring or forecasting growth that proved unsustainable.

The Predictive Index isn’t immune to these headwinds. We recognize that the market for good engineers is robust. It’s also fickle, with greener-grass opportunities regularly enticing employees (ours included). It creates a complicated dynamic for those of us building and managing engineering teams. 

In response, we must be realistic and acknowledge that opportunities abound for some of our best people. But we also need to adjust our own outlooks. I’m grateful for how decisively PI changed its hiring practices and pivoted to an option-based policy. We source candidates nationwide, because we understand that top talent no longer considers geography a barrier to entry or impact. In fact, we have to offer flexible work situations to remain competitive, just as we offer appealing compensation and benefits packages. 

We’re willing and able to meet the best people where they are. We can work out the logistics. We can get people up to speed on our best practices from afar. But we can’t teach certain behaviors—so we identify the ones that will balance our teams, and we go after those potential additions with purpose.

I do worry about the newer members of our team (and other teams, for that matter). I’m acutely aware of how colocation can benefit culture. There’s no denying that these younger workers are missing out on certain professional and personal growth opportunities many of us had simply by spending time with co-workers. 

These colleagues may be digital natives, but professional connections can be elusive when remote work is all they’ve ever known. Many of us can help them navigate the logistics, politics, and expectations of workplaces with increasingly amorphous boundaries. 

So, it’s imperative that we make people feel part of PI, no matter where they are or where they’ve been. And you have to be intentional about that. It might mean sacrificing velocity or production so you can prioritize travel time and get everyone together on-site. It might cost you half a sprint’s worth of work, but to me, it’s worth it. 

I’m fortunate to be surrounded by leaders who understand the value of human connection. PI’s mission is Better Work, Better World, and my colleagues recognize that in order to achieve that lofty ideal, we need to not only accommodate, but also champion different work styles, behavioral types, and perspectives. 

Some businesses might shut down these efforts. But our leadership—from the CEO to the People Ops team, and on through the Engineering department—sees the return on that investment. What may be lost in production is regained in energy. Connected people will show up for each other. The payoff will show up in the form of engagement and retention. 

Envisioning a scalable way forward

Many agile manifestos are more than a decade old now. The original scrum system focused on pillars, one of which was colocation. The idea was that teams who sat, thought, ate, and problem-solved together would work better together. But the post-COVID landscape demands re-evaluation.

We have no choice but to address this new landscape head-on. It’s a challenge that coders should welcome—a complicated puzzle without an immediate solution, but solvable through iteration, intentional team building, and an embrace of what remote work has to offer. 

In many ways, we’re working faster now. But faster doesn’t always equal better. We’ve had situations where the team was moving so fast, driven by our organization’s ambitious goals, that people found themselves working on the same things. That was rarely an issue when scrum teams sat together in the same office. 

But it’s not an issue isolated to engineers. We also see it in DevOps teams. You combat it by getting organized. We button up our processes because we know that ad-hoc won’t work when we’re distributed across the country—or the world. 

We have to revisit our hiring motions. Remote work accommodations are no longer an afterthought. Now, we ask candidates—and our remote co-workers—what, specifically, they like about hybrid or remote setups. We ask what they don’t like, too. 

The answers will vary depending on behavioral styles, among other factors. Lots of engineers at PI, as with other organizations, are more introverted. That makes the traditional team sync a challenge. When we force people to join video calls with their cameras on, we risk alienating some. Intention and attention drive engagement.  

Sure, some profiles will always take more readily to the autonomy and flexibility remote work affords, but if we codify guidelines and try to accommodate people’s preferences, we can achieve results at scale. In fact, that balance is essential to evolving the scrum system as we know it. 

We haven’t figured it all out yet. But we have a good idea of what works, what we’ve learned, and how we can apply those learnings. I’m confident in the abilities of our teams, and in the resilience and agility of the engineering field as a whole.

It’s a new code to crack, and we’re up to the challenge.