[MUSIC] Welcome, to the final module of the course. In this module, I'm going to talk about retrospectives. Let's get to it. Retrospective is a term used in the software development community, to describe the act of reflecting back on work that was done and not done in the project. There are two essential types of retrospectives. Sprint retrospectives and project retrospectives. The basic idea behind a retrospective is to reflect on what went well in the project, what didn't go well and what can be done to improve the process going forward. In a sprint retrospective, this is done by reflecting on what happened in the last sprint. Remember how, in the Agile Planning in Software projects course, I talked about time boxing and Morgan talked about iteration planning. Well, both of those practices introduce the idea of organizing your time into small, manageable chunks. After those time box chunks, at least in agile projects, it's important to also have a planned self appraisal session. This is a Sprint Retrospective. In Sprint Retrospectives, the insights learned from the team self appraisal is then applied to the next Sprint, which allows the project to regularly improve. The team selects what is important and what should be focused on. This gives the team a sense of contribution to improvement and allows them to own it. It helps the team to be internally motivated to succeed. They don't need outside forces, pushing them to improve. In a project retrospective, sometimes called a postmortem, the team looks back over the entire project, when the entire project has been deemed complete. One of the major differences, with the project retrospective, is that there's no next sprint to which the lessons from the retrospective can be applied. That shouldn’t stop you from practicing project retrospectives though. Even though the current project might not have a next sprint, there are likely to be other projects on which team members will work. They could be other projects that the team works on together, or the team could disband and go on to other projects. That doesn't matter. What does matter, is that the entire team gets the opportunity to reflect on the project as a whole, and to take lessons learned into future endeavors, whether separate or apart. Another really important reason to have project retrospectives is that they allow the team a cathartic release of energy. In most projects, there will be personality differences, disagreements, and compromises made. If, at the end of a project, these are left unresolved. It can be unhealthy. Having a project retrospective, gives the team the ability to settle their differences in collaborative open atmosphere. Free from judgement. We'll talk about ways to make sure that you achieve that atmosphere in the next lesson. What are two reasons to conduct a software postmortem retrospective? A. Apply lessons learned in the previous project to future projects. B. Guarantee that issues in previous projects do not occur again. C. Allow team members to mend damaged relationships with one another. Or D. Postmortems should not be done at all. The answers are A and C. Postmortems are a great way to apply lessons learned to future projects. As well, as get people the chance to talk about their experiences openly and repair wounds. The value of doing a retrospective is pretty clear. But what happens when you avoid doing them? Well, think about a scrum project in which you didn't do sprint retrospectives. What would happen after each sprint? It's likely, that the team would plan for the next sprint and jump right into development. In fact, this often happens. However, without allowing for reflection, these projects tend to continue as they have before. Without any explicit sense of what is going well and what is not going well within the project. People may have their feelings, and they may express those feelings regularly. But without a team-wide retrospective to capture those feelings, it's difficult to make a team decision on what needs to be changed, and what should stay the same. Remember, no matter how great your team is, there is always room for improvement. Nobody's perfect, we're not machines. So, instead of avoiding reflection in your projects, encourage it. The resulting improvement is often tangible. So that's what a retrospective is and why you should use them. In the next lesson, I'm going to talk about some issues surrounding retrospectives, I'll see you there.
