Project Retrospective

At the end of each project owned and ran by Lab651, a project retrospective should be completed and documented.  The idea of the retrospective is to give all involved parties a way to input what went right and what went wrong.   This process should be done internally with the entire team and, if the client is amenable, with the client in a separate meeting.  For the client meeting, the engineering team does not have to be present, but it is good if they can be.

This section outlines two different retrospective approaches.  The Long Format Retrospective and the Simplified Retrospective.   Which one to use will be determined by the project size, project complexity and client characteristics.

• Project Size - Small projects (in scope or length) will benefit from the simplified process.
• Project Complexity - With a large number of components (data centers, CI/CD, Web, mobile etc..) or departments (dev, dev-ops, QA, analytics) a more complete process may be desired to talk about more of the moving parts and how they work together.  So, a long format may be desired. 
• Client Characteristics - The client’s temperature, patience and interest-in-process will determine if you want to put the client through a short or extended meeting.  

At the end of either retrospective, a list of process improvements should be included in the documentation and a meeting regarding process improvement ideas should be held, internally.  We use Agile for development and we should be agile in all of our corporate processes.