Don’t Go Chasing Waterfalls: The Limits of Traditional Project Management and How Being "Agile" Can Help Your Team

Ever dealt with something related to intellectual property that was complicated? Unless your pants are currently on fire, then obviously your answer is, “YES!” Establishing and transferring those rights and obligations is inherently complex, nevermind having to develop and maintain processes and protocols for various parties. Moreover, getting those parties to collaborate efficiently while maintaining effective levels of diligence and consistency has its own range of issues. This article will discuss how you and your team might manage your office’s next big project effectively while maintaining ongoing communications with the relevant parties.

With the myriad ways for these collaborative gears to become inundated with the proverbial sand at any given time, trying to improve these processes becomes an additional task on top of everything else. Your team, tasked with making such improvements, encounters its own frustrating pain points, while also receiving feedback from a variety of parties --some of whom you are trying to influence without any official authority, while some influence you with the utmost authority. You then try to incorporate this input in an organized way through various projects and process improvements, which are likely, quite complicated themselves.

Sounds challenging, huh? Perhaps overly so? Well, if you’re using the traditional approach to project management, then that makes sense. The “traditional approach” refers to the linear path of:

1. Determining your objectives
2. Planning how you’re going to complete them
3. Completing them
4. Reviewing how it went

You cannot begin a subsequent step until the previous one has been completed. In project management lingo, this is referred to as the “waterfall” method,¹ and it’s not always the best project framework to use.

For illustrative purposes, here’s a straightforward example not directly related to IP: say you want to build a website where people can watch videos; not only that, but they can also have accounts on this site where they can note which videos are their favorite and can provide feedback to the people who made them. They can tell their friends about the videos through various means and even upload their own videos if they wish.² Now picture this fully-formed website in your head and imagine having used the waterfall project framework for constructing it. You first thought of all the different things you’re trying to accomplish by having the website exist, and then brainstormed and designed all the different features that would allow you to complete those objectives. After building all those features, you released the website to the public.

Easy-peasy, right? Well, what if you made a wrong assumption about how people would use one feature, which then flowed through to how you designed others? If the problem was widespread enough, you could be left with a website no one wants to use. All of that work for nothing; and not only was the effort worthless, it took you a really long time to build an entire website with all the features you desired. The whole planning, designing, and building process came and went before you knew anything about how users might like it! See the problem?

One solution to avoiding all that is the nontraditional, nonlinear approach, known as the “agile” framework. Instead of having an ironfisted, linear planning, execution, review process, this approach aims to continuously deliver incremental progress on your objectives within a work environment that is more collaborative and respondent to change. This starts in similar ways to the waterfall method in the form of having objectives and a general vision for how your team would like to accomplish them, but after that is where the frameworks diverge.

Rather than planning out and then executing all of the different ways you want to accomplish your team’s goals, the next step in the agile framework is prioritization. Here, you should avoid even trying to do everything at once. Instead, focus only on the aspects of the project that are the highest priorities to your team. Once you have mapped out what your priorities are, start your work on the top of that list by breaking the highest priority down into action items and committing to delivering some or all of them in a short timeframe,³ known as a “sprint” among agile practitioners. That is, how many items your team commits to should depend on how much bandwidth your team anticipates it has to devote to a project to ensure completion of the chosen action items. After your designated sprint is finished, you report to the interested parties (such as your team and outside stakeholders) the results of the sprint and completed action item(s) in order to get their feedback.

This feedback then informs what subsequent actions you should take with your project; since at this point you may have only delivered a portion of the larger project, you’ll necessarily have to get going on the other parts as well. This will involve re-prioritizing what’s left to accomplish, which may include action items from the highest priority you initially identified that you couldn’t commit to in your first sprint. If your team’s highest priorities still have not changed, include those remaining action items in your next sprint. Alternatively, if you’ve already completed the objective after your first sprint, you should prioritize your remaining objectives and proceed to break the highest priority down into action items for sprints, etc. Rinse and repeat, as necessary.

While this might sound simple, or even say, “linear,” the value of such a framework is most apparent whenever you’re working on a complicated project and, most importantly, whenever your teammates’ and/or stakeholders’ feedback sends you in different directions that you didn’t anticipate when the project began. With a complex project containing multiple action items across multiple sprints, the agile approach provides you the flexibility to deliver on more than one priority at a time.⁴

Agile also makes incorporating feedback much easier. For example, because you’re working on only your highest priorities for designated lengths of time and you’re always collecting input along the way, you can simply shift your priorities or alter which action items you create from sprint to sprint. If the only point in time your work is reviewed is once the entire project is finished, as is the case with the waterfall approach, you’ll likely be left trying to incorporate what you’ve learned from your team and stakeholders back into a tangled and complex web of completed objectives.

