Scrum is an adaptive process. One way Scrum teams achieve this is by conducting regular retrospective meetings to talk about what was successful in the last Sprint, what could be improved in the next one, and new ways in which the team could get better. These are candid meetings in which the whole team (Product Owner, ScrumMaster, developers, and QA) participates.
Ideally, the team will hold these meetings at the end of each Sprint. Retrospective meetings provide a forum for the team to voice concerns and boast about things that went well. It is very important to balance the meeting with successes and areas for improvement. To achieve this balance you can request that every participant brings to the meeting a list of two or three practices that helped the team perform well and two or three areas where the team needs to improve.
Retrospective meetings can be hard to manage because they can easily turn into emotional discussions. To prevent this, it is very important to keep the meeting focused on how to work better as a team and not into a forum for personal attacks. I have found retrospective meetings to be of great value to let teams vent things that frustrate them and get ideas from the whole team on how to address these issues. Likewise, when things are going well, it is good for the team to talk about what makes them successful, and to make sure everybody is aware of what the team needs to maintain to keep the momentum going. These meetings also enforce the concept that everybody involved (ScrumMaster, Product Owner, developers, QA) works together as a single team, and that they need to collaborate with each other.
At a retrospective meeting, teams might discuss things such as, "We need to make sure our unit tests are kept up to date, because when we ignored them during the last Sprint, issues crept up beyond our control." or "I found it really helpful to demo the new screens to Jane early on, rather than at the end of the Sprint." or "We need better communication between developers and QA; a lot of bugs didn't get tested early on because the developers didn't flag them as ready to be tested on time."
It is important to follow up on what the team agrees to during these meetings. If the team decided it should start doing something new, such as demoing work in progress to the Product Owner sooner, the ScrumMaster needs to help the team to make sure the demos are being conducted earlier. The ScrumMaster also needs to bring this topic back to the next retrospective meeting to see if the team feels they are moving in the right direction.
After the retrospective meeting the team is ready for a new Sprint. The team gets together for a new Sprint planning meeting and then repeats the cycle. Since the code is potentially shippable at the end of every Sprint, the regression testing process is considerably simplified. Some teams have a special type of Sprint called Release Sprint in which all they do is deploy the system to the testing environment, conduct regression testing, fix any issues found during this process, and then promote to production the features completed in the Sprints since the last release.
Why Scrum Works
Scrum's practices and guidelines work because they address the most important component of software development: people and their interactions. Scrum provides a framework for the entire team (Product Owner, ScrumMaster, developers, quality assurance, and business analysts) to collaborate, and work with each other on a regular basis.
For example, the daily meeting helps the entire team (not only the ScrumMaster or the Product Owner) monitor progress on a daily basis. If the team starts falling behind, it can adapt and self-reorganize immediately. Time boxing in the Sprint helps the Product Owner monitor progress at specific intervals, because at the end of the iteration, the features planned during the planning meeting are either potentially shippable or not. The goal of potentially shippable code guides everybody in the team to work towards the same goal. The Sprint retrospective meeting allows the team to reflect on successes, talk about areas for improvement, and to take measurements to improve in the next Sprint.
A common misunderstanding is to see the Scrum process as a mini-waterfall. Just having short iterations is not enough to make Scrum work. For Scrum to shine it is vital that all team members work together on the same goal during the Sprint. If developers are coding a set of features but QA is testing a different set of features they are not working together. You are not going to have potentially shippable code at the end of this Sprint. The ScrumMaster must promote this collaboration model, especially on teams that have never worked as close together as Scrum suggests.
Scrum fosters an environment in which teams can succeed in the long term by maintaining a constant pace. Using short iterations and self-inspection every step of the process (e.g. daily meetings, Sprints, and retrospectives) allows Scrum teams to always know the status of the project and to make sure the team is moving towards the same goal. Since Sprints are short in duration and the team is always focused on having potentially shippable code at the end of the iteration, Scrum prevents the so-called "student syndrome" in which people apply themselves only at the last moment before a deadline. Figure 2 shows the stress level on teams that do not have short iterations and regular checkpoints. These teams are often relaxed at the beginning and stressed out towards the end of the project. Scrum's short iterations and regular checkpoints lead teams to a more efficient model in which team members themselves detect deviations, and make adjustments early on rather than wait until it is too late. The stress level on Scrum teams tends to be low, like the one depicted in Figure 3.
|Figure 2. Traditional Process: Here's an analysis of stress levels in traditional software processes teams.||
|Figure 3. Scrum Process: The stress level in Scrum teams is typically low.||