How  Lessons Learned are Managed

GMAT lessons learned include things that we did well and should keep doing, and large scale things we should be doing to improve the software or our project.   Lessons learned are each discussed by the team and if we decide there is a real issue, we require a plan for improvement.   To make sure we are efficiently handling lessons learned, here are some high level guidelines for creating them.

What is a Lesson Learned

Lessons learned are issues that cause significant problems or could have caused significant problems, or are issues where we did something that significantly improved the software or our project.   Lessons learned require group discussion and probably a change in team habits, process or strategy.

Lessons learned satisfy one the following criteria:

• Issue that is putting the project at greater risk than necessary

• Issue that is causing significant inefficiency

• Issue that is significantly lowering quality

What is Not a Lesson Learned

A lesson learned is not a minor annoyance, a tweak to an existing process, or something that can be resolved between team members in the everyday process of getting work done. Team members should bring these types of issues up at meetings, or work them among the team members involved.

A minor issue, (i.e.  not a lessons learned), satisfies one of these criteria:

• Tweak to an existing process

• Minor annoyance or gripe

• Can be resolved by just picking up the phone, or discussing via email, or weekly meeting

• Does not require significant change in habits or processes

Things We Should Keep Doing

• [EGD] Continue utilizing Jira to track work items and narrow the focus to what is needed for the customer with nice to haves mostly being spin-off tickets

• [EGD] Test system setup to run on different python versions and system configurations.

Things We Should Change

Do Better

• [EGD] update third party dependencies earlier in the release development cycle

  • [SES] Remove unused dependencies (Xerces)

• [EGD] provide a bread crumb amount of information on tickets so someone with GMAT dev team experience can retrace the steps of the work performed

Start Doing

• [EGD] Performing regular pushes to the GitHub repo on around a monthly or as-needed basis

• [EGD] Have periodic schedule planning sessions for work items to consider in the near future in the event current work is completed ahead of schedule or customer funding becomes available

• [DJC] Run static analysis and dynamic analysis periodically (monthly?) and fix issues uncovered in those runs

Stop Doing

• [EGD] Implementing functionality only for a single customer that makes its usage strictly limited to that customer for a feature other customers will also want..

• [EGD] Drilling down aiming for perfection of an implementation once the “good enough” implementation has been achieved. “Good enough” still includes implementation that will not break the system’s architecture and follows agreed upon design principles.