Agile Retrospective

What is an Agile Retrospective?

The Agile Manifesto states that a team reflects on how to become more effective. Agile retrospectives are evaluating a way for teams in order to examine their working methods and adapt. Two meetings are typically organized at the end of an iteration:

? “Sprint review” (or demo), aimed at obtaining feedback on the outcome of the sprint and discuss what the next step will be:
? “The retrospective” focused on the team, and the processes used in the delivery of the software.

The purpose of these retrospectives is to help continuously improve their way of working teams (continuous improvement) to improve working methods (continuous improvement). An agile retrospective, or as Scrum calls it a "sprint retrospective," is a way for teams to evaluate their way of working and constantly get better at what they do.

The 12th principle of the Agile states that teams reflect at regular intervals on how they can become more effective, and aligned therewith change their method. All members of a team are taking part in the retrospective meeting. During this meeting, they "examine" them how the iteration has expired and they determine what improved and "changed" to be in their attitude and way of working.

Retrospectives are therefore an effective way in order to achieve short-cycle improvements. The facilitators of the retrospective (often the Scrum Master and Project Manager) has several retrospective exercises and should be able in every situation to choose the most effective method and use.

A retrospective meeting usually starts with retrace the status of all actions from the previous retrospective to verify that they are implemented. If they are not implemented and is this still necessary, there will be taken action to do so.

Actions defined from a retrospective must be implemented in the next iteration.
To make sure the team carries out the actions of a retrospective, they add to the backlog, in the form of user stories. These are included in the planning game and scrum board placed on the planning so that they are visible and remain for the team.

Why do we do Retrospectives?

Organizations must constantly improve themselves in order to remain competitive in the market and deliver lasting value. The classic organizational large long-term change programs is often inefficient and ineffective. We want better ways to improve discovery and retrospectives are above the solution. It testifies not reality to do what you always did and still expect different results. If you want to bring more value to your customers, then you have to change the way you work.

In which distinguish a Retrospective itself from traditional traditional improvement programs?

Teams can achieve significant benefits from retrospectives. Teams own agile retrospectives, and can therefore focus on those improvements that they consider necessary. They solve problems that interfere with their process. Agile retrospectives give teams control over their own performance and thats how it should be! If teams are adequately supported, then there is more responsibility and they know they are supported to carry out the tasks. And this leads to less resistance to change.

Changes are necessary as a result of the actions arising from retrospectives. Another advantage is that the team decides which actions it picks out a retrospective and that the team also performs those actions. There is no question of transfer. The team determines its own tasks. The team analyzes what is happening, the tasks and the team determines perform these tasks. The team involves the product owner, the project manager of the underlying project, and users with the improvements when it deems necessary.

The team remains a leader in the formulation and implementation of the tasks in this way if your team improve route determination is much more effective, faster and cheaper than if transfer is of tasks between the team and other people in the organization.

Retrospectives can be used to form teams and in order to strengthen them. You can use different types of retrospective exercises to explore in a team issues in collaboration and communication. Coaching and mentoring helps team members to see where things go wrong and how they can improve themselves. Retrospectives offer this valuable input.

Retrospective Designs
As a facilitator of retrospectives, it is important to have a small toolbox of exercises that you can use when designing a retrospective. Which helps you to facilitate retrospectives that deliver more for the teams you work with.
Why several retrospective exercises?

Each team is different, and also to deal with the issues that teams will vary at each iteration. Therefore, there is no retrospective exercise guaranteed to always give the best results. Therefore go ahead with a retrospective-example that always starts well en is best suited. In addition, there is a risk that teams get bored if they perform more and retrospectives in the same way. A solution to this is to introduce variation by the use of different exercises.

Choosing retrospective exercises
The purpose of selecting a retrospective exercises is to achieve a design of a Retrospective meeting that produces business value. That value is created when teams identify during a retrospective issues they find it important to work and thereby improve their process. Incidentally, a process often 'the way we work here. But what is most important? That may be the largest, most current limit where a team is facing.

It may also be important to find out what the reason is that the last iteration has gone wrong, or just become a great success. Plus, you can also examine what strengths can bet the team to improve further through a strength-oriented Retrospective.

