Skip to content

Latest commit

 

History

History
39 lines (31 loc) · 5.66 KB

01_VirtualStandup.md

File metadata and controls

39 lines (31 loc) · 5.66 KB

Virtual Standup Report

For anybody who does research in the lab should submit a Virtual Standup Report twice a week. There is no a separate submission system. Rather it is one Google Docs document that you maintain on your own. The idea of standup meeting comes from software engineering industry. You just get together and talk about what you did the day before and what you will do on the particular day. For us, becuase we don't get together in the same place at the same time (maybe we should?), we do this virtually; submitting a brief report in a Google Docs.

The goals of submitting Virtual Standup are as follows

  1. self-reflection
  2. practicing identifiaction of tasks
  3. practicing estimating how long it will take to complete a task
  4. regular communication with your peers (primarily your advisers)

Use it to recall what you have done a last few days and to plan what you are going to do for the next few days. If you have done nothing, and if you are not going to do anything at all, still submit it with empty parts. We want to have visibility on not being able to make any progress as well for self-reflection.

Here is a sample virtual standup report: https://drive.google.com/open?id=1hTWOfzuCnW8Qs8VYlUq1ubUQnNDSmf0cti57owHQBko

Policy

  • The report will be shared within the lab. You can learn what other folks are doing by reading this.

  • On the top of the document, maintain a long-term to do list with associated due date. Everything has a due date.

  • Below the table it should have a report in reverse chronological order(the most recent on the top) .

    • Each report starts with the date of submission
    • It should contain the following three sections
      • (completed) the tasks that were compmleted since the last standup
      • (plan/in-progress) the tasks that you will work on until the next standup
      • (blockers) anything that kept (or keeps) from you making a progress (e.g. ilness, too much courseworkload, mid-term exam, collaborators, emotional challenges) Note that this repot is open to your colleagues so you should not write anytihng that you cannot open to peers for any reason.
    • Anything that is written in the report should be a fact. A fact is a statement that can be verified. It can be proven to be true or false through objective evidence. Any task should produce an artifact (typically digital artifacts - file, document, file, annnotated pdfs, pictures of whiteboard)
    • Example 1 ) "some ideas through brainstroming" is true only if there is a document that has a list of ideas
    • Example 2 ) "Read one paper" is true only if they wrote a summmary and reflection (evidence).
    • Example 3 ) "Spent some time to explore ideas" can never be a fact because you cannot prove with an evidence.
    • Example 4 ) "Looking into Matlab" can never be a task - it does not produce an artifact.
    • You may say there are certain types of works that are not visible even after you complete it. For example, reading someone else's code can be it. If so, change the way you work so that your putting efforts into something will ALWAYS generate some sort of artifacts. (e.g. if you read someone else's code, document the code with comments or come up with some test cases that you ran, or even capture your screen) This is obvioiusly better for collaboration and also better for yourself as well because you collaborate with yourself (you from the past or you in the future).

  • if a task appear in the (plan/in-progress), your goal is to make the item appear in the (completed) section by the next time that you submit the report.

    • Try your best not to have any orphansed task items. This means that you plan something that you are not going to do.

    • The whole purpose of the "plan" part in the stand-up report is to practice planning and estimating. One way to work is to simply work whatever that you have to do at the moment and report whatever done in the standup report in retrospect. If so, we don't need to put anything in the "plan" part as long as you know what to be done. However, this is not research. Eventually getting a Ph.D. (or becoming a competent professional) is being an "independent researcher (or independent problem-solver)". "independence* is the essential component here. You need to be able to identify what to do, plan ahead, estimate the completion time, and execute the plan.

    • This part of the report is for you to practice identifying/planning/estimating and improve your capability to estimate a doable unit of work that can be done by a certain time. I care less about you keeping to your plan. I don't like over-promising (write the whole paper vs. write one paragraph of the paper) or vague plans ( e.g. read more papers / work on programming / start working on vs. reading CHI 2019 by Guo et al. paper/writing code for prototyping). Rather, I would rather like an honest plan - for example, "not planning to work until next Tuesday due to the blocker".

    • This is not "promise" but "plan". Things don't work as they are planned, which I understand. If something cannot be done by the next report, decompose the task into subtasks that can be done by then. Rather, I would like you to be good at planning, estimating how long it will take to complete a task, and decomposing a task into subtasks. This was my opinion but I would like you to discuss with you if you can tell me why it is challenging to write the stand-up reports.

  • If you have done nothing for particular period, submit a empty report. Missing reports from time to time is fine. Unexpected things happen. However, if it becomes your habit, you want to keep track of this behavior and reflect on it too.

  • The project advisor (typically Sang Won Lee) will review the document and leave comments on the report.