Agile Retrospectives

Lancez-Vous. C'est gratuit
ou s'inscrire avec votre adresse e-mail
Agile Retrospectives par Mind Map: Agile Retrospectives

1. To be successful

1.1. The need for the ritual

1.1.1. Address positive & negative aspects

1.1.2. Form a ritual: stop and reflect

1.2. Naming the process

1.2.1. Pick the right name (e.g. "retrospective")

1.3. Prime directive for a retrospective

1.3.1. People need to feel safe

1.3.1.1. No "management" present, only team members

1.3.1.2. The team decides what will be made public

1.3.1.2.1. Optionally publish a list of actionable items

1.3.1.3. Everybody should know (learn) how to provide and receive feedback

1.3.1.4. Encourage but don't force participation

1.3.1.5. Decide on the location for a retrospective based on the team's "energy"

1.3.1.6. Discuss personal needs and wants

1.3.1.7. Talk about how you can improve, not how others can improve

1.3.2. Assume everybody's best intentions

1.4. The darker side of the Retrospectives

1.4.1. "Complaint" sessions

1.4.1.1. Arise from unfullfilled needs

1.4.1.2. Defensive or attacking responses

1.4.1.3. Leads to retrospectives being cancelled

1.4.2. Rephrase accusations as "wishes"

1.5. Retrospective Facilitator

1.5.1. Should have a clear idea about the goals of the meeting

1.5.2. Select the right exercises for the situation at hand

1.5.3. Practice a lot

1.5.4. Learn from more experienced facilitators

1.5.5. Don't force people to speak

1.5.5.1. Make sure everyone is able to speak and get heard

1.5.6. Clarify the insights people offer until everyone understand what is meant

1.5.7. Challenge the insight, ask questions, look for different perspectives

1.5.8. Allow for hard topics to be discussed, but keep focusing on positivity

1.5.9. Don't make decisions but generate ideas and let the team decide

1.5.10. Don't take sides in discussions

1.5.11. Develop yourself (using professional help)

1.5.12. Help the team summarise and write down action points; make sure they're followed up during the sprint

2. Why?

2.1. Team building

2.1.1. Bring back harmony

2.1.2. Improve the work

2.1.2.1. Reflect

2.1.2.2. Prevent future mistakes

2.1.2.3. Continuous improvement

2.1.3. Empowerment

2.1.3.1. Own decisions

2.1.3.2. Change way of working

2.1.4. Deal with new and leaving team members

2.1.5. Praise

2.1.6. Make a connection between developers and managers

2.2. Reflection

2.2.1. How to be more effective

2.2.2. Inspect and adapt cycle

3. The schedule

3.1. Set the stage

3.1.1. Provide a direction

3.1.2. Provide a timeframe

3.1.3. For everyone to communicate readily, ask everyone: what do you hope to get from this?

3.1.4. Establish or re-establish team values; define what is acceptable behavior during the retrospective

3.2. Gather data

3.2.1. Collect important interactions and events during the sprint

3.2.2. Collect metrics about the project and the work done

3.2.3. Use visual aids

3.2.4. As a group, look for patterns or changes

3.3. Generate ideas

3.3.1. Analyse the data together

3.3.2. Encourage "big picture" thinking

3.3.3. Establish an understanding of cause and effect

3.3.4. Don't jump to conclusions

3.4. Decide what to do

3.4.1. Settle on just 1-2 solutions

3.4.2. Use story cards or backlog items to record experiments and actions for the upcoming sprint

3.4.3. Every individual should understand what is asked from them personally with regard to the proposed solutions

3.5. Closing

3.5.1. It should be clear what is expected

3.5.2. It should be clear what will be documented, and where

3.5.3. Create memorable things: a poster, a picture, etc.

3.5.4. Reflect on the retrospective itself: what can be improved next time?