Structure of a retrospective
The book Agile Retrospectives by Esther Derby and Diana Larsen describes well the activities that a retrospective is built:
1. Determine Playfield
2. Collect Data
3. Creating Insights
4. Define Actions
5. Exit

Retrospective Exercises:
? Asking Questions is a simple but powerful exercise. There are many different questions that you can ask. The trick is to pick out those questions to see further help the team to understand their most pressing problems and potential of possible improvements. Asking follow-up questions thereby helps to go deeper into issues in the retrospective.
? Starfish exercise is a variation on the "What went well?" "What did not go well?" “What could be improved". This assumes a five equally divided circle that indicates which activities the team must stop immediately, what activities it should retain, what it should persist, which should be given a greater role and that it should start.
? Sailboat exercise is aimed to remind the team to the target, the product that has to deliver, the risks that might occur, what their slow and, above all, which helps to deliver good software. The exercise uses a metaphor of a boat, rocks, clouds and islands.
? If there are problems in a team that should be discussed over a one-word Retrospective appropriate exercise than a one-word Retrospective appropriate workout. It begins by asking each team member to name one word that reflects their feelings about the last iteration. These words are used to discuss issues that might otherwise never would be discussed.
? Team members can describe the performance of the team by the name of the car brand they associate with the iteration in the so-called “Car-brand exercise”. This exercise allows everyone to share his or her opinion about the iteration and to come up with improvements.
? The feelings of team members are often affected by problems they encounter in their mutual cooperation. Team members can request it in a retrospective with the "Happiness Index" which helps them to make improvements to fixed. This practice makes use of a graphical representation of the feelings of the team members.
? "If there are major problems which would prevent the team in the future, the five-times-why exercise can be used. It uses cause-effect analysis to identify the root causes of problems and tackle.
? The Constellations exercise is used to clarify or team members agree on key issues. This exercise is very suitable as an opening for a retrospective, because it allows team members to express themselves freely on any subject.
? A Team Evaluation exercise can do introspection teams in different areas, such as the performance of the product owner, controlling activities during each iteration, the team spirit, and implementation of good practices.
? A strengths-based Retrospective reveal where the power of teams and team members located. The exercise is considered lies teams and team members. The exercise uses a solution-oriented approach. This approach helps in finding ways to use the strengths of the team in solving problems.
? A High Performance Tree is a metaphor used to help teams make their vision and the direction they want to go visible. Simultaneously, the exercise makes visible what is needed to realize that vision.
? If a team is mature enough, Value Stream Analysis can be used to help them recognize their own pitfalls. The exercise shows how the team makes the product. He makes clear dependencies and shows if there is waste in the development process.
? When multiple teams working within an Agile project, you can use a "Retrospective of Retrospectives" to improve cooperation between the teams. That is an effective way for teams to learn from and with each other and to tackle together issues that the project is facing.

Literature to read and learn much more about above recapitulation:
-LyssaAdkins. Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition. Addison Wesley, 2010.
-Rachel Davies and Liz Sedley. Agile Coaching. The Pragmatic programmers, LLC, 2009.
-Luis Goncalves and Ben Linders, a Toolbox of Retrospectives.
-Esther Derby and Diana Larsen. Agile Retrospectives: Making Good Teams Great. The Pragmatic Programmers, LLC. 2006.
-Jutta Eckstein. Agile Software Development with Distributed Teams. Dorset House, 2010.
-Henrik Kniberg. Scrum and XP from the Trenches. InfoQ, 2007.
-Patrick Kua. The Retrospective Handbook: A guide for agile teams. leanpub, 2013.
-Dean Lef?ingwell. Scaling Software Agility: üest Practices for Large enterprises. Midison-Wesley, 2007.
-Mary Poppendieck and Tom Poppendieck. Lean Software DevelopPoppendieck and Tom Poppendieck. Lean Software Development: An Agile Toolkit. Addison-WesYey, 20O3.
-Mike Rother. Toyota Kata. McGraw-Hill, 2009.
-Jean Takaba. Collaboration Explained: Facilitation Skills for Software Project Leaders, Addison-Wesley, 2006