1. Project Retrospectives Mary Lynn Manns manns@unca.edu http://www.cs.unca.edu/~manns

2. Project Retrospective “… the single most important step toward improving the software process!” Kerth,2001

3. Why is it so important? When things go well … … we need to share these things with others When things don’t go well … … we need to talk about and solve the problems rather than hiding them or assigning blame

4. What is a retrospective? A ritual for reviewing projects

5. Why a retrospective?… To look at the past People stop and learn from their experiences  document the successful practices  avoid same mistakes over and over  share different views  see the big picture  allow your process to adapt to advances in field

6. Why a retrospective?… To plan the future People are involved in improvements  understand the need for improvement  design improvements  own the improvements  get motivated to improve

7. Why a retrospective?… To build community People will understand … … what others are doing?.. what they are struggling with … what their talents and limitations are? ……..

8. Why a retrospective?… To reach closure People find that it is … Cathartic Informative Enlightening Fun etc…

9. What a retrospective isn’t  Not a complaint session …everyone did the best job he or she could…  Not a place for finding fault  An end  Not the same every time

10. What happens before …  Interview participants  Distribute retrospective handout  Request effort data  Request artifacts

11. What happens In the beginning  Create safety  Write ground rules  Define success  Define insanity  Do the “I’m too busy” exercise

12. What happens To look at the past  Artifacts Contest  The Big Picture  Time Line  Emotions Seismograph  Passive Analogy  Offer Appreciation  Repair Damage Through Play

13. What happens To look to the future  Change the Papers  Messages  A Plan for the Future  Posters  One Last Topic  Closing

14. What to do with the information  Retrospective reports –What worked well that we don’t want to forget? –What should we do differently? –What still puzzles us? –Recommendations to management –Lessons learned  Patterns

15. Patterns  To capture lessons learned, successful practices  1970’s: C. Alexander, architecture  1995: Design Patterns: Elements of Reusable Object-Oriented Software  Patterns for design, testing, management, training, introducing innovation, etc…  http://hillside.net/patterns/ http://hillside.net/patterns/  http://www.cs.unca.edu/~manns http://www.cs.unca.edu/~manns

16. Pattern  Problem  Forces  Solution  Context  Rationale  Consequences  Known Uses  Name

17. Pattern Language A collection of related patterns that work together to solve complex problems

18. Project Retrospective Looking back in order to move forward