Agile Concepts in Academia, Part III: What Can Agile Do for Me – Really?
In the first two posts about Agile and EBM, we focused on history and theory. In this post, let’s get real.
At our Brown Bag in August 2022 we talked about a simple visualization tool called Kanban and gave a few tips on how to use it in a team setting. That talk barely scratched the surface of this powerful visualization tool, and some viewers reached out afterward to look for ways to apply the tool to their specific situations. This exposes a main strength and drawback of Agile methods and tools – they are almost infinitely adaptable (the power of the pivot is built in, after all). And the Agile community has been generous with both the tools and knowledge. There’s a wealth of free content at Agile Alliance and other sites.
It’s a real challenge to sort through all of this to find the tools that offer the most benefit with the least overhead or churn. ATG aims to help you think about this through the lens of the problems you might be trying to solve, on a daily basis, in your individual work and with your teams.
It’s helpful to start with a scenario. In our Agile Project Management workshop, we use a realistic one to demonstrate multiple aspects of Agile practice, focusing on two key areas:
change (or risk) management
communication and meeting culture
You can come up with your own scenarios where Agile practices could prevent or mitigate problems. For example, your project has fallen behind somehow. How can you discuss it without pointing fingers? Or there’s one person who consistently derails your planning calls. Or you have trouble determining what your biggest future challenge might be in a long-term program. Whatever questions you’re facing, there’s probably an Agile tool to help you. Start with your “why,” and then you can think about your “what” and “when.”
Here’s a quick example: Your team is going for a challenge grant – perhaps a collaborative project that spans multiple disciplines or even institutions. The provost and project director tasked you with creating planning meetings between investigators, community partners, and sponsors.
What is your biggest “why” as the planner of the meetings?
It might be to demonstrate that you have the right partners to get the work done. In this case, use the Agile tools of Stakeholder interviews and user stories to find the right participants at the right stages. A Lean Canvas may be useful to identify information channels and hone in on the actual problems you’re solving for.
It might be to identify the top three challenges the team will face in the first, second and third year of the award to demonstrate a flexible strategy and mitigations. You can use a “risk register” and round of Planning Poker to surface ideas, and vote on their overall importance.
It might be planning meetings that drag interminably without actual plans being formed. You can use Agile meeting formats to make sure all voices are heard in an equitable way.
You may face all these challenges at one time or another. If you choose to roll out these Agile ideas and strategies, starting multiple new work methods all at once will likely not go well. We recommend employing the Agile strategy of inclusion while deciding where to start and follow a hypothesis-driven, evidence-based approach. Be very clear in your communications to the team that these are experiments, intended to make everyone’s work a little (or a lot) easier. Start with something easy to try, and easy to change if it doesn’t work. Allow people to question the process and be willing to fail. Failure is often where you learn the most, as long as you gather your data along the way and pivot thoughtfully.
Large group meetings serve as a good place to start. Make sure the expectations are clearly defined (“In our next meeting, we are going to try a new way to facilitate”) – and let them know what to expect. When you apply Agile meeting principles, you may see how people tend to be relieved when the Repetitive Monopolizer gets gently redirected or the Silent One Who Actually Knows Everything gets to talk for once. And if it doesn’t end up improving things after all, you can solicit feedback and try something else.
Below are a few articles from other sources that go into more detail about the ideas we presented in this post.
Stakeholder Management - Focused on software development, but has intriguing thoughts for any collaborative effort.
Agile and Change Management - A recent and thoughtful essay from Harvard Business review.
Agile Meetings - Advertises a course, but offers many good suggestions in the free article.
If you would like to do a deeper dive, contact us to be notified of our next open-cohort workshop, where we go into more detail and provide hands-on experiences.