How to prepare can seem mystifying to a lot of newer debaters or those who have not had good prep practices hammered into their heads. As a high school debater I did not have much coaching support, so when I moved into college debate I was “enlightened.” It was easy to think “welp I’ve got files and they’re highlighted and I mostly know how to go for them,” but it is a much more programmatic process than just that. In today’s tech age putting a large number of resources in the hands of debaters across the board, debaters can invest so much more in preparedness than ever before. So start your prep early and be ready to slam your opponent’s after following this guide.
Having organized virtual tubs sounds like a no-brainer, but it’s easy to, well, not do it. Relying on memory of where you have ‘x’ cards does not put you in a good spot when you’re in a crunch. Having well-organized files means you can quickly navigate through your documents to find appropriate arguments and answers for both pre-round prep and in-round prep. Organizing files also has a secondary effect of building a mental catalog of where you have cards. When *you* have placed files in particular folder, you’ll intuitively remember where they are for quick access.
I have attached an example of what an organized virtual tub can look like, built off of how I organized my files as a debater:
Example Virtual Tub.zip
I’ll give a breakdown of how to use this filing structure. Here are the main folders:
!-Answers to Ks
Why the exclamation points? I used exclamation points to keep some folders sorted above others. I didn’t want “Previous Topics” or “Speech Docs” to alphabetically mix into folders I may be using in debates. This can also be done with numbering (“1-“) or lettering (“A-“) if you want to order your folders more particularly.
In your aff folder, you should have sub-folders for different affirmatives. Your H1B aff files should not intermingle with your Open Borders files, otherwise you risk confusing yourself with file organization. You could create a generic advantages folder since a lot of advantage ground is cross-applicable between various affs (as with any topic), but I lean toward having them integrated with specific affs and just copying cross-applicable cards to different files. This is especially important because varying internal links will (should) modify how you write a variety of blocks.
In specific aff folders, you should have a 1ac’s folder and a 2ac’s folder. 1AC’s shouldn’t be in a master aff files. There’s an important reason for this: you shouldn’t always read the same 1ac. You should have a variety of versions, maybe with different internal link or impact cards cycled in or different advantages, different solvency mechanisms, etc. Having different versions of your 1ac allows you to change your aff based on predicted neg strategy, or to cut out some parts to let you read more impacts, or more solvency cards, etc. For 2ac’s, I recommend putting case extensions and case blocks in one file and then off-case frontlines and blocks in another. Why? Creating an overly large document is a baaaaaad idea. It’s harder to navigate because there’s more material to scroll through and it’s more likely to lag or crash your word processor, eating up precious prep time in a debate.
Answers to Ks Folder
Why doesn’t this belong in the aff folder? Ks are read on the aff and neg, you’ll end up using this folder on both sides of the debate. This is a fairly straightforward folder. The sub-folders are not necessarily for specific Ks, but are intended to be more blanketing into categories of specific Ks, then there are specific Ks. This is mostly an organizational preference on my part, but it does simplifying putting files with cross-applicable answers close to specific Ks (it makes logical sense to generic identity politics answers in the “Identity” folder along with a “Race Ks” sub-folder).
Again, a folder useful for both aff and neg. This should be an exhaustive compilation of all of your impact cards AND impact answers. Why not just impact answers? There’s 2 big reasons:
1) Impacts go both ways. Even if you perceive “Unilateralism Good” as the “impact,” that does not mean you will never debate a team that says “Multilateralism Good/Unilateralism Bad.” The same is true of Growth, Warming, etc.
2) When putting together new arguments, it’s easier to have already put your impact work in a central place to pull cards for your new DA or advantage rather than digging through an old DA or advantage.
As you can see, there are a lot of general folders that can have specific sub-folders. For instance, “Econ” can have “Growth” and “Trade” sub-folders/files, or “Environment” can include “Biodiversity” or “Warming” or “Deforestation” sub-folders/files.
This folder will be one of the most important to keep maintained, simply because there are a lot of potential negative arguments to read.
This folder has 5 sub-folders:
- Case Negs
“Case Negs” is categorized into “General Advantage Answers,” “General Solvency Answers,” “K Affs,” “Topic Areas.” You could create folders for specific affs rather than using “topic areas,” as that is more applicable for list topics.
As I mentioned for the Aff folder, there are general advantages that will be cross-applicable between different affs. So it makes sense to create “General Advantage Answers” folder with specific advantage answer files that include topic-generic internal link/solvency answers and impact answers and then putting specific aff internal link answers in specific case neg files.
This is similarly true of “General Solvency Answers.” For every topic there will be all-encompassing solvency arguments that apply to the whole topic like “Trump circumvention/non-enforcement.” The value in having general case answers separated from specific case negs is for debating new affirmatives that you do not have a specific case neg to.
“Topic Areas” or “x Aff” folders are largely self-explanatory. There can be stylistic differences in whether or not you create a single master file for case negs or separate them into different files for advantages or solvency, though I lean toward the former.
“K Affs” can in many ways be redundant with the “Answers to Ks” folder. However the function of this folder for case negs to specific affs different teams read as opposed to just generalized responses to the literature area a K aff uses.
The CP folder is pretty straightforward. I prefer sub-categorizing CPs into different types (Advantage CPs, Agent CPs, Process CPs, PICs, Specific Aff CPs, etc), but that’s a matter of personal choice. From there I create different folders for different CPs.
The DA folder is straightforward as well. Different folders for different DAs. Perhaps different folders for different classes of DAs (econ DAs, politics DAs, etc.) The reason I prefer creating different folders for individual DAs is to simplify placing update files in appropriate places when I don’t have the time to immediately compile files, same with CPs.
The K folder as I used it mostly lacks sub-categories of Ks and mostly has folders for specific K arguments. That’s a matter of personal choice.
The T-FW-Procedurals folder is straightforward. I preferred sub-folders for T, FW, and Procedurals mainly because I would have multiple documents for each (separate definitions and violations files for T, FW and updates for it, breaking procedurals into specific files for each one.”)
I preferred putting all theory for both aff and neg in one general folder. This was mainly an effort to prevent losing theory files in the minutia of my aff or neg folders and because appropriately naming files overcame any possible confusion. It’s also useful to have a central place for theory so you don’t forget about or lose theory arguments you had put in a 2AC file or CP file.
You should create sub-folders for different topics you debated on or have files from so you can archive your dropbox from that season. It is so valuable to keep all of your files because people (or you) will invariably borrow from previous topic work. Having answers to a former education topic aff that a team reads as an advantage CP keeps you from getting blindsided. This also creates a valuable resource for your newer squad members who did not debate on previous topics. They are the most vulnerable to being “backfile checked.”
You should save speech docs from every single debate that you have been in. There are so many reasons why:
1) It helps you to do speech redoes. Having your opponent’s document to reference means you can give an even better redo and thus improve even more, especially in your evidence analysis skills.
2) Saving your speech docs also saves any blocks you wrote on the fly in a given debate. You can then integrate them into your aff file, DA file, CP file, case neg, etc. Why would you want to lose a 2nr CP solvency overview you wrote specifically for a Syrian Refugees aff that won you a debate? Save it and you save yourself future prep time. In my freshman year of college, my partner asked me to write him a heg impact overview during his 2ar prep. I wrote an impact overview that ended up being used YEARS later as it was continually modified for efficiency, specific impact comparison, assuming specific answers, and so on. We won a lot of debates was going for the heg advantage in the 2ar because of the re-use and refinement of that one impact overview that proliferated into a variety of different ones.
3) Adding to your files. Just like you should scour open evidence and the caselist for new cards, you should recut and use good evidence that was read against you.
You should organize your speech docs by topic, by tournament, by round (with round number, side, and opposing team in the folder name), and then name speech docs appropriately for each speech. This sounds overly complicated, but it amounts to a 3-5 minute ritual to do at the end of every debate that has a hugely valuable payoff.
One thing I hoped to illuminate with this article is that all the way down to how you organize your files, there is a certain strategy involved. It took me too long to come up with my own file organization (with some elements borrowed), the ideal goal of this article is enabling anyone reading this to organize their virtual tubs and kick off positive debate habits, whether they use this system or one inspired by similar thinking.
Colin Dailey is an Assistant Debate Coach at George Mason University and Co-Owner of Policydb8.com.
Over the past few months I have been analyzing the voting histories of over 400 active judges on the College Policy Circuit, covering just about every judge who has been to a major national or large regional tournament in the past year and a half. I have posted publicly about some of the insights this brings on which judges have judged the most rounds, and what this can show about how judges behave and the question of judge predictability.
For my latest project I’ve been investigating school bias in judges, testing to see if judges can be biased towards teams from a school (or set of schools) when compared to other judges. That analysis is still in its embryonic stages, but in the meantime I felt that there might be interest in what the raw data tells us about the successes of various schools.
I will make a separate, longer, post going deeper into the methodology behind this data, however the basic process was scouring through the Tabroom judging record of 416 Judges, analyzing the over 48,000 ballots that they had between them, parsing which schools were involved and who won, and then compiling that data. While this isn’t a complete history of the tabroom era it does give a relatively representative understanding of the past six years of debate history.
Below I present three relatively basic metrics for school success: Percentage of ballots won (the data treats each ballot as a separate decision as opposed to analyzing panel decisions holistically), the total number of ballots won, and the most ballots contested. This data explicitly excludes swing-teams but does count the rounds of teams who were debating swing teams. There was no differentiation made between Novice, JV, or Varsity divisions in the compiling of this data.
The top ten most successful teams* by percentage of ballots that they’ve won are:
1. Harvard – 63.0% of ballots
2. Northwestern – 62.1% of ballots
3. Towson – 60.7% of ballots
4. UC – Berkeley – 59.2% of ballots
5. Georgetown – 58.8% of ballots
6. University of Michigan – 57.8% of ballots
7. Oklahoma – 57.3% of ballots
8. Rutgers-Newark – 57.3 % of ballots
9. Kansas – 56.6% of ballots
10. Wake Forest – 56.2% of ballots
The top ten most successful teams by won ballots are:
1. Liberty University – 2,583 Ballots
2. George Mason – 2,268 Ballots
3. Kansas – 2,186 Ballots
4. Wake Forest – 1,777 Ballots
5. Emory – 1,562 Ballots
6. University of Michigan – 1,556 Ballots
7. Harvard – 1,509 Ballots
8. Oklahoma – 1,346 Ballots
9. Northwestern – 1,189 Ballots
10. James Madison University – 1,181 Ballots
Honorable mention goes to Binghamton University in a very close 11th place.
The top ten most successful teams by ballots contested are:
1. Liberty University – 4,681 RBallots
2. George Mason University – 4,090 Ballots
3. Kansas – 3,860 Ballots
4. Wake Forest – 3,162 Ballots
5. Emory – 2,844 Ballots
6. University of Michigan – 2,693 Ballots
7. James Madison University – 2,625 Ballots
8. Harvard University – 2,394 Ballots
9. Binghamton University – 2,393 Ballots
10. Oklahoma – 2,347 Ballots
* Not including teams with under 40 ballots in my data set. Apologies to Columbia, SUNY Broome, and City College who would otherwise have places on this list.
An adaptation of Scrum for agile project management in Debate.
Regular file production is something of a lacking function in many high school debate teams, notably for schools that primarily operate as clubs with no established coach on staff. Much of the time, their work relies far more on using openevidence, the caselist, whatever other files happen to come their way, and then far down the priority list is doing work themselves. This results in pre/post season work being unfocused, unorganized, inefficiently done, or non-existent while waiting to see what camps/file selling sites (oops)/caselists put out in terms of files.
This problem can exist for a variety of reasons: lack of research ability, card cutting ability, or general confusion when considering how to approach a topic. But, assuming that a high school team has individuals capable of these things, what is lacking? Why is it difficult to have regular original file production? A laisse-faire approach to work ends up being the norm, with debaters all working on their own side projects with little interaction over what they are working on with others (minus the always existing gushing over cool arguments that they found). When that is the case, no matter the size of the team, there will be sizable gaps in the virtual tubs or at minimum, a lack of originality in work.
What should occur is team organization: how to identify assignments, distributing them, how to work on them, etc. My goal is to outline a model of team organization built on Scrum, an agile project management framework. While it may seem inconsequential, project management structure has increasing value for debate with the expansion of topic size, information available, and subsequently the number of arguments that exist. For many teams who already have a central process for assignments and file work, this will likely feel familiar.
So, a brief introduction to Scrum. Scrum is an agile project management framework, typically used for software development. Agile refers to a set of values for completing assignments. A core principle of agile that Scrum is built off of is continuous improvement. Scrum is a more defined process, a heuristic that prizes adapting to changing factors in how the work process goes. This means re-prioritizing and short release cycles to consistently learn, adapt, and improve work. And Scrum intends to take an incremental approach by breaking down projects into smaller work goals. So let’s break down and define the elements of the Scrum framework and then modify the process to be more applicable to a debate team. (Be mindful that there is a wealth of literature surrounding project management models; the aim here is to minimally define concepts as necessary.)
Development Team (Assignment Group) – These teams are a) self-organizing (teams themselves decide how to best accomplish work) and b) cross-functional (all members of the team are capable of accomplishing their work without depending on other team members). This does not refer to the squad as a whole (unless you have a small squad). The ideal group size is in the 3-9 range to ensure there isn’t a loss of team interaction on the smaller end or too much complexity at the larger end. Group organization does not necessarily require that every member of an Assignment Group is working on the exact same file. Rather, Assignment Groups will all be assigned a set of files (or one large file) that they delegate work on among themselves. An important facet of the Assignment Group dynamic is that while groups may be strategically designed to have varying skill levels to balance out group effectiveness, the debaters in the group should take an egalitarian approach with no outside labels, titles, so on affecting the dynamic of the group and impeding effective collaboration. It does not make for an effective group for a debater to be labeled a novice or JVer who doesn’t know what they’re doing.
Product Owner (Assignment Lead) – A better term for debate is the assignment lead and likely is a head coach, team captain, or simply the person who has the best sense of the pulse of the topic. The assignment leader controls the product backlog, or list of assignments for overall work period, and prioritizes importance of assignments. An important feature is that there is one, singular assignment lead purely for the sake of ensuring that there is consistency and lack of contradiction in priorities. This does not mean that there cannot be input from others, but that there is an executive decision made about how to prioritize and hand out assignments to decrease the risk of the ever dangerous “too many cooks in the kitchen.” While in a typical Scrum framework, the Assignment Lead is removed from the actions of Assignment Groups, to better fit the typical format of a debate team, they would likely have a second role as a Group Lead.
Scrum Master (Group Lead) – A better debate term is group lead, but that is still a slightly misleading term. This is either a more senior debater or a coach. The point of this role is not a hierarchical authority that working groups are answerable to. Instead, the goal of the group lead is to coach the assignment group to be self-organizing, coach individual team members in cross-functionality (referring to completing their assignment from research to formatting to quality to file organization to file submission), and removing impediments to progress (ie helping identify and filling file gaps, assisting in overcome research blocks, etc). Outside of working with the Assignment Group, Group Leads should coordinate with the Assignment Lead and other Group Leads to discuss organization, planning implementation of Scrum and when it should occur, and how to improve efficiency.
- Sprint (Wave) – A sprint is a time period of a month or less in which a “Done” and usable “Increment” is created. These time periods should be consistent during a development effort and a new sprint starts immediately afterward. Some key rules for a sprint are: no changes are made that would veer from the sprint goal, quality goals do not decrease, and the scope can be clarified or re-negotiated between the assignment leader and the development team as new issues arise. Each sprint has a goal of what to accomplish, and a flexible plan to meet that goal, and a finished increment at the end.
Sprint Planning – Self-explanatory name. The key questions are what can be achieved in the sprint and how will the work to complete a file be achieved. Work is selected from the assignment list (product backlog) and put into the sprint assignment list (sprint backlog). This is a collaborative session for the Assignment Group; the Group Lead should take a monitoring and assisting role, not leading it. This is a time period that
Daily Scrum – This is a daily, roughly 15 minute box of time for the development team to synchronize work and plan for the upcoming day. This time is used to examine progress toward the sprint goal and completing work in the assignment list. An important distinction to make is that this is not a status meeting. This is not a time where debaters report their work to a coach or lead on their assignment and then are told what they should do different. This is a self-organizing exercise where debaters discuss and collaborate in their working groups to measure group progress toward achieving their sprint goal, identify issues, adapt as necessary, and set daily goals together. It should happen at a consistent time and have full participation. It is important that this happens at a single time is to ensure group participation and effective group evaluation of progress. A series of facebook or slack messages from varying group members throughout the day is not productive because that simply devolves into giving status updates. The group leader should supervise, but only for the sake of ensuring that the working group is staying on task and keeping to the point.
Sprint Review – This is held at the end of the sprint to inspect file work done and adapt the assignment list if needed. This includes the development team, the group lead, the assignment lead, and all other relevant parties. The goal is for the assignment group to demonstrate work that is “Done,” for the assignment lead to determine what is “Done,” and for the entire group to collaborate on what should be changed about the assignment list and what should be done in the next sprint.
Sprint Retrospective – This occurs after the Sprint Review and before the next Sprint Planning session. The goal is for the assignment group to discuss what went well during the Sprint, what could be improved, and what they will commit to improve in the next Sprint. The Group Lead will oversee the meeting in order to ensure that debaters are participating and understand the purpose of the meeting. By the end, the Assignment Group should commit to making changes to their process to be more effective AND more enjoyable during the next Sprint.
Product Backlog (Squad Assignment List) – The product backlog is an ordered list of everything needed in a product. In context of debate, that means an assignment list for everything that will be needed in the tubs. It should be ordered by priority. This does not need to happen all at once, but can be broken up in varying sprints/assignment waves.
Sprint Backlog (Sprint Assignment List) – This is the set of product backlog items that are being worked on in a sprint, or assignment wave. An important note is that this is a forecast of goals that the team believes can be accomplished within a sprint. To ensure that improvement goals are being met, it should improve at least one high priority process improvement from the previous retrospective meeting.
Increment (Completed Files) – An increment is the sum of all of the backlog items completed during a sprint and the value of increments from previous sprints. The goal of Scrum as a framework is to “deliver” a “Done” increment. The definition of what “Done” means is important. There is no stable definition I can provide outside of a file being usable. The key is that there is a shared understanding from team members of what “Done” means, what makes a file usable, what elements are needed, etc.
Application to Debate
Now that the model has been generally defined, let’s walk through what the application of this model can look like for a debate team.
Early pre-season/Topic announced: Team does a basic mapping of what the topic can entail, different areas for affirmatives, negative files to cut, arguments to anticipate, etc. Debaters and coaches express arguments that they have the most interest in, think will be most relevant, etc. This enables the Assignment Lead with input from others to build the Assignment List, define what these assignments are with a general concept of what they should be upon completion, and appropriately prioritize arguments.
Given the structure of teams and balanced outside obligations for debaters, weekly team meetings should be of multipurpose function for Sprint Reviews, modifying the Assignment List, distributing assignments to groups, then groups break off for sprint retrospectives of the previous sprint and Sprint Planning for the current set of assignments.
In the Sprint Review, the Assignment Lead will evaluate “Done” files (or have done so before the meeting starts since that can be time consuming), the Assignment Group and Group Lead will make recommendations for what should change about the Squad Assignment List (completed files should be removed, a file isn’t complete and should carry over to the next Sprint, new file ideas were discovered while working on the Sprint, etc.). The Assignment Lead will appropriately modify the Squad Assignment List based upon completed files and recommendations in Sprint Reviews.
Individual Assignment groups will have their Sprint Retrospectives. This is an opportunity for debaters to discuss how they could improve their coordination, individual work efforts, adjust the level of work they think they can accomplish (“did we take more than we could complete?”), and carry those changes into the next Sprint.
Assignment Groups choose or are given a set of assignments based upon what those groups believe they can handle. This can vary. In the early pre-season, putting together an affirmative master file or a large case neg for a presumed core of the topic aff can require the coordination of an entire assignment group, depending on its size. For smaller assignments such as DAs or CPs, those can be handled by one or two people, depending on capability. The Assignment Lead ensures that the Assignment Groups understand the files that they have been assigned are and what they entail.
For building larger or a greater quantity of files per group in the summer, longer sprints (up to a month) can be more useful to ensure that assignments will not HAVE to be carried over to the next sprint.
Assignment Groups will plan their sprints. This will involve outlining and mapping out what a completed file should include, functionally creating sub-assignments within the assignment, defining what makes the file “Done,” and then delegating file work among themselves. Even if working on different files, the group should collaborate as a whole to outline files. This is especially important if a group has a large number of smaller assignments given to them, meaning that initially, not all files will have someone working on them and will only be taken up by an individual debater after completing a previous file. This will make file completion a more incremental process that can result in meaningful goal-setting and accomplishments on a daily basis. Given the modular nature of file work being done, debaters in their groups should also delegate who will compile which master files.
In Daily Scrums, debaters will talk as a group, set goals for themselves for that upcoming day, discuss what they accomplished or didn’t accomplish of their goals in the previous day, examine how they should adjust their work process or work level they are capable of in the upcoming day, and discuss any modifications that should be made to file outlines based on research that they came across. This is a self-reflexive period in which debaters should aim to be aware of their strengths and weaknesses. Other debaters should aim to offer advice on goal-setting or execution of the different elements of file-building (search terms, databases to look at, what a card should say, formatting, file construction, etc.). Part of the goal is for the Group to assess overall progress of their Sprint Assignment List. Based upon self-assessment and outside assessment from their Group Lead, they should consult with their Group Lead for assistance and how to improve.
While doing work during a Sprint, debaters should pay attention in their research/file work for possible future assignments that could be added to the Squad Assignment list, appropriately saving articles/books and taking note to recommend to the Assignment Lead in the Sprint Review. If it is pressing, it should be sent to the Group Lead who will communicate to the Assignment Lead. Simple reason for the hierarchy: on larger squads, this can result in the Assignment Lead being bombarded by constant messages from a dozen or more different debaters on a regular basis.
The Group Lead has the responsibility of regularly reviewing work put out by debaters in order to ensure quality, monitor performance of Group members, and ultimately approve of files being done. Depending on the deadline and total progress being made, the Group Lead should cut cards to fill holes of files or assist in research for difficult portions of files.
The Assignment Group should have their files “Done” before the end of their sprint or made as much progress as possible. They should have time for their Sprint Review BEFORE the file submission deadline is due.
Then we come back to the team meeting and it all starts over again.
The Group Leads and Assignment Lead should regularly discuss changes to the model, different group capabilities, file prioritization, etc in coaches meetings or over a chat medium. It makes the most sense to have this meeting not long after overseeing Sprint Retrospectives.
Every person on the team is responsible for reporting holes in files, avenues to research, etc. It makes the most sense to do so on a central spreadsheet or through Group Leads so the Assignment Lead does not get bogged down with messages, especially as team size scales up.
This model requires a lot of coordination and in turn, organization. Here are some guidelines for what that should look like:
The squad writ large should have a messaging medium (team slack, fb messenger, POLICYDB8 CLUB, gchat, etc.). Assignment Groups should each have a messaging medium (slack channel, different fb chat group, DIFFERENT POLICYDB8 CLUB, different gchat group). These communications should include audio/video chat capabilities or an alternative should be used for those functions so various meetings do not have to occur in person.
The Squad Assignment List should be on a spreadsheet or some other open, transparent location the team as a whole can see. Ideally only the Assignment Lead can modify it (because people will undoubtedly mess it up and cause confusion at some point.). Highly recommend Google Sheets. Also, of course, POLICYDB8 CLUB (use the forums and edit a post continually).
Assignment Groups should have a spreadsheet as well. This is where things get interesting. Assignment groups will have their sprint assignment list. They should have this organize into an interactive visualization of work being done. List items should be categorized into “To Do,” “In Progress,” “Blocked,” “To Verify,” and “Done.” “To Do” should be all of the items that the group wants to complete during a Sprint. “In Progress” is all items currently being worked on (taken by debaters as a daily goal). “Blocked” are items that debaters cannot complete or need help with. It is the responsibility of the Group Lead to help with these items. “To Verify” is for items that debaters believe are done but the Group Lead needs to check. “Done” is for items that have been completed. Only the Group Lead should move items into the “Done” column.
This model also means that files should be sorted differently during Sprints. Assignment Groups should have a shared cloud folder (Like Dropbox). Different Assignments should be in different folders (Heg folder vs Aff Case folder), and then should be split into Master Files and Daily Files. Master Files are the final product of a Sprint. While the Sprint is in-progress, the Master File will be organized in an outline format with headers reflecting list items. Daily Files are for the work that are done on a given day by individual debaters. As Daily Files get verified and categorized as “Done,” they should be compiled into the Master File.
Team-wide file sharing method doesn’t matter that much. Can be a listserv, dropbox, POLICYDB8 CLUB, Onedrive, etc.
Other recommendations for a more tech-minded team would be self-hosted file sharing web applications like ownCloud or NextCloud, both of which have integrations with various chat or project management features that could aid in the execution of this kind of assignment process.
So why use this model?
This sounds complicated, I know. It takes more thought than just “hey debater, what do you want to work on? Cool, work on that." However there are a variety of benefits.
Makes work manageable
Overwhelming younger debaters is real and burnout is real. Incrementalization makes tracking progress on file work simple and ensures that work levels are easily changed without the typical "so and so checked out" or "x novice/JVer doesn't get it" appearance. For many who don’t have as much experience, the idea of doing a file by themselves is daunting to the point of not being able to accomplish anything. For many who have other life, school, or work events come up, the idea of taking regular large files sounds like a recipe for stress and disaster. By nature, this structure teaches debaters how to approach file structure, how to manage time, and how to ask for help.
Educational for less-skilled debaters
Understanding what goes into mapping out a file and how to manage doing file work can be elusive for debaters. By doing this process in a collaborative environment, lower skilled debaters can learn from more experienced debaters how to do so by effect of Sprint Planning sessions. Moreover, Daily Scrums are an opportunity for direct engagement and consultation between debaters and coaches as well for advice and assistance.
Ensures file work is transparent and debaters are honest about their limitations
There is always an issue of debaters volunteering for more assignments than they are capable of. By reducing file assignments to a variety of small parts that are individually worked on daily, debaters get a better feel for how much time they really can put into debate in a day and how much work they can do. Part of the function of the Daily Scrum is for debaters to be up-front about how much they think they can accomplish that day. This resolves a lot of the “bite off more than they can chew” problem. Moreover, the assignment boards and direct involvement with their group and group lead ensures that progress is shared in an open environment. This means coaches and group members have a solid idea of how files are coming along. It also means that coaches have a better indication of when they should intervene with debaters who have trouble completing their assignments.
Creates an environment for consistent work being done
Oftentimes assignments are levied on a weekly basis for debaters to finish, leaving it on them to determine how to balance out work on a given file. For more than a few, this results in procrastination and last minute all-nighters, typically resulting in a lackluster file or vague excuses like “uh I ran into walls while researching.” Daily goal setting in Daily Scrums means daily work being done.
Allows for flexibility
The Scrum model can vary in scale on time, group size, and level of engagement based on a given squad’s needs. Even further on flexibility, the incremental nature of file work along with the open showing of file work done means that any given person in a group or the group lead can pick up where someone left off and finish a file.
This may sound unwieldy for effectively operating during the regular season, especially when considering school, classes, and so on interrupting the ability to regularly work or coordinate. Something important to note is that the time period for Sprints can be scaled down as much as necessary (like getting assignments on Tuesday for a tournament starting Friday) and Assignment Groups do not always have to take a massive group of assignments. Clearly people can take a break on days when it’s necessary (need to do schoolwork, need some personal time, the assignment list is small and doesn’t require everyday work) or skip Sprints when necessary (midterms week, finals week, family vacation, etc.). The advantageous thing about the Scrum model is that it is flexible by design, capable of many different degrees of intensity.
Lastly, this is a valuable resume material
Learning project management and having experience in it (particularly a popular method like Scrum) is a valuable skill that is marketable. While debate has a variety of different portable skills that can be pointed to (public speaking, critical thinking, research, etc etc), a lot of those can sound vague to an employer. Being able to say “I have x number of years of experience in Scrum project management as a development team member/scrum master/product owner” is much more tangible and is an attractive resume item.
Find this interesting?
Discuss it in the comments or the forums. The best thing about a model like this is that it is and should be adaptable. Most importantly, it is something I want to get feedback on and discuss.
Want to go even further? Policydb8 will be doing a free summer workshop for high school debaters that will use this model to produce files as well as give lectures to equip them with the necessary tools to avoid camps. If you're interested in participating (even if you are not a high school student), stay tuned to our email list and/or social media pages for further details.