Agile loops from jargon to understanding (cc) F. Gobbo, S. Gentilini, F. Bertone, V. Del Bianco, please refer to: federico.gobbo@uninsubria.it Dipartimento di Informatica e Comunicazione Università degli Studi dell'Insubria

Acknowledgements This is a derivative work from the talk "XP loops" presented in XP BE 2007 by Vera Peeters (Tryx) Pascal Van Cauwenberghe (NAYIMA)

This is a derivative work from the talk "XP loops"

presented in XP BE 2007

by

Vera Peeters (Tryx)

Pascal Van Cauwenberghe (NAYIMA)

Wannabe Agile?

What Agile is not Not a panacea. Not a silver bullet. It doesn't tell you if a project is worth starting. It tells you how to start and when to stop in time. (c) artwork / graphic by Michael Whitehead for Next 16-9-2003

Not a panacea.

Not a silver bullet.

It doesn't tell you if a project is worth starting.

It tells you how to start and when to stop in time.

(c) artwork / graphic by Michael Whitehead for Next 16-9-2003

Ready to start?

Start from your (onsite) customers... Business decisions are taken by the customers Technical decisions are taken by the developer team ...and trust!

Principles and values Collaboration instead of negotiation

Collaboration instead of negotiation

User stories Customers tell: the value Developers tell: the price Don't show the kitchen, serve the dishes!

Customers tell:

the value

Developers tell:

the price

Principles and values Collaboration instead of negotiation Communication instead of requirement elicitation

Collaboration instead of negotiation

Communication instead of requirement elicitation

Small releases Steering and adapting Short-time planning release = iteration (XP) release = sprint (Scrum) Timeboxing everywhere Be realistic, don't pretend to look in a crystal ball!

Steering and adapting

Short-time planning

release = iteration (XP)

release = sprint (Scrum)

Timeboxing everywhere

Principles and values Collaboration instead of negotiation Communication instead of requirement elicitation Feedback, feedback, feedback!

Collaboration instead of negotiation

Communication instead of requirement elicitation

Feedback, feedback, feedback!

Planning game How much business value can you deliver in the next release? Pair writing Product backlog Delivering business value early and often

How much business value can you deliver in the next release?

Pair writing

Product backlog

Principles and values Collaboration instead of: negotiation Communication instead of: requirement elicitation Feedback, feedback, feedback! Business value instead of: overdesign & unused features

Collaboration instead of: negotiation

Communication instead of: requirement elicitation

Feedback, feedback, feedback!

Business value instead of: overdesign & unused features

Sustainable pace Find your natural rhythm of work (for all involved!) Think about the long run No overtime Our suggestion: the Pomodoro Technique

Find your natural rhythm of work

(for all involved!)

Think about the long run

No overtime

Principles and values Collaboration instead of negotiation Communication instead of requirement elicitation Feedback, feedback, feedback! Business value instead of overdesign & unused features Respect for people instead of pretending

Collaboration instead of negotiation

Communication instead of requirement elicitation

Feedback, feedback, feedback!

Business value instead of overdesign & unused features

Respect for people instead of pretending

Daily Standup Meetings 3 questions: What I have done? What I will complete today? I need help with... Keep it short!

3 questions:

What I have done?

What I will complete today?

I need help with...

Principles and values Collaboration instead of negotiation Communication instead of requirement elicitation Feedback, feedback, feedback! Business value instead of overdesign & unused features Respect for people instead of pretending Small, realistic chunks of work every day

Collaboration instead of negotiation

Communication instead of requirement elicitation

Feedback, feedback, feedback!

Business value instead of overdesign & unused features

Respect for people instead of pretending

Small, realistic chunks of work every day

Pair Programming Two programmers work together at one keyboard: driver types in code, observer- navigator reviews code and considers the strategic direction of the work. Not for everyone...

Two programmers work together at one keyboard: driver types in code, observer- navigator reviews code and considers the strategic direction of the work. Not for everyone...

Pair Programming and Productivity... PairProgramming reduces productivity! That would be true if the most time consuming part of programming was typing... Martin Fowler Start with a reasonably well-defined task Agree on one tiny goal at a time TDD please Rely on and support your partner Sync up frequently Be especially courteous Take a moment to celebrate Often switch roles

PairProgramming reduces productivity! That would be true if the most time consuming part of programming was typing... Martin Fowler

Start with a reasonably well-defined task

Agree on one tiny goal at a time

TDD please

Rely on and support your partner

Sync up frequently

Be especially courteous

Take a moment to celebrate

Often switch roles

Principles and values Collaboration instead of negotiation Communication instead of requirement elicitation Feedback, feedback, feedback! Business value instead of overdesign & unused features Respect for people instead of pretending Small, realistic chunks of work every day Fun and quality instead of heroism

Collaboration instead of negotiation

Communication instead of requirement elicitation

Feedback, feedback, feedback!

Business value instead of overdesign & unused features

