Mach 30 #EngineerSpeak Hangout Sept 17, 2015

Discussion Topic:  Sprint 2 Stand Up 6 and Sprint Review

Attending: J, Juli, Chris, Jeremy, Chris

Start:  2210

End: 2310

Summary:

Closed out Sprint 2.  While not all PBIs were completed, the most critical PBIs for MTK development were completed, successfully demonstrating the move to IPython is the way to go for MTK.

Proposed tweet:

Mach 30’s MTK, an engineering analysis and documentation tool, adopts IPython, Jupyter, and Anaconda.

Minutes:

• Stand up

• Aaron

• Did - noted that there are too many variables impacting the material properties (maybe around 20 beyond the details of printer differences); tried to verify the data already in the report, but got blocked because the variability in material properties looks to be too large for a general report (blocked on this PBI)

• J

• Did - did not get around to helping Jeremy with installer

• Jeremy

• Did - did not get to working on the installer during the sprint (did make a little progress since: fixed a bug that broke IPython and researched how to set auto-loaded extensions)

• Chris

• Did - didn’t do anything

• Sprint Review

• <Chris noted that the Sprint ended on schedule, but the review was postponed for scheduling reasons; this is important to keep track of for computing velocity>
• YVN-09: Add an abstract to the MTK document of the Yavin thruster for non-technical readers - DONE
• MTK-05: Reproduce "MTK Basic Test 01 - DONE (expect to modify as MTK is re-implemented in IPython)
• MTK-06: Reproduce "MTK Basic Test 02 - DONE (expect to modify as MTK is re-implemented in IPython)
• MTK-07: Reproduce "MTK Basic Test 03 - DONE (expect to modify as MTK is re-implemented in IPython)
• YVN-15: Investigate alternate 3D printer materials instead of PLA - BLOCK

• Report as of last edits
• Up for stakeholder review as to what to do about risk management for Yavin

• MTK-02: MTK needs to be installable on Linux via a script - NOT DONE

• Jeremy - The installer currently installs iPython and the notebook extensions, but currently does not load the extensions in the notebook (there is an issue with loading them from the current system-level installation location).

• MTK-09: Facilities in iPython to better style documents created in notebook - NOT DONE

• Note that this was scope creep on the sprint

• Retrospective

• What we did well

• IPython seems to be a better solution than Sage
• When it was working, the installer was super helpful for ensuring consistent development and testing of MTK documents
• Anaconda looks like the way to go for the basic infrastructure of MTK’s computing engine (need to try it out on other platforms than just Linux)
• Lots of data was harvested; this is especially helpful for being able know what we need to do moving forward.
• Doing a better job of removing single points of failure

• What didn’t go well

• Didn’t finish several PBIs (YVN-15, MTK-09, MTK-02)
• Several folks ended up not being available half way through the sprint
• Didn’t realize how many issues would arise from the physics of FDM process is too variable to use data for safety calculations.  Error bars exceed margins.
• Naively added an extra PBI (MTK-09) to the sprint that ended up not getting worked on

• What can we do better next time

• New from this sprint:

• Have team members review their calendars in detail to improve capacity estimation

• May also be helpful to publicize this information on an ongoing basis

• Stakeholders should consider being more active to address PBIs that aren’t working (eg, we should probably have removed YVN-15 before the end of the sprint as it could not be completed as specified)
• When no work has been completed on a PBI that is in-progress for more than a week, the team should see if they can help fill the gap
• We need to know that we may need to rely on our own processes and data for confirmation at least, if not for the primary research data.
• We also should be more cognisant of the potential size of PBI’s, such as YVN-15

• Carry-overs from previous sprint review:

• Try to eliminate single points of failure - have people that can act as backups for workload.
• Possibly ship replacement or otherwise known working parts to team members having hardware issues.
• Refine the EC review process, both in terms of automation and in terms of sequence.  None were major issues.
• Would prefer to not wait until the last minute (even just week to week) to do the committed work
• Weekly posts to P2 or the blog based on the stand ups