Agile Concepts in Academia, Part I
Team Science is a familiar phrase and Strategic Doing is becoming a bit more common in the academy as a way to initiate Team Science-based projects using Agile practices. Agile practices and evidence-based management* emphasizes skills and methods translated from the business world into active and effective management of research projects—turning the ideals of Team Science into reality. This series of blog posts will explore the similarities and differences between some of the tools and philosophies that broadly fall into the category of “Agile Management” and unpacks ways to apply them to your work.
*This phrase has a very different meaning than “evidence-based medicine”, where clinical choices are based on the published literature. By contrast, “evidence-based management” means managing based on the evidence in front of you. Did an approach not work before? An evidence-based management approach would be to find out why and modify. It’s related to the continuous improvement philosophy of LEAN approaches.
Part One: The Twin Pillars of Agile: Inclusion and Iteration
“Agile” is one of those business buzzwords that is making its way into Academia. In this post, I will attempt to peel away the jargon and mythology to focus on the aspects of Agile that can have the most impact on the daily work of an academic, whether a single investigator, the head of a center, or an RD professional: the best practices we have learned that don’t rely on your specific position in a research group. These practices can be loosely grouped into two alliterative and easy to remember headings: Inclusion and Iteration, which reference the two most powerful aspects of Agile (in my opinion).
Inclusion
I like to tell this part of the Agile “origin story”: The software developers who first came together to create the Agile principles were trying to solve problems they saw in their industry, and the biggest one they identified was a lack of diversity in their work teams and management. They wanted to create a system that welcomed women and minorities, who were (and still are) seriously under-represented in the software industry and usually relegated to low positions. They wanted to flatten the many reporting levels in traditional project management, and to empower individuals to feel fully invested in managing their own work and collaborating frequently and effectively. They saw clearly that diverse and self-managing teams produced consistently higher quality work and were happier, and in 2001 the group produced the Agile Manifesto.
It didn’t take long for the business world to take note, and Agile became the hot new flavor of project management philosophy, destined to be misunderstood and misused by the industry. Like with all complicated new toolsets, it takes time to experiment and find how to best use the machinery for your unique situation. Inclusion was one of the most misunderstood concepts early on. Two of the four statements in the Agile Manifesto refer to inclusion: We have come to value Individuals and interactions over process and tools, and Collaboration over contract negotiation. These are worthy values, and Agile provides multiple strategies for getting there, including many different types of facilitated meetings and methods for reaching consensus and assigning work, depending on the project’s needs. Too many teams tried using too many tools too soon, without really learning and building up the approach, and ended up confused and discouraged that the tools seemed ineffective.
I saw this firsthand at a financial software company where I worked around 2005. The entire software development team (several hundred individuals in 5 different countries) got a brief training and instructions to “go forth and be Agile!” The result, predictably, was disastrous and led to me requesting formal training in Agile Project Management so I could help coach the development teams through the chaos. Subsequently, the first team I worked with ran the first successful Agile project for the company. The biggest thing that contributed to our success was figuring out what Inclusion and Collaboration meant – and what they didn’t mean. At first, we invited everyone to every single meeting. That’s inclusive, right? But we quickly realized that we got nothing accomplished when we tried to give equal weight to every single voice in a one-hour meeting, so we practiced the formal Agile meeting facilitation methods, and tried out different ones until we found what worked the best for us. This helped us make sure we knew who needed to be included in which meetings. We created firm working agreements so that we could use our collaborative time effectively. It also embraced the other pillar of Agile: trial and error, otherwise known as iteration.
Iteration
Agile software development uses quick turnaround cycles called “sprints.” The idea behind a sprint in software is to produce a “Minimum Viable Product”, or complete unit of work that can be tested, validated, and accepted by the stakeholder (or collaborator who needs your input for their work to progress). An example from software development might be a section of an app such as a calendar widget. At early stages it doesn’t need to interact with all the other elements of the app, but it has to be “done enough” that how it will interact is obvious. The idea behind this is the ability to quickly iterate when a flaw in the logic is discovered, or the team experiences a resource loss or other complication.
On a more philosophical level, iteration is an acceptance of the fact that most work is cyclical and builds on previous discoveries. The analogy to the world of research is clear, but what might be less obvious is how thinking of your work in iterative “sprints” can help you visualize even highly complex projects in terms of interim deliverables, even if just to yourself. For example, a section in your research paper or grant proposal could become a Minimum Viable unit of work and allow you to see how to plan around potential pitfalls and estimate your work more realistically. Using the idea of units of work and iteration allows you to recover more quickly from unplanned results or resource issues. There will usually be another unit to move to.
In conclusion
There is much more to Agile than the two ideas of Inclusion and Iteration, especially once we begin examining the tools themselves. We will explore some of those tools and concepts, including a look at evidence based management, in future posts.