Respect for people instead of pretending

Small, realistic chunks of work every day

Fun and quality instead of heroism

Unit Tests Automated test that validates that units of source code are working properly. Test cases written in the same language as the production code. Each test case is independent from the others.

Automated test that validates that units of source code are working properly.

So what? Safety Net Facilitates change Facilitates refactoring Simplifies integration Documentation Design Separation of interface from implementation Force code being testable ...

Safety Net

Facilitates change

Facilitates refactoring

Simplifies integration

Documentation

Design

Separation of interface from implementation

Force code being testable

...

Principles and values Collaboration instead of negotiation Communication instead of requirement elicitation Feedback, feedback, feedback! Business value instead of overdesign & unused features Respect for people instead of pretending Small, realistic chunks of work every day Fun and quality instead of heroism Quality work every time

Collaboration instead of negotiation

Communication instead of requirement elicitation

Feedback, feedback, feedback!

Business value instead of overdesign & unused features

Respect for people instead of pretending

Small, realistic chunks of work every day

Fun and quality instead of heroism

Quality work every time

Test Driven Development without inmagine.com with forbes.com

without inmagine.com

with forbes.com

Test Driven Development write a test implement code to pass the test refactor testdriven.com forbes.com

write a test implement code to pass the test refactor

testdriven.com

forbes.com

Principles and values Collaboration instead of negotiation Communication instead of requirement elicitation Feedback, feedback, feedback! Business value instead of overdesign & unused features Respect for people instead of pretending Small, realistic chunks of work every day Fun and quality instead of heroism Quality work every time Technical excellence

Collaboration instead of negotiation

Communication instead of requirement elicitation

Feedback, feedback, feedback!

Business value instead of overdesign & unused features

Respect for people instead of pretending

Small, realistic chunks of work every day

Fun and quality instead of heroism

Quality work every time

Technical excellence

Refactoring without with

without

with

Refactoring clean code that works! get rid of smelling code: duplication large classes large methods long parameters list etc etc..

clean code that works! get rid of smelling code: duplication large classes large methods long parameters list etc etc..

Principles and values Collaboration instead of negotiation Communication instead of requirement elicitation Feedback, feedback, feedback! Business value instead of overdesign & unused features Respect for people instead of pretending Small, realistic chunks of work every day Fun and quality instead of heroism Quality work every time Technical excellence Simplicity

Collaboration instead of negotiation

Communication instead of requirement elicitation

Feedback, feedback, feedback!

Business value instead of overdesign & unused features

Respect for people instead of pretending

Small, realistic chunks of work every day

Fun and quality instead of heroism

Quality work every time

Technical excellence

Simplicity

Continuous Integration Small steps Small changes Small problems Integrate frequently (multiple integrations per day). Each integration is verified by an automated build.

Small steps

Small changes

Small problems

Not so easy... Once you are there, great benefits: Control Visibility Early warnings Availability of a "current" build

Once you are there, great benefits:

Control

Visibility

Early warnings

Availability of a "current" build

Principles and values Collaboration instead of negotiation Communication instead of requirement elicitation Feedback, feedback, feedback! Business value instead of overdesign & unused features Respect for people instead of pretending Small, realistic chunks of work every day Fun and quality instead of heroism Quality work every time Technical excellence Simplicity Be in control

Collaboration instead of negotiation

Communication instead of requirement elicitation

Feedback, feedback, feedback!

Business value instead of overdesign & unused features

Respect for people instead of pretending

Small, realistic chunks of work every day

Fun and quality instead of heroism

Quality work every time

Technical excellence

Simplicity

Be in control

Collective Code Ownership Everyone can contribute to everything Any developer can change any line of code Everyone is responsible for all the code No one person becomes a bottle neck for changes

Everyone can contribute to everything Any developer can change any line of code Everyone is responsible for all the code No one person becomes a bottle neck for changes

Prerequisites and Alternatives Prerequisites, at least: CodingStandards Version management Unit tests Alternatives? CodeStewardship ... So what? Define who ones the code! More "collective", is better, but has more prerequisites

Prerequisites, at least: CodingStandards Version management Unit tests

Alternatives? CodeStewardship ... So what? Define who ones the code! More "collective", is better, but has more prerequisites

Principles and values Collaboration instead of negotiation Communication instead of requirement elicitation Feedback, feedback, feedback! Business value instead of overdesign & unused features Respect for people instead of pretending Small, realistic chunks of work every day Fun and quality instead of heroism Quality work every time Technical excellence Simplicity Be in control Trust your teammates

Collaboration instead of negotiation

Communication instead of requirement elicitation

Feedback, feedback, feedback!

Business value instead of overdesign & unused features

Respect for people instead of pretending

Small, realistic chunks of work every day

Fun and quality instead of heroism

Quality work every time

Technical excellence

Simplicity

Be in control

Trust your teammates

