Retrospective Audit 1 Semester2

by Team OptoFab @TechLauncher

6 min read August 16, 2021

Tags

• Audit
• Retrospective

Our team project is a continuing one from last semester focusing on the implementations of a Customer Portal and a Local Order Management System for ANFF OptoFab ACT.

Table of Contents

1. Details
2. Rubrics
3. Feedback
   1. Project output
   2. Decision making
   3. Team work
   4. Communication
   5. Reflection

Details

	Information
Date and time	11/08/2021 17:00-19:00
Participants	@Phillip Wu @Wo Tian @Ruiqiao Jiang @Ruoqian Wu @Yaoyi Xu @Hengrui Xu @Guoyu Wang
Tutor	Greg Bek
Examiner	Priscilla Kan John

Rubrics

Refer to: https://cs.anu.edu.au/TechLauncher/current_students/evaluation/project_audits/

Feedback

The feedback is based on the reports from the TechLauncher Feedback Portal.

Update on 18/08/2021 after the tutorial:

Thanks to the candid critiques and valuable feedback from our tutor and shadow team, our team has learnt to better improve our project in terms of decision making, team work, communication and reflection. So we’ve put a strikethrough on the question mark below [?]. For more details, please refer to our meeting minutes for week 4 tutorial here.

Project output

Good

1. Landing page is well developed;
2. GitHub repository main page has a really useful set of instructions on building and running the app
3. Project management
   1. The team has been able to set reasonable goals and timelines.
   2. Administrative and planning tasks seem to have been completed effectively and without issues.

Bad

1. Landing page:
   1. One has to scroll down to find information
   2. Table of contents in dropdown menu conflicts with navbar [?]
2. SOW (Statement of work):
   1. SOW does not outline what deliverables you will make and how progress will be measured by your team and your customer. [?]
   2. Statement of Work seems a bit lacking with only few information in it and very little analysis and details included
3. Weekly schedule:
   1. The weekly schedule doesn’t describe what will happen beyond a set of programming tasks
   2. The schedule is waterfall in nature, which doesn’t offer much opportunity to seek customer feedback on the website and react to it as the semester progresses.
4. Risk register
   1. It doesn’t seem to have been reviewed recently.
   2. It is concerning that you consider the risk of serious data mismatching as Possible “Risk will likely occur”. [?]
5. Project management:
   1. There have been a few instances where the team have had to refactor something multiple times because they started before finalising design/negotiation with clients on that aspect of the project. [?]
6. [The website]:
   1. The footer is hard to read since it has a blur effect over it. Such important information about the product should not be hidden.
   2. Do add more spacing between each paragraph. There are dashes between each section but a larger gap will make reading the website easier.

How to improve

1. Landing page:
   1. [homepage toc serves a different purpose than the navbar]
   2. Consider separaring out the decision log into a separated document,that is kept in your repository so that new version can be tracked.
2. SOW:
   1. [ lesson learnt, need to avoid the same mistake in the future ]
3. Weekly schdule:
   1. Considering demonstrating work in progress to client throughout the semester to get feedback and guidance.
   2. [ can only afford one sprint, agreed by client , slack…]
4. GitHub repository:
   1. Considering a section at the top describing what tools need to be in place for a new person to be able to clone and run the project (i.e. Node Package Manager is an obvious requirement).
5. Risk register:
   1. Starting to review risk register immediately and making sure content is valid.
6. The website:
   1. [Paying attention to user experience such as legibility and page layout.]
   2. [will use React.js to customize layout and improve legibility]
   3. [footer is deprecated in our design]

Decision making

Good

1. Decision is very readable, having the retrospective/rationale presented alongside the decision makes it easy to follow.
2. The team reacted quickly and they were able to make the decision and minimise its negative effects on the rest of the project.
3. The team have also shown good prioritisation in setting their goals. Moving their current aim to a ‘minimum viable product’ first was a good choice.
4. It is clear that the team are cognisant of not overpromising and have a clear idea of timelines when negotiating with clients.

Bad

1. It is hard to find the previous sem decision log in any of the links provided.

How to improve

1. Consider separating out the decision log into a separate document, that is kept in your repository, so that new version can be tracked.
2. [Include the decision logs from previous sememster.]

Team work

Good

1. The team charter is well developed which is expected for a project that is not in its first semester.
2. It’s clear that each team member has their own roles, and that their coordination is effectively utilising each individual’s strengths.

Bad

1. The team have made the project manager a single point of failure, should they become ill or unavailable.
2. Team charter:
   1. The core values could be elaborated upon, what does it mean for your team to be “respectful”? To each other? The client?
   2. Team charter doesn’t outline what is expected from each member apart from their skills.
3. It may be too early to judge team collaboration until substantial work has been done but evidence of team work can be better shown with more detailed communications documentation and better formatted to do list. It appears difficult for an outsider to understand the to-do list as it is. [?]

How to improve

1. The team should make sure that the deputy spokesperson is in a position to backup the project manager, and that in turn one or two other team members shadows the deputy. [?]
2. Team should maintain a work log to track hours spent from each member.
3. [Refine the team charter with more details, including: what’s expected from each team member; explanations for the values;]

Communication

Good

1. The plan focuses on times and tools, and does outline how you would work with your client to raise issues or deal with feedback.
2. Overall the teams communication with clients has been quite effective when negotiating goals and timelines for the semester.

Bad

1. Meeting minutes are too brief without enough details
2. Though it is clear that the team has benefitted from having one person communicate with the client, the client mentioned a lag when contacting the necessary members of the team. [?]

How to improve

1. Try to minute more details of the discussion to for future review.
2. It would be great if the team could include the agreed decisions after each discussion item.
3. It is suggested that the team assign a Front End leader and Back End leader to join the client meetings together with the project manager. [?]

Reflection

Good

1. The team has shown that they are very capable of learning from their previous semester working with us

Bad

1. One couldn’t find any reflections beyond those listed in your decision log.
2. There is no clear reflection documented on the landing page.

How to improve

1. The team should have a reflection log, and individually every team member should have some reflections to capture as well. [?]
2. It would be better if the team could add the rationale behind each risk or even add a reflection log to show evidence of reflection among the team. Similar to the decision log, what exactly happened that gave rise to each risk. [?]
3. [Incorporate the reflection in landing page]