Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • Project Management In Debate


    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.)


    Scrum Team

    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.


    Scrum Events

    - 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.


    Scrum Artifacts

    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.


    Additional notes:

    • 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.

    Edited by ColinD

    • Positive 1

    User Feedback

    Recommended Comments

    There are no comments to display.

    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.

    Add a comment...

    ×   Pasted as rich text.   Paste as plain text instead

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

Terms of Use