How can we implement Continuous Improvement with the Retrospective Ceremonies? The Concept of a Retrospective ought to be familiar to anyone Working on an Agile Project. There have been several names over the years. These names explain this activity of Reviewing what happened throughout a Project, such as “post-mortem” or “lessons learnt”. Some may argue that these are not the same thing for a variety of reasons. However the inputs, discussions and actions arising out of such Meetings are Fundamentally the same.

There are different adjectives one can hang in front of the word “Retrospective”, such as “Sprint”, “Release” or “Project”. This defines the Scope of what is to be Reviewed. Any Sprint Team member will have participated in a Sprint Retrospective, and knows its Value. At the end of a Project, the holding of a Project Retrospective is often perfunctory or omitted altogether. This often happens because the Team is being dissolved, now that the Project has actually finished. This is a serious oversight of a very Valuable tool for process improvement, not just for future Projects, but for the Company as a whole.

Continuous Improvement: The Value of the Project Retrospective

A Project Retrospective can add incredible Value to the Company. This value is added in a variety of methods due to the fact that of the Learning it brings. This value can be achieved even with small Projects that have held regular Sprint Retrospectives. The Project Retrospective can combine all the experiences from those Sprints into a Roadmap for subsequent Projects. It can likewise examine other areas of Product Development, such as Stakeholder Management and Product design.

If there were lots of change demands during the Project, it can indicate that the design process needs strengthening. It can also suggest that the right Stakeholders were not engaged. Or maybe their Requirements were not understood and translated into relevant User Stories. The general sentiment of Stakeholders towards the finished Product can also be Reviewed during the Sprint Review meeting. This is in order to figure out whether expectations were met. If they have not been met, what can be Done to remedy this is future Projects. Feedback can be implemented as soon as the next sprint and should be planned during the Sprint Planning Meeting.

Continuous Improvement: Aligning large Projects.

A benefit that a Project Retrospective has over a Sprint Retrospective is that it can bring together multiple Teams. This allows for cross-fertilization of ideas and experiences. The Project Retrospective is not restricted to a Meeting at Project close-out either. For large Projects, it may be suggested to have more than one Project Retrospective. A first Retrospective could occur halfway throughout the Project for example. In the Scrum Framework, large Projects are governed via a “Scrum of Scrums”. While Meetings are held to align the various Teams, a Retrospective will benefit from the collective wisdom of all the Teams.

Continuous Improvement: Learning from Failure

It is a sad fact of life that not every Project succeeds; some are cancelled and some fail. While Agile is structured in such a way that a floundering Project can “Fail Fast”, this is not the time to walk away. Rather, this is the time to learn from mistakes made along the way. We should look to ensure that they will not happen in the future.

There are many reasons why a Project may fail. It is not always the case that the Development Team did not Deliver. In fact, the problems often arise in the design phase. A poor or inadequate blueprint of what the Minimum Viable Product should be will never result in a successful Product. That is no matter how hard the Team tries or how many changes are applied. Utilizing the Project Retrospective to unearth why a Project Failed is the first action towards ensuring failure does not re-occur.

Taking advantage of Success

Successful Projects similarly can include to the repository of Company knowledge. Where process improvements were identified throughout the Scrum they can be applied to the next Sprint. Care needs to be taken that the understanding acquired is not lost when the Scrum closes down. While this can be achieved through other means, the Project Retrospective is an formal way of recording:-.

• why the process needed improvement.
• how it was improved, and.
• the measurable Benefits it gave the Project, such as minimized time to finish, reduction of problems or more reliable Teamwork, compared to earlier Sprints.

We found these books great for finding out more information on Agile Scrum:

There are other elements of the Project that might have been enhanced, such as:-.

• accelerated Team maturity and/or a decrease of dispute through utilizing specific Tools and techniques.
• Improvements in the conduction of Ceremonies (Meetings) in Scrum, by adhering to the Framework, as coached by the Agile Scrum Master.
• Improved knowledge transfer and how it was achieved, such as the Scrum Product Owner coaching all Team members how to compose pertinent User Stories.
• New Tools and strategies that were attempted that added to or interfered with Project success.

All of these would have a direct Benefit on Projects moving forward. The Benefits could also extend beyond Agile Development into the IT space. It can supply Valuable lessons for the rest of the Organisation.

Ensuring the Lessons are not Lost.

In order to increase the Benefit of a Project Retrospective, the audience ought to be as large as possible, without making the Meeting too large to be Manageable. Apart from the Product Owner, some Stakeholders must attend, in addition to someone from understanding Management and process Management. Representatives from other Teams need to likewise be invited, specifically if it was a Multi-Team Project. This must likewise be weighed up versus how well the Scrum Development Team will react to the general group; it is vital that no-one feels frightened, or holds back from expressing their opinion, no matter how questionable.

The earlier Iterations of Retrospectives, that is post-mortems and lessons learnt were frequently not successful and dreaded by the participants due to the fact that they tended to end up being “Blame Games”. The Scrum Master who assists in a Retrospective knows how to avoid this, while getting active participation from all his Team members.