Project Retrospectives Mary Lynn Manns

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

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

What is a retrospective? A ritual for reviewing projects

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

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

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

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

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

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

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

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

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

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

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…  

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

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

Project Retrospective Looking back in order to move forward