In this blog series, Jason Larson, head of content at IIA, sits down with IIA experts who serve as sparring partners for Research and Advisory Network clients. IIA’s RAN expert community, with over 150 active practitioners and unbiased industry experts, is dedicated to advising data and analytics leaders on key challenges unique to their enterprise.

With four agile transformations spanning his career, Greg Nelson, vice president of data operations at Highmark Health, knows something about instilling a product-centric mindset at large, complex organizations burdened by legacy systems and processes.

This conversation explores agile transformations at the team level and across entire portfolios and addresses the often-underappreciated aspect of cultural adaptation necessary for true agile integration. Greg unpacks the layers of agile implementation, from securing early wins to reshaping organizational mindsets and incentives, providing a roadmap for leaders looking to adopt an agile approach to data and analytics.

Agile has been around for a while, especially in software development. But it’s also becoming a staple for data and analytics leaders like yourself, adopting agile methodologies to bring more product-oriented thinking to D&A work. So, why agile? What about agile frameworks appeals to you more than the traditional waterfall method?

Greg Nelson: When I think about product-based agile execution frameworks, I picture agile as one leg of a three-legged stool within data and analytics. The first leg is about getting things done (the execution framework)—making sure our teams work well together, everyone knows what's going on, and we're consistently delivering on outcomes.

The second leg is about adopting a product mindset. Whether developing for commercial or internal purposes, we solve problems that create sustainable value over time. For me, this is about building durable solutions that solve systems of problems for the people using them.

The third leg focuses on the human element of our work. Take an example from healthcare, “the no-show report.” This report typically shows which patients didn't make their appointments. But really, it's just looking backward, not changing anything moving forward.

If we switch to a human-centered approach, we start digging deeper. Instead of asking who didn’t show up, we ask why. We start peeling back the layers to understand the underlying issues. Is it about improving the right staffing mix or ensuring people get the care they need? Why is that important? How we frame our problems necessarily determines the outcomes we’ll try to solve. Whether this might be to ensure access to care or to lower the cost of care, a human-centered approach helps us see beyond the data to the human impact of what we're doing.

Thinking about products is good, but without the human context, it’s incomplete. That’s why these three aspects—execution, product mindset, and human-centered design—need to work together, just like the three legs of a stool.

That makes sense, especially the bit about the human-centered approach. You mentioned looking at demand through the lens of your data customer. That’s a key thread to IIA’s DNA, helping data and analytics leaders shift the focus from the supply side of the house—the tools and technology—which is where the comfort lies, to really tuning into what the demand side needs. Can you talk about how agile has helped you make this shift? Are there specific examples where agile has fueled this change, making it a key part of your strategy?

Greg Nelson: First, agile improves quality, alignment, execution, and transparency, which zeroes in on what the business needs to achieve. However, a common pitfall is when agile efforts stop just at the team level. Just because a team is ticking off all the scrum ceremonies and working off an active backlog doesn't mean they're necessarily doing the right things or working in the best way. It just means they're executing within two-week sprints.

There's a misconception that agile means you don’t have to document or that we don't need to plan, which isn't true. Planning needs to be more intentional and at higher and higher levels to ensure the outcomes are prioritized. What's often missing is consideration at the program and portfolio levels. That's where methodologies like the scaled agile framework come into play. Here, we develop lean business cases at the portfolio level and map strategic priorities to value streams. Without tying our work to what truly matters to the business, we could be busy doing the wrong things all day—efficient execution but missing the desired business outcomes.

Scaled agile provides us with a framework to discuss with our customers and help with prioritization. You’ve likely heard the adage: if everything is important, then nothing is important. This framework helps us prioritize properly and bring work to people rather than people to projects. In traditional project-based data and analytics work, we often see teams massed together for a project and then disbanded once it's complete, and we miss the opportunity to treat products with the durability we want in true products.

Scaled agile changes that dynamic. It allows us to keep teams stable and bring the work to them, focused on portfolios that can shift as business needs change. When strategic priorities shift within a portfolio, we can pivot quickly without massive upheavals. This is true business agility—avoiding those big ripples when companies lay off hundreds only to hire thousands elsewhere. If we were fully agile, we could shift our focus without needing such drastic changes.

