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


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 :


  • Purpose
  • Scope
  • Definitions, acronyms etc.


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


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


  • 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).

  • 1
    It is unclear what kind of help you need. A retrospective is usually a meeting in which the team looks back on what went well and what didn't in the last period and what improvements can be made to the process to keep the good things and improve one or two areas where improvements can be made. – Bart van Ingen Schenau Apr 6 '14 at 7:49
  • @BartvanIngenSchenau: I think the OP is looking for a structure of a document produced as a result of a retrospective. I see two possible cases where a retrospective would be followed by a document: either when the boss wants to be informed in a formal way by the impediments encountered by the team, or when (which is the case of the OP) the team of one person wants to keep trace of the work (when you're alone, writing down the contents of the retrospective makes sense). – Arseni Mourzenko Apr 6 '14 at 8:41
  • @MainMa: That is a possibility, but I couldn't derive that with enough confidence from the question. – Bart van Ingen Schenau Apr 6 '14 at 8:53
  • I think I meant the retrospective to be the act of wrapping up a release and writing a report on it.. from an agile perspective. @MainMa you are correct. I need to formulize the lessons learnt. – peter_gent Apr 6 '14 at 14:29
  • Isn't there a script in PSP for this? Perhaps an extension or modification of the PIP template? – Michael Apr 8 '14 at 19:14

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.

  • by team though :- I'm a lone developer so what can I do in this case ? – peter_gent Apr 8 '14 at 20:49
  • @peter_gent: my answer applies to a team of one too. – Arseni Mourzenko Apr 8 '14 at 21:58

Not the answer you're looking for? Browse other questions tagged or ask your own question.