Looking back at the video website example, significant portions of “completed” code might have to be overhauled to incorporate such feedback. Think about the ways that process would have been improved by instead using the agile approach. Rather than designing and implementing every feature you could ever hope to include in the website, you would start with what you consider to be the highest priority and work from there. As a result, you can get something out to the public (from which you can begin receiving feedback) much more quickly and without locking yourself into only one conception of how the (eventually) fully-formed website should look. Your team and users are guiding the incremental development of these ideas with the flexibility to incorporate feedback more fluidly while avoiding the possibility of redesigning the entire website. In other words, by going the agile route, you have a much higher chance at succeeding--both in terms of the effectiveness of what you’re delivering to your users as well as the efficiency with which you do so.

Of course, the realities of tech transfer don’t exactly correspond with a purely software-based world in which the agile framework was developed.⁵ In the video website example, you’re building something from scratch, and it was just you and your users. When dealing with the intellectual property of your institution, you have complicated established processes, web portals, and resources, so starting over from scratch may not be feasible. Additionally, there are other parties outside of your team and those you work with on a daily basis (e.g., your investigators), and these outside stakeholders tend to have vetting power in this process. Many of them have may also limited availability for providing feedback, so the traditional approach of talking to them at the beginning of the project and then presenting them the final result may be the only option.While this certainly introduces an extra degree of difficulty for wouldbe project managers, fear not! This isn’t an all-or-nothing proposition; agile concepts are also helpful for non-software development teams and those facing institutional constraints that are more conducive to the traditional approach. In these circumstances, you can try incrementally building a hybrid waterfall/agile system, which would include characteristics of both frameworks.⁶

For example, if your project or circumstances require more upfront planning, you could still try progressing on your objectives through sprints to induce more consistent feedback from everyone involved. Alternatively, if your stakeholders are too busy for agile’s constant and thorough input-gathering, you can still keep them informed of your team’s priorities through a shared backlog of objectives and action items. This not only makes your work transparent throughout the project, but-- using a web-based tool such as Trello-- it also makes it easier for them to provide regular feedback virtually, if face-to-face meetings aren’t feasible.

Another starting point could be the agile concept of a daily “standup” meeting, in which everyone on your team reports their progress on assigned action items and what they plan on doing over the course of the day to further that progress, including any breakthroughs or roadblocks worth discussing as a group. This kind of collaboration and transparency helps keep everyone’s efforts aligned, avoids the duplication of work and ensures the dissemination of best (and the avoidance of worst) practices throughout the team.

How you begin changing your approach will depend on which aspects of waterfall you must continue with (e.g., due to outside constraints) and which aspects of agile you believe will help you the most. You can even take an agile approach to making your projects more agile: introduce what you deem to be your highest priority agile concept first, see how it goes, and keep progressing from there. After all, if taking this kind of incremental, nonlinear approach to managing projects can be helpful, then so too can incrementally morphing your project management practices into increasingly nonlinear versions over time. Exhale.

That’s what we’re trying to accomplish here at Addgene, and with the Tech Transfer Team included, we hope to continuously deliver more and more value to all of the stakeholders involved in fulfilling our mission, using our limited resources as efficiently as possible. In the meantime, take TLC’s advice and “don’t go chasin’ waterfalls;” instead, try some agile for yourself!

FOOTNOTES

1. The name “waterfall” is purportedly derived from the difficulty of travelling back up a waterfall once you’ve plunged down it.
2. You or may or may not have come across this concept at some point during your time on the internet.
3. Typically, timeframes range between two to four weeks.
4. Assuming that it makes sense for your team technically, logistically, etc., to be working on those items and that your team has the necessary bandwidth.
5. The agile framework was formalized with the publication of the Manifesto for Agile Software Development in 2001. Developers were fed up with having the waterfall method imposed on them by business-focused superiors, so a particular group concocted a list of four core values and twelve principles they felt should guide their vocation. Given the inherent flexibility of software, an incremental and focused approach to developing software made sense and could be more easily adopted than fields that have, say, three-dimensional space to contend with.
6. For more information about the hybrid waterfall/agile system, see Suzanna Haworth, Agile v. Waterfall: What Should You Use for Your Project?, DIGITAL PROJECT MANAGER, May 5, 2017, available at http://www.thedigitalprojectmanager.com/agile-vs-waterfall/ (last visited October 18, 2017). You can also learn about how these practices can be applied in environments other than software development. See Teri Funnkhouser, How to Apply Agile Practices With Your Non-Tech Team or Business, TECH REPUBLIC, Apr. 7, 2016, available at http://www.techrepublic.com/article/how-to-apply-agile-practices-with-your-non-tech-team-or-business/ (last visited October 18, 2017).