Agile is a flexible project management philosophy that emphasizes iterative progress and adaptability to change, while Scrum provides a specific framework of practices and roles to implement these principles—together, they offer laboratories powerful tools for managing complex, evolving research projects. Following his comprehensive webinar on implementing Agile methodologies in laboratory settings, communication consultant and leadership expert Sean Grace fielded questions from participants about practical implementation challenges. Drawing from his 25 years of experience developing talent across industries, Grace addresses key concerns about KPI development, regulatory compliance, stakeholder management, and the effective use of tools like Kanban boards. These Q&A exchanges highlight the importance of short feedback cycles and team collaboration in advancing scientific projects.

Lab Management Certificate

The Lab Management certificate is more than training—it’s a professional advantage.

Gain critical skills and IACET-approved CEUs that make a measurable difference.

Q. What metrics or KPIs can be used to measure the success of Agile methodologies in improving efficiency and team engagement?

A. What's great about Agile Scrum is that it's a collaborative team effort in defining what the KPIs are. You need to determine what you're trying to accomplish and what the definition of “done” is. It all depends on what you're trying to do. If it's a matter of just improving lab processes—maybe it's not a specific project that is related to an outside client—then you have to [ask yourself], “What do we what are we trying to [accomplish]? Let's define that through our KPIs. But if it's an external product, you have to determine what is going to indicate that's finished—and [those parameters] are your KPIs to determine if it’s moving forward or not. There’s a tremendous amount of variability in how you define KPIs.

Q. How can Agile methodologies be balanced with the need for strict compliance and documentation in highly regulated environments?

A. [Regulatory compliance] is certainly one of the bigger challenges in the sciences . . . but that shouldn't change your decision to adopt Agile Scrum; you have to adopt it within the strictures and constraints that you that you may have already. What I love about Agile Scrum—and I emphasize this a lot—is the “mindset” aspect of it more so than the methodology. However, the methodology and framework [are] important because they give you a way in which to achieve those goals. But again, [there is] tremendous flexibility in how you do that. You're just going to have to make sure that the compliance and documentation aspects of what you're doing are followed through as usual. [Essentially], you're just going to be overlaying [your lab’s preexisting processes] the Agile Scrum framework in order for your teams to be more efficient.

Q. What are the similarities between Agile Scrum and design thinking?

A. I would say there's a lot of similarities. Design thinking is human based. It's about creating products and designing products for actual use. So, Agile Scrum actually works quite well in the Design Thinking arena. Design thinking is a framework for innovation and development, and it's very much attached to the question of, “How is this going to affect an actual human?” And there's stories involved [in design thinking and Agile Scrum] as well, [as in] [insofar as] trying to convert an abstract product into an actual value or benefit. So, I think they work very well together. And it's an excellent question, because I never quite thought of the two being together, but the more I think about it, they are quite compatible. [Again,] I would say there's a lot of similarities, especially from the human centric standpoint, and the ability to be adaptive as you move through the iterative design and development process. [Like Agile,] design thinking isn't a big believer in phase, gate, or waterfall project management. It's more about empowering the engineers, designers, and developers to make decisions on their own to deliver a product with value.

Q. Sometimes a stakeholder has a different timeline than what is realistic. How might this play out in an Agile Scrum environment?

A. Yes, and I think it's another great question, because Agile fully acknowledges the failure aspects of any process, whereas traditional project management doesn't. Often, traditional project management lays out a perfect plan on a Gantt chart with benchmarks and milestones and [gates]. But what's beautiful about Agile Scrum is it gives you that quick ability to not get stuck with long-term plans. So as far as the stakeholder goes, I think it's important that the stakeholder be very much involved. Now, they may not be directly involved, depending on who they are—if it's an outside client, they may not be involved in the planning stage of the sprint—but communication is important so they have a realistic understanding of what's involved. That's where the story points come in, too, where you're weighing the actual weight of a task and not giving it a one to 10, but giving it a 13 versus a two. And if you can communicate that back to the stakeholder, they'll have a better understanding of what it [really] takes to execute this issue. And with the constant feedback loop, you're constantly reporting back and saying, “Okay, here's where we thought we'd be, but here's where we actually are. But that's okay, because we're moving it along in a very efficient way.” So, stakeholder communication is key.

Q. How do you ensure that you’re moving forward and not stuck at a certain point in the project?

A. Well, that's where the Kanban board comes in. So whatever sprint you're on, [or] whatever task you're working on, will be fully visible as to where it is. Your daily stand ups and your weekly quick reviews will give an opportunity to discuss why a task or a sprint is getting stuck, and then you'll have to figure out a way around that. What's beautiful, again, about Agile Scrum is [that] it forces this continual examination by everybody [on] the team to take a look at what's going on, where things are at, and why things are the way they are, versus more conventional processes where you'll have a project, and then an individual goes to their particular area, they work on it by themselves for a long time, and then a month or two later they come back, [receive] some feedback, then they go back [to working].

And although that has its place, you lack that regular, iterative, short feedback cycle. And the short feedback loops are really critical in identifying what is stuck and why in the Kanban board. I really emphasize the actual, physical board with stickies on it. There's something about that different than, say, a digital board, where you actually have to move something from one to the next. And as you're doing that, you have a certain attachment to the whole process, and everybody could take a look at and say, “Oh, I see why that's stuck, because that project is dependent upon task D, and task D hasn't left backlog yet.” So, these are some of the things you'll discover when you have everything on the board.