Acceptance Tests Customers specifies scenarios to test when a user story has been correctly implemented A story can have one or many acceptance tests Acceptance tests are black box system tests Customers sign completed stories when their acceptance tests pass

Customers specifies scenarios to test when a user story has been correctly implemented A story can have one or many acceptance tests Acceptance tests are black box system tests

Acceptance Tests HowTo Written at the start of each iteration Start a story executing acceptance tests Write unit tests Keep adding unit tests and production code until all the acceptance tests pass

Written at the start of each iteration

Start a story executing acceptance tests

Write unit tests

Keep adding unit tests and production code until all the acceptance tests pass

Principles and values Collaboration instead of negotiation Communication instead of requirement elicitation Feedback, feedback, feedback! Business value instead of overdesign & unused features Respect for people instead of pretending Small, realistic chunks of work every day Fun and quality instead of heroism Quality work every time Technical excellence Simplicity Be in control Trust your teammates Working software is measure of progress

Collaboration instead of negotiation

Communication instead of requirement elicitation

Feedback, feedback, feedback!

Business value instead of overdesign & unused features

Respect for people instead of pretending

Small, realistic chunks of work every day

Fun and quality instead of heroism

Quality work every time

Technical excellence

Simplicity

Be in control

Trust your teammates

Working software is measure of progress

Velocity Velocity is the rate at which you complete your work, in a certain period of time. In project management terms: velocity is the amount of work that a team can complete in a specified period of time.

Velocity is the rate at which you complete your work, in a certain period of time. In project management terms: velocity is the amount of work that a team can complete in a specified period of time.

Velocity and Burndown Velocity to make commitments in future iterations If a team does not know its velocity, how will that team be able to know how much work to put into an iteration? Burndown to meet commitments in one iteration If a team doesn't focus burndown, it is probable that the team will miss the scope of the iteration

Velocity to make commitments in future iterations If a team does not know its velocity, how will that team be able to know how much work to put into an iteration?

Burndown to meet commitments in one iteration If a team doesn't focus burndown, it is probable that the team will miss the scope of the iteration

Open Workspace Self-organizing teams Collaboration Comunication Trust Simplicity Self-organization Feedback!!

Principles and values Collaboration instead of negotiation Communication instead of requirement elicitation Feedback, feedback, feedback! Business value instead of overdesign & unused features Respect for people instead of pretending Small, realistic chunks of work every day Fun and quality instead of heroism Quality work every time Technical excellence Simplicity Be in control Trust your teammates Working software is measure of progress

Collaboration instead of negotiation

Communication instead of requirement elicitation

Feedback, feedback, feedback!

Business value instead of overdesign & unused features

Respect for people instead of pretending

Small, realistic chunks of work every day

Fun and quality instead of heroism

Quality work every time

Technical excellence

Simplicity

Be in control

Trust your teammates

Working software is measure of progress

μεταφορά : "a transfer", in rhetoric "transference of a word to a new sense", from μεταφέρω - metaphero , "to carry over, to transfer" Metaphor Shared Vision Ubiquitous Language Communication Simplicity

Principles and values Collaboration instead of negotiation Communication instead of requirement elicitation Feedback, feedback, feedback! Business value instead of overdesign & unused features Respect for people instead of pretending Small, realistic chunks of work every day Fun and quality instead of heroism Quality work every time Technical excellence Simplicity Be in control Trust your teammates Working software is measure of progress Shared understanding

Collaboration instead of negotiation

Communication instead of requirement elicitation

Feedback, feedback, feedback!

Business value instead of overdesign & unused features

Respect for people instead of pretending

Small, realistic chunks of work every day

Fun and quality instead of heroism

Quality work every time

Technical excellence

Simplicity

Be in control

Trust your teammates

Working software is measure of progress

Shared understanding

Retrospectives

Principles and values Collaboration instead of negotiation Communication instead of requirement elicitation Feedback, feedback, feedback! Business value instead of overdesign & unused features Respect for people instead of pretending Small, realistic chunks of work every day Fun and quality instead of heroism Quality work every time Technical excellence Simplicity Be in control Trust your teammates Working software is measure of progress Shared understanding Continuous improvement

Collaboration instead of negotiation

Communication instead of requirement elicitation

Feedback, feedback, feedback!

Business value instead of overdesign & unused features

Respect for people instead of pretending

Small, realistic chunks of work every day

Fun and quality instead of heroism

Quality work every time

Technical excellence

Simplicity

Be in control

Trust your teammates

Working software is measure of progress

Shared understanding

Continuous improvement

Agilemanifesto.org (re-read it!) Individuals and interactions Working software Customer collaboration Responding to change Naturally non-fondamentalist: many methodologies, many technologies. over processes and tools over comprehensive documentation over contract negotiation over following a plan based on the community!

Individuals and interactions

Working software

Customer collaboration

Responding to change

Naturally non-fondamentalist: many methodologies, many technologies.

Thanks for your attention! Questions? The answers during this week!