project retrospectives mary lynn manns [email protected] manns
TRANSCRIPT
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 happensbefore …
Interview participants
Distribute retrospective handout
Request effort data
Request artifacts
What happensIn the beginning
Create safety
Write ground rules
Define success
Define insanity
Do the “I’m too busy” exercise
What happensTo look at the past
Artifacts Contest The Big Picture Time Line Emotions Seismograph Passive Analogy Offer Appreciation Repair Damage Through Play
What happensTo 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… http://hillside.net/patterns/ http://www.cs.unca.edu/~manns
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