Retrospectives Explained by Esther Derby, co-author of Agile Retrospectives: Making Good Teams Great. ***Video here: https://youtu.be/G8T-TUo_9V4 Effective retrospectives stoke the engine of team improvement. They’re the critical feedback loop for the team to examine methods, engineering practices, teamwork, and organizational relationships.  But too often, teams fall into a rut, or fail to act on their retrospective resolves. Esther will share a five part framework for retrospectives, how the parts fit together, and what happens when you omit one of the stages. If you have been dissatisfied with your team’s retrospectives, or you are ready to take your retrospectives beyond “what did we do well, what could we do better,” watch this slide show and learn from one of the world’s experts on retrospectives. ------------------- About Esther Derby 

I consult with you to help you develop a holistic view of your organization and take action to achieve optimum success. I coach you to boost your effectiveness and confidence as a manager, and I deliver workshops that bring insights to life, build skills, and engage your people in learning. 

If you have questions about my services, contact me to schedule a free initial conversation. I'd be delighted to share my thoughts with you and learn about your company. 

 Phone:  +1 612.239.1214 
 Email: esther@estherderby.com 

 Visit my website to learn more about what I do, browse my blog and sign up for my free email newsletter.

2. Agile Retrospectives are special meetings that take place at the end of a period of work--usually an iteration or software release.

3. In a retrospective, a team steps back, examines the way they work, analyzes, and identifies ways they can improve.

4. Agile Retrospectives stoke the engine of team improvement.

5. But too many retrospectives fail to deliver meaningful (or any) results.

6. Too often, retrospectives are boring, painful, a waste of time.

8. It doesn’t have to be that way.

15. Some people worry these steps will take too long.

16. But leaving out a step undermines the purpose and effectiveness of the retrospective.

18. Some (ineffective) retrospectives start in the middle, by asking the group to list what they did well, and what they should do differently.

19. “ What did we do well?” is a questions that asks about insights, in the absence of data.

20. “ What should we do differently?” is a questions that asks for a conclusion with neither data nor analysis.

21. So don’t skip a step, and don’t short change the retro. 1/2 hour is not enough time to get beneath the surface of most problems.

22. Every retrospective should be unique.

23. Choose a focus that reflects what’s going on for the team.

24. Identify what data will help the team sort through that issue.

25. Select activities that will enable all members of the team to participate, and think, learn, and decide together.

26. If you always use the same focus and activities, you’ll end up in a rut. Switch it up.

27. Retrospectives can’t fix everything.

28. Retrospectives aren’t the place for individual performance feedback.

29. Retrospectives aren’t the answer for inadequate technical or collaboration skills.

30. Retrospectives may not correct faulty mental models of software development or of how organizations work.

31. Some issues require feedback, coaching, training.

32. Retrospectives do help teams think, learn, and decide together.

33. Retrospectives make time for teams consider ways to re-design their work and team culture.

34. Retrospectives help teams improve. Over time, they help good teams become great teams. Over time, they help good teams become great teams.

36. You can read more about my thoughts on management, leadership, teams, and organizations at www.estherderby.com . You can also sign up for my newsletter there. @estherderby on Twitter @estherderby on Twitter @estherderby on Twitter @estherderby on Twitter @estherderby on Twitter