1158 Project Retrospectives Miroslav Novak Systems Engineer Borland.

1158Project Retrospectives

Miroslav NovakSystems Engineer

Borland

Introduction

What’s the context?

Agile Software Development

Values (among other things):• responding to change over following a

plan, • individuals and interactions over

processes and tools

eXtreme Programming

Values (among other things):• communication, • feedback

Lean Development

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

Adopting Agility

Willing to Learn

Pursuing Quality

Examining the Past

Adjusting for Future

Questions?

Please make a note to yourself to

ask them later.

Retrospectives

Say what?

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

A Practice

A practice that relies on and fosters

continued learning, and

improvementis some form of retrospective.

Why the ceremony?

Stopping to reflect is not natural.

Formalism and ceremony make it more likely.

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.

What are some of its outcomes?

Understanding

Increase and spread the knowledge

Mended relations

Acknowledge and appreciate contributions.

Quantify the effort.

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.

Question:

A show of hands, please –

Who has had one of these outcomes from a retrospective?

Question:

A show of hands, please –

How many recall a retrospective that actually had an effect on their next project.?

Questions?

Please make a note to ask them

later.

Retrospective Climate

Where do you do this?

What kind of climate does it occur in?

A safe one

A timely one

A committed one

A facilitated one

A safe climate?

First and foremost:

Not threatening to those who have something to contribute.

A timely climate?

The end of a project:– Rebuilding– Recuperating– Reconnecting

But, need feedback before next project.

A committed climate?

A community

A binding contract

Motivation to learn and adapt

Or, the effort is wasted.

A facilitated climate?

Neutral

External

No vested interest

Questions?

Please make a note to ask them

later.

An Experience

What have you done?

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.

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.

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.

Customer Retrospective 1

Execution:• Safety Exercise• Artifacts Contest• Develop a Time Line Exercise• Mining the Timeline Exercise• Lessons Learned Exercise

Customer Retrospective 1

OutCom:• Management Awareness• Concrete Action Plans• Tangible Milestones

Leveraging Borland ALM

What can you see now?

ALM Components

Valuable, relevant, and accessibleinformation for our retrospectives:• CaliberRM• Together• Optimizeit; • ServerTrace;• Datamart;• Borland Search Server;

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

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

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.

Metrics of Requirements Management

• Trend of post-launch defects over time• Trend of number of change requests for rework

Metrics of Project Status

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

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

Metrics of Design and Development           

Active code/design review process that

leverages Audit and Metrics functionality

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.

Quick Example

What can you get now?

Take Action

What can you do now?

Where do we start?

Where is your project right now?

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

References

Cockburn, Adaptive Software Development

Kerth, Project Retrospectives: A Handbook for Team Reviews

Questions?

Thank You

1158

Project Retrospectives

Please fill out the speaker evaluation

You can contact me further at …[email protected]