You've been at this for quite some time, this being your fourth stint leading an agile transformation, right?

Greg Nelson: Yep, that’s right.

And you make it sound so easy, but I know it’s far from it. I’d like to dig a bit deeper into one of your earlier points—about agile sometimes getting a bad rap because it can stall at the team level without reaching into the portfolio level. That shift seems like a huge hurdle. How do you manage to get over that in an organization?

Greg Nelson: Honestly, I'm less worried about the business side. Every organization I've worked for has embraced a relentless focus on outcomes and the core values of quality, alignment, transparency, and flow (or execution). It's more about adopting a new language and meeting people where they are, which we can manage with good conversations and strong relationships.

From my experience, the real stumbling blocks are on the supply side, more specifically, the “soft skilling” and leadership mindsets on the D&A team. How do we shift our thinking toward product-centric, human-centered design and execution patterns? We're traditionally aligned vertically within HR and management roll-ups, and now we're asking people at various levels, like managers, directors, and EVPs, to adapt to new roles.

For instance, a VP in our organization might become a portfolio owner, overseeing a whole area like clinical data strategy. That shift is more straightforward for some than others. At the VP level, they leverage their expertise to engage strategically rather than getting caught up in daily escalations.

The challenge is more acute at the manager and director levels. Managers are used to managing large teams directly, but now their role is less about directing daily tasks, which are now handled by product owners and scrum masters. This can lead to a sense of identity loss as their jobs transition to focusing more on outcomes, transparency, and the value their teams bring to the business rather than day-to-day task management.

The key to adapting successfully is embracing this shift toward a business outcome mindset and human-centricity. It’s about caring for the professional growth of their teams more than managing their daily tasks.

This transition can be smoother in startup environments because there's no legacy to contend with—we start with a clean slate. But in larger organizations, people still have their old accountabilities. You can’t just rip off the band-aid. It’s a gradual transition as part of the broader transformation.

You've touched on some important aspects of change management here, especially how it impacts teams and middle management. Could you dive a bit deeper into other key elements of change management that are important to consider when transforming a team to an agile way of work?

Greg Nelson: There’s a lot to unpack with change management. One analogy I like to use is my woodworking hobby. I love building fine furniture. If you judged me by the quality of my projects, you’d see I know my tools and what I can produce in my workshop. But if you told me to build something in someone else’s shop, I’d be a tad freaked out as I wouldn’t know what tools I had to work with. I’ve grown accustomed to the type of tools in my shop, where they are, how they perform, and so on. This is what people often experience in their work lives as we’re replacing their comfortable surroundings and giving them new tools and language and they are expected to perform at the same or better levels than before. It’s a great way to illustrate that change is deeply personal. Change management is not an organizational challenge, it is an individual challenge.

It’s essential to start with clear role expectations. Everyone needs to understand not just what their job entails—the deliverables, outcomes, and typical day—but also the tools they’ll have to do it effectively. It’s about knowing what decisions they can make and when to collaborate with others, like scrum masters, product managers, or business owners.

In change management, we often overlook the importance of role clarity, decision-making authority, and aligning everyone’s understanding. We hesitate to spend time documenting these details, but they are fundamental in helping people navigate change. Knowing your role, how you’ll be evaluated, and your responsibilities to your teammates.

Previously, a manager might get promoted and gain HR responsibilities by simply telling people what to do. Now, we’re shifting to a model where we don’t manage people directly under us in the same way. Product teams are highly matrixed, meaning you could be responsible for upskilling people and overseeing their productivity without them directly reporting to you. This creates a gap in how we traditionally manage and lead, which larger organizations often struggle to bridge without proper documentation and management training as well as performance evaluation and incentive processes.

You’ve talked about the importance of role clarity, documentation, and how product teams operate in a matrix setup, especially in a legacy enterprise setting. Have you adjusted the competency models you use and how skills map to those models? Could you break down a few practical steps for reshaping competency models and aligning skills with those competencies?

