1. 1158 Project Retrospectives Miroslav Novak Systems Engineer Borland

2. Introduction What’s the context?

3. Agile Software Development Values (among other things): responding to change over following a plan, individuals and interactions over processes and tools

4. eXtreme Programming Values (among other things): communication, feedback

5. Lean Development Values (among other things): incorporating feedback, a culture of continuous improvement.

6. Adopting Agility Willing to Learn Pursuing Quality Examining the Past Adjusting for Future

7. Questions? Please make a note to yourself to ask them later.

8. Retrospectives Say what?

9. What is a retrospective? A retrospective is a formalized way of stopping to reflect on a project at the end of a project. It includes everyone associated with the project, as a community. - Kerth, 2001

10. A Practice A practice that relies on and fosters continued learning, and improvement is some form of retrospective.

11. Why the ceremony? Stopping to reflect is not natural. Formalism and ceremony make it more likely.

12. What is its purpose? It serves to allow the team to reflect on the project in a way that allows the team to look at and learn from mistakes, as well as identify and quantify successes.

13. What are some of its outcomes? Understanding Increase and spread the knowledge Mended relations Acknowledge and appreciate contributions. Quantify the effort.

14. What are some of its outcomes? A set of lists is generated: –What to change, –what was learned, –what worked, and –what needs further discussion.

15. Question: A show of hands, please – Who has had one of these outcomes from a retrospective?

16. Question: A show of hands, please – How many recall a retrospective that actually had an effect on their next project.?

17. Questions? Please make a note to ask them later.

18. Retrospective Climate Where do you do this?

19. What kind of climate does it occur in? A safe one A timely one A committed one A facilitated one

20. A safe climate? First and foremost: Not threatening to those who have something to contribute.

21. A timely climate? The end of a project: –Rebuilding –Recuperating –Reconnecting But, need feedback before next project.

22. A committed climate? A community A binding contract Motivation to learn and adapt Or, the effort is wasted.

23. A facilitated climate? Neutral External No vested interest

24. Questions? Please make a note to ask them later.

25. An Experience What have you done?

26. Customer Retrospective 1 Situation: Project 1: Finished Requirements elicitation and management. To be handed off externally. Project 2: New project to adopt CaliberRM. Same team for both projects.

27. Customer Retrospective 1 Mission: Learn from Project 1 experience with respect to requirements elicitation, management, within CaliberRM and how to adapt from this for Project 2.

28. Customer Retrospective 1 Mission: Learn from Project 1 experience with respect to requirements elicitation, management, within CaliberRM and how to adapt from this for Project 2.

29. Customer Retrospective 1 Execution: Safety Exercise Artifacts Contest Develop a Time Line Exercise Mining the Timeline Exercise Lessons Learned Exercise

30. Customer Retrospective 1 OutCom: Management Awareness Concrete Action Plans Tangible Milestones

31. Leveraging Borland ALM What can you see now?

32. ALM Components Valuable, relevant, and accessible information for our retrospectives: CaliberRM Together Optimizeit; ServerTrace; Datamart; Borland Search Server;

33. Metrics of Changes in Requirements Measure the amount of requirements change on a project Excessive change at the wrong point in the software lifecycle requires investigating The team will identify improvements

34. Metrics of Changes in Requirements Frequency of change to the requirements Rate of introduction of new requirements Number of changes to a requirements baseline Percentage of defects with requirement errors as the root cause Number of requirements-related change requests

35. Metrics of Requirements Management The benefits of active and evolving requirements management approach can also be examined. Changes implemented as of result of previous retrospectives, for example, may supported by metrics.

36. Metrics of Requirements Management Trend of post-launch defects over time Trend of number of change requests for rework

37. Metrics of Project Status For retrospectives after an increment, use various metrics to gain insight into the state of a project.

38. Metrics of Project Status Number of requirements by status/total number of requirements Functional requirements allocated to a project release or iteration Requirements growth over time Number of requirements completed Number of requirements traced or not traced

39. Metrics of Design and Development Active code/design review process that leverages Audit and Metrics functionality

40. Metrics of Design and Development Number of audit tests/number of violations. Trend in number of violations. Distribution of audit violation severity. Lines of code/ successful acceptance tests. Lines of code/ number of classes or methods. Changes in design metrics per package or class Changes in metrics associated with certain refactorings.

41. Quick Example What can you get now?

42. Take Action What can you do now?

43. Where do we start? Where is your project right now?

44. Places to start Right now! Start of a project Middle of the first increment After each increment In the middle of subsequent increment End of the project

45. References Cockburn, Adaptive Software Development Kerth, Project Retrospectives: A Handbook for Team Reviews

46. Questions?

47. Thank You 1158 Project Retrospectives Please fill out the speaker evaluation You can contact me further at … mnovak@borland.com