In my personal life, I spend a lot of time with a software engineer (my husband) as he worked with teams to build products. Although he has long since outstripped my meager technical programming knowledge and/or has been under a strict NDA, we don't often talk about the nitty gritty of his work. I can't help myself from asking questions, though, about how the teams function. And that's how I came to know Agile software development.
In the grand tradition of start-ups everywhere, I'll let you know that there is an official Agile development system (read more here) and you can hire official Agile experts to be on your team, or you can do what I did, which is Google a lot of things and borrow what works for you! There are, admittedly, a lot of differences between launching a software product and turning in a dissertation, but I've isolated a few key concepts that really challenged how I thought about my work and helped me build systems to move quickly and efficiently through the dissertation process.
A caveat: I've made every attempt to be universal here, but disciplinary (and sometimes departmental) differences abound. In my field (and in my department) the dissertation is a manuscript (or even longer) piece to be completed as a single author piece with the end goal of becoming a book manuscript as a next step, and I've written these from that perspective. But I hope that the principles I've highlighted here can be helpful even if you're working with co-authors, or producing a shorter series of articles, or some other type of capstone project that I can't even imagine.
WORK IN DISCRETE ITERATIONS
In Agile systems, one of the core ideas is that time is segmented into short (one to four week) chunks, and at the end of each one, a working product is produced. Rather than waiting until all the research is completed, or all the testing is done, iterative working patterns engages all those skills simultaneously, so that stakeholders (ie, people who are interested in the outcomes) can see progress regularly. For some teams, this looks like sprints, where the group decides on a set of objectives or deliverables for that timeframe, and then works backwards to plan out all the work necessary to get there.
How does this work as an academic? - Rather than saying "this year I want to write two chapters" or "This term, I want to do all the research for x and y topics", I set discrete, deliverable goals like:
In this month, I'm going to write the conference paper that will eventually become part of x chapter
In these two weeks, I'm going to draft the first section of this larger chapter
But lots of us set these kind of goals! The difference in iterative work flows is that I was engaged in all of the parts at once. Instead of refusing to move onto the drafting until the research was done, or waiting until the whole chapter was ready before sending it out for feedback, I tried to work in many directions at once. If I pulled an article to read for a specific section, I not only read it, but I took notes, and wrote (with varying degrees of formality) my thoughts and findings. When I was in the archives, I was also writing up my first impressions from the research, reading and writing actively at the same time. It might be just my brain, but switching up the type of task during the day kept me engaged, and seeing the word count increased, even if those actual words wouldn't make into the dissertation as such, helped me feel (and actually be) productive. But perhaps most importantly, whenever my stakeholders (ie, my advisor and committee) wanted an update, I had a ready to go summary of what I was working on, and something reasonably polished to share with them at a moment's notice.
SHORTEN THE FEEDBACK LOOP
In Agile systems, feedback is continuous. One of the most important tools for making sure the team stays on track during these intense sprints is the SCRUM or stand-up meeting. The idea is that a stand-up is a short (you're literally standing up, encouraging brevity) informal meeting where each member reports what they did yesterday, what they will do today, and any issues that are blocking their progress toward the ultimate goal. This lets managers keep on top of how each team member is performing, identify any problems quickly and efficiently, and promotes the idea that you're accountable for moving forward, every day. Rather than waiting for the end of a sprint, or heaven forbid, a quarter or whole project cycle, to evaluate how things are going, stand-ups make evaluation a daily occurrence.
How does this work as an academic? Well, the team for my dissertation writing was me, myself and I, and my cats might have become concerned if I stood up at my desk, discussing with myself how my work was going everyday. So, I started to build those simple questions into my "start of work ritual." I opened up a file and wrote down what I accomplished yesterday, what I wanted to do today, and what things were blocking me. Not only did the act of writing it down make me feel like I was moving forward, even if the progress was slow, it also gave me a low stakes way to confront my own procrastination. It takes some honesty but it's a real shock to have to write down "yesterday, I did not do a single shred of work on [whatever short term goal] because I spent the entire day researching for a prospective syllabus that isn't due for three months." I was (and remain) the queen of procrastinating productively, or working on things that ostensibly need to get done at some point but seem easier than whatever pressing thing that needs to be done now, and checking in daily made me see just how I was engaging in that particular behavior. But surprisingly, the most helpful thing was identifying my blocks. While a software development team might be blocked by a server outage, I was often blocked by more nebulous, abstract things like:
I don't know enough about x topic to write authoritatively about it.
I am not clear about what my advisor meant by y comment on the draft I'm revising
I have no idea if this idea is coming across the way I want it to
Writing the blocks down let me see what specifically wasn't working, and then let me take steps to remove the block. I could set aside some time for targeted research, schedule a meeting to discuss feedback, or send an early draft to a friend or writing group to check for clarity. Too often, I would get lost in the feeling of being stuck without ever identifying the specific problem, and writing down the block as specifically as I can helped to work through that on a daily basis, rather than waiting until a big milestone had passed.
TEST DRIVEN DESIGN
In Agile systems, test driven design is a tool to buttress against over-design. Before you write a line of code for the actual product or feature, you write a test (or sequence of tests) that the code must pass in order to be considered complete. You then write code to specifically pass that test, and only when the code passes the test do you consider the product or feature complete. By working backwards from the test, you ensure that you aren't adding extra features, writing unnecessary code or straying too far from the objective of that specific feature.
How does this work as an academic? Before I started to write any piece of my dissertation, I tried to be as specific as I could about what that piece needed to do argumentatively. Like many people, I was often focused on the content of a specific section - what sources does this need to cover? What ideas am I introducing? Shifting to a model where I was focused on the argument, I instead would plan out what work I needed that section to do. For example:
This paragraph needs to link Foucault's theory with my argument about cat videos.
This section needs to historicize how zoo exhibits incorporated natural elements.
This chapter needs to advance my argument about surveillance forward in time to a digital space.
By focusing on the work that the argument did (notice the active verbs like link and advance) rather than the content, I built myself a failsafe against overwriting, and a "test" to run when doing the each round of editing, not just the first. It was easy to do a first look of a paragraph and say, yeah, that met the goal, but after three rounds of edits and feedback, it was so helpful to be able to look back and say this paragraph needs to link these two ideas and cut away any excess writing that did not fit that function. Not all of us have linear brains, but writing out linear "tests" can help to streamline writing and clarify your argument. Cut out those extra three sentences, decide if they need to go in a footnote, or just put them in a document called "extra ideas" because you never know when you'll need them again.
BE ADAPTIVE, NOT PREDICTIVE
In Agile systems, being adaptive is a core value that underpins so many of the actual day to day practices. To be adaptive is to be responsive to changing demands, team needs, unexpected challenges, and exciting breakthroughs. Predictive management styles often have very established outcomes, proven processes, and rock-solid expectations for what the end product must do or accomplish. As Wikipedia so succinctly puts it:
Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team has difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method is about what will happen on that date. An adaptive team cannot report exactly what tasks they will do next week, but only which features they plan for next month. When asked about a release six months from now, an adaptive team might be able to report only the mission statement for the release, or a statement of expected value vs. cost.
How does this work for an academic? Despite my very concerted efforts to make writing my dissertation a completely transparent, predictable, and scheduled work effort, it changed every day. I found new sources that changed or challenged my argument, I had other responsibilities pop up that took precedence over writing, I got sick, my committee had major revisions for a chapter, or my funding changed. When I gave myself the freedom to shift my timeline, adjust to new realities, or follow promising leads, I became a better writer. Having milestones like sprint goals ensured that I never got too far off track, and checking in every day gave me structure even when things were shifting, but Agile showed me that I could let the project evolve all while staying in control. I could fall down the rabbit hole of learning that led me to getting a PhD in the first place all while staying focused on producing the product that would eventually get me out, degree in hand.
It isn't a perfect fit, but using some Agile principles helped make the monstrous task more manageable. I remember thinking the day after I turned in my prospectus that I didn't even know how to start. Should I open up some Word Doc and call it dissertation? Do all the research first, then all the writing, then the editing? When should I share drafts? Should I just take a stress nap? Looking at other project management styles, even if they were far from my own use case, helped me see that there were a lot of ways to get started and build tools and systems that served me, my working style, and ultimately, the work itself.