Greg Nelson: Absolutely. Back in 2018, I actually covered this topic in my book when I started discussing product management for data and analytics teams. In that book, I introduced a competency model where we defined what proficiency looks like at different levels for these roles. For instance, a data engineer might see career stages like associate, staff, senior consultant, principal, and fellow.

In product management, the levels might include associate product manager, product manager, senior product manager, and group product manager. The expected proficiencies at each level cover domains like understanding requirements, using tooling effectively, and evaluating and grooming the backlog.

These competencies are distinct from those you'd expect from a data engineer. So, part of what we've done recently is overhauling our job families and roles, clearly defining the expected proficiencies at every level. This way, everyone knows what excellence looks like in their role and what they must aim for. Having these clear benchmarks is critical, especially when transforming roles and expectations within an agile framework.

Can you talk a little bit more about resistance points that you've experienced when transforming your teams to agile?

Greg Nelson: In every transformation I’ve been through, there's always this challenge where everyone knows who the best team members are; naturally, they don't want to lose them. Instead of focusing on a team-based approach where everyone gets to grow and improve, you find people hoarding their star performers.

Another resistance point comes from agile purists. Whether it’s scaled agile or another methodology, they insist there's only one "right" way to do things. I appreciate standards—like using consistent language in scaled agile so everyone’s on the same page. But often, there’s a reluctance to adapt these methods to fit the specific context of our work.

Empowering teams is a big part of agile, and that makes some managers uncomfortable. It’s like letting your kids make their own decisions—it's necessary, but you need to be prepared for the mistakes that come with it. Some purists push to let teams run with full autonomy, but that’s not always practical. I’m still accountable for my team's outcomes, so while I support empowerment, it must come with certain guardrails.

We also need to navigate the organization's political and social landscape. For instance, while product managers should have direct access to executives, how and when they interact needs careful handling. We wouldn't immediately throw a new associate product manager into a high-stakes meeting. It’s about easing them into these roles responsibly.

So yeah, these are some challenges—managing resistance not just by adhering strictly to agile principles but by adapting and integrating them thoughtfully into our organizational culture.

Funding and other incentives obviously play a significant role in agile transformations. But how so at the practical level?

Greg Nelson: There’s a saying that no man is an island, right? The same goes for agile and product teams—they must operate within the broader context of an organization’s established incentive structures. These might dictate what gets prioritized, who gets attention, and where the funding flows. Organizations are built for stability, and any attempt to shake that up will stir some resistance—what I like to refer to as organizational antibodies that seek to destroy the elements that threaten stability.

We need to tread carefully, even down to the language we use. For instance, some parts of an organization might resist the term “product” in data contexts if they traditionally control product definitions elsewhere. That’s why I emphasize a product mindset about shifting perspectives more broadly.

Now, when it comes to incentives, as a recovering social psychologist, I see things a bit differently. Behavioral economists like Chip and Dan Heath discuss how to subtly guide people toward desired behaviors and influence rather than demand.

In product teams within agile frameworks, it’s less about blunt incentives and more about nurturing new identities. Teams often name themselves, which can be quite creative and empowering. We’ve had names like the JusticeLeague for our digital front door, or Serenity for stable API delivery, and even The InteGREATors for a team handling interoperability work. Watching these teams form, storm, norm, and perform is fascinating. This identity formation is a vital part of their journey and performance.

To put a bow on this excellent conversation, give some friendly advice to the Greg Nelson going into his first agile transformation. What are the top three things you would tell your former self to do to get started?

Greg Nelson: To start, keep it small. Initially, you should focus on a couple of teams to create some bright spots—secure early wins. That's crucial. Secondly, ensuring everyone knows they have a seat on the bus is important. They need to be clear on their roles and expectations and understand that this is a journey of continuous improvement.

Third, always measure according to your outcomes. If people are clear on the goal or target, they’ll have flexibility in how they contribute to reaching it. It's about giving them options and utilizing their strengths to help the team and enterprise succeed.