As an lone, Agile (PXP/PSP) developer what is the proper structure for a formal project post-mortem? [closed]

Question

Question:

As an lone, Agile (PXP/PSP) developer what is the proper structure for a formal project post-mortem?

Scenario

I'm using a PXP methodology (which is a blend of extreme programming and the personal software process) to work on an undergrad project. The project revolves around computer vision and architecture.

Although the project has a lot of potential for future improvement, I need to write a project retrospective for this release. I'm used to working with an SRS (requirements specification) and DSD (design specification document) with a structure like :

Introduction

• Purpose
• Scope
• Definitions, acronyms etc.

Description

• Product perspective
• system interfaces
• interfaces
• Hardware Interfaces
• Software interfaces... constraints etc.

Requirements

• Performance, interfaces etc...
• Attributes for security, portability etc.

DSD

• system overview -Design consideration
• Architecture
• detailed system design ... etc.

However, agile project as we know revolve more around stories than functional requirements, and firm designs. A recommended non-agile structure for this final report is :

Introduction : - Literature review : - planning : - statement of the methodology used.

Design :

• requirements
• design aims

Implementation - language choices, coding guidelines etc.

Evaluation - evaluation of how good the algorithms are.

I've not been able to find an example online of a definite project postmortem structue for a PSP project (even the documentation 1 does not mention how it should be structured).

Answer 1

Imposing a strict structure on retrospective document is not very agile itself.

In Agile, you don't find strict rules you have to follow at all costs, such as:

• “Unit tests should be written prior to code.”

• “The code should have at least 95% code coverage.”

• “Each public and protected method should have documentation explaining its usage, each parameter, the return value and, if any, the possibly generated exceptions.”

The reason is that you may find yourself in a case where it's obvious that the rule makes more harm than good for the whole project, thus requiring the team to adapt the rule to their particular case, rather than adapting the process to the rule:

• A team may notice that, unlike in other teams, following TDD prevents flexibility they had when they were writing code first, while having only minor impact on the quality.

• Another team may find that developers spend weeks trying to go from 94% to 95%, increasing the risk of delivering the software late, while also decreasing code quality, since they spend less time doing code reviews.

• A third team may discover that programmers are demoralized documenting boilerplate code, instead of doing real programming. Also, they tend now to make fewer efforts writing self-documenting code with self-documenting names of methods.

This is exactly what retrospective is done for. So why not adapting the retrospective itself?

Note that:

• The retrospective would never be the same: if the process evolves, you'll have a different type of problems each time, which will have an impact on the retrospective.

  The very first retrospective may be centered around the overall organization of the project: the fresh team just started the project, and not everything is satisfactory enough. They picked Scrum, but some guidelines of Scrum seem not adapted for this team; on the other hand, they would like to use some guidelines from XP. The team is also in two buildings, making communication more difficult that is should to be. The team also notes a hundred more impediments to be solved.

  The second retrospective is principally axed on estimates: indeed, the team estimated to be able to do twice what was really done. Two major reasons for this is that (1) the most skillful developer of the team was sick during the second week of the sprint (what should the team do to handle “Hit by a bus” scenario better in the future? Why losing a member of the team had such consequences? Do they have cowboy coders in the team?) and that (2) system administrators were too busy to deploy the project regularly (Won't DevOps help?)

  The third retrospective concerns mostly the deceivingly terrible quality of some pieces of code found during code reviews (Are programmers sufficiently trained? Have everyone in the team read Code Complete? Do deadlines encourage sloppy programming?) and the fact that the representative of the customer is never available to answer the questions (Do we need to hire an expert instead? Do we need to be frank with the customer and ask to be more involved in the project?)

  As you can notice, imposing a strict structure on a retrospective report wouldn't be obvious, and would only make the report less clear. For example, the most straightforward structure for the second retrospective would be:

  1. Actual estimation process

     • Description of the actual estimation process,

     • Specificity of this process compared to what is used by other teams in the company.

  2. The actual issue 1: “Hit by a bus” scenario

     • The code is not documented enough,

     • There are no enough communication inside the team during the sprint, so members sometimes ignore what other members do.

  3. The actual issue 2: cowboy coders

     • The lead developer don't care matching the common rules used by the team,

     • The lead developer is not a team player and should look for another team.

  4. The actual issue 3: no DevOps

     • System administrators are too overwhelmed to deliver the product on time,

     • DevOps can help.

  The same structure makes no sense for the first or the third retrospective.

• The retrospective itself should adapt itself to needs and constraints of the team.

  This means that from team to team and from company to company, you'll find differences in handling retrospective meetings.

  A company where the CEO wants a report after each retrospective would organize the retrospective differently from a company where what is said during retrospective is known only by the team.

  A team of three developers would have a different retrospective than a team of twelve.

  A retrospective of a team of persons who are afraid of being criticized in front of their pairs would have nothing to do with a retrospective done by a team where people welcome constructive criticism and see it as an excellent way to improve.