We recently added a relatively large feature to our product that involved the entire R&D department (with all the different teams within it).
This feature included UI development, server side development, and huge migrations of SQL schemes (and other stuff that I myself was not involved in at all).
The development process for this feature was chaotic – Front-End and Server teams were not synchronized, SQL migrations broke the DB, and product specifications were incomplete which meant that with every step of the way we found new issues with the initial definition, requiring changes to core concepts that the developers had relied upon.
All in all, a feature that was planned to be released within 10-14 days, took roughly 24 (intensive) days of development.
I was requested to write a report of ‘What went wrong’ (from my team’s side – each team writes such a report from their pov).
What are the common methodologies for writing such reports, specifically in the field of software development?
Also – Is there some formal name for such reports?
EDIT & ANSWER:
Apparently, such a report/review-process is commonly referred to as ‘Project Post-Mortem’ (other names exist as well).
After figuring this out, I found these two resources that outline suggested methodologies for gathering the necessary data, organizing it, analyzing it, and formulating solutions for discovered issues (as well as some general information on these reviews and their purposes):
‘A Defined Process For Project Post Mortem’ –
http://www.csee.umbc.edu/courses/undergraduate/345/spring12/mitchell/readings/aDefinedProcessForProjectPostMortemReview.pdf
‘Post-Mortem Reviews: Purpose and Approaches in Software Engineering’ – http://www.uio.no/studier/emner/matnat/ifi/INF5180/v10/undervisningsmateriale/reading-materials/p08/post-mortems.pdf
7
Having done this many times, this is the format that I have used successfully in the past. The order these headings are presented in will also make a difference in how the report is received by management. Whenever possible, leave them with a good taste in their mouths.
This shouldn’t have to be said, but… keep your language professional throughout the report.
What happened?
Describe what happened, both good and bad. Give details about each incident. Do not place blame. Keep opinions out of it. Imagine your self as a reporter who is telling the story of what occurred.
What went wrong?
This is the hard part. Admit to what you, your team, or other teams did wrong. Keep blame out of this! Just state the facts. “We (my team) made breaking changes to the database that caused delays for entire development group by X number of days.”
What went right?
Part of the telling of this story should include where your team, or other teams, did the right thing. Communication of delays, changes, etc. “We added significantly more columns to tables X, Y, and Z. These columns will allow us to track something.”
How do we improve the process?
This is where you start to display some opinions. You were asked what happened and what could be done to fix it. State your opinions supported with facts. “When we made the breaking database change, we should have implemented these changes on a separate development database.”
2