Agile Engineering Practices Hangzhou Scrum Forum 2009 May 2009

Agenda Ground rules Purpose and expected outcomes About the presenter Agile – concepts and methodologies Agile and Engineering Practices Scrum XP FDD

Ground rules

Purpose and expected outcomes

About the presenter

Agile – concepts and methodologies

Agile and Engineering Practices

Scrum

XP

FDD

Ground Rules Mute your cell phone Participate – ask and answer questions Do Don’t

Mute your cell phone

Participate – ask and answer questions

Purpose and Outcomes Purpose: Review key Agile principles Discuss Agile Software Engineering Practices Outcomes: Gain an understanding of key Agile Software Engineering Practices Recognize there are multiple sources from which to learn and implement Agile Engineering Practices Develop a basic understanding of Feature Driven Development as an Agile alternative to XP practices (which are often challenging to implement)

Purpose:

Review key Agile principles

Discuss Agile Software Engineering Practices

Outcomes:

Gain an understanding of key Agile Software Engineering Practices

Recognize there are multiple sources from which to learn and implement Agile Engineering Practices

Develop a basic understanding of Feature Driven Development as an Agile alternative to XP practices (which are often challenging to implement)

About Me Vernon Stinebaker ( 史文林） http://www.linkedin.com/in/vernonstinebaker Director of Technology/Principal Architect 20+ years software development and process experience CMMI, SDLC/waterfall, and agile methodologies Certified ScrumMaster/Certified Scrum Practitioner 9+ years experience with Feature Driven Development Founding member of the open source FDDTools project

Vernon Stinebaker ( 史文林）

http://www.linkedin.com/in/vernonstinebaker

Director of Technology/Principal Architect

20+ years software development and process experience

CMMI, SDLC/waterfall, and agile methodologies

Certified ScrumMaster/Certified Scrum Practitioner

9+ years experience with Feature Driven Development

Founding member of the open source FDDTools project

Agile Manifesto

Agile Manifesto Principles Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently , from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity -- the art of maximizing the amount of work not done -- is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently , from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity -- the art of maximizing the amount of work not done -- is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

First things first… The most important contributor to the success of projects is… People!

The most important contributor to the success of projects is…

People!

Scrum eXtreme Programming (XP) FDD DSDM Crystal Perficient’s Enable-M … But they share the same objectives -- those described in the Agile Manifesto No “one” Agile

Scrum

eXtreme Programming (XP)

FDD

DSDM

Crystal

Perficient’s Enable-M

…

But they share the same objectives -- those described in the Agile Manifesto

Today’s Focus XP FDD

XP

FDD

First let’s talk about Scrum

Scrum

Scrum 3 Roles Product Owner ScrumMaster Team 3 Ceremonies Sprint Planning Daily Stand-up Sprint Demo 3 Artifacts Product Backlog Sprint Backlog Burn-down Charts

3 Roles

Product Owner

ScrumMaster

Team

3 Ceremonies

Sprint Planning

Daily Stand-up

Sprint Demo

3 Artifacts

Product Backlog

Sprint Backlog

Burn-down Charts

Scrum in one slide Mountain Goat Software, LLC Product Owner Team ScrumMaster

Scrum is… Simple, but not easy!

Simple, but not easy!

Characteristics Self-organizing teams Product progresses in a series of month-long “sprints” Requirements are captured as items in a list of “product backlog” No specific engineering practices prescribed Uses generative rules to create an agile environment for delivering projects One of the “agile processes” Mountain Goat Software, LLC

Self-organizing teams

Product progresses in a series of month-long “sprints”

Requirements are captured as items in a list of “product backlog”

No specific engineering practices prescribed

Uses generative rules to create an agile environment for delivering projects

One of the “agile processes”

OMG! No specific engineering practices prescribed!

OMG! No specific engineering practices prescribed!

Sequential vs. overlapping development Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986. Rather than doing all of one thing at a time... ...Scrum teams do a little of everything all the time Requirements Design Code Test Mountain Goat Software, LLC

So… We still have to do Requirements gathering Design Coding Testing But how?

We still have to do

Requirements gathering

Design

Coding

Testing

But how?

I like XP!

I like XP!

XP Practices eXtreme Programming describes engineering practices On-site Customer Metaphor 40 Hour Week Planning Game Refactoring Simple Design Pair Programming Testing Short Releases Coding Standards Collective Ownership Continuous Integration

eXtreme Programming describes engineering practices

On-site Customer

Metaphor

40 Hour Week

Planning Game

Refactoring

Simple Design

Pair Programming

Testing

Short Releases

Coding Standards

Collective Ownership

Continuous Integration

Which practices have you implemented? On-site Customer Metaphor 40 Hour Week Planning Game Refactoring Simple Design Pair Programming Testing Short Releases Coding Standards Collective Ownership Continuous Integration

On-site Customer

Metaphor

40 Hour Week

Planning Game

Refactoring

Simple Design

Pair Programming

Testing

Short Releases

Coding Standards

Collective Ownership

Continuous Integration

What does the project process look like? Is this simple? (Easy or not?) What happened to those practices?

Is this simple? (Easy or not?)

What happened to those practices?

Scrum doesn’t prescribe engineering practices. XP is great! But are their alternatives?

Scrum doesn’t prescribe engineering practices.

XP is great! But are their alternatives?

Feature Driven Development

Feature Driven Development

FDD in a slide Simple? YES!!! But not easy 

Simple?

YES!!!

But not easy 

The whole process in one slide ETVX. Really simple. Not one book. One slide. (Well, OK. 10 pages actually.) FDD Process copyright Nebulon 2009

ETVX. Really simple. Not one book. One slide.

(Well, OK. 10 pages actually.)

Develop an Overall Model What’s this? Modeling? Yes. Agile modeling!

What’s this? Modeling?

Yes. Agile modeling!

Build a Feature List User valued, user verifiable functionality <action><result><object> Calculate the total value of a sale. Display the result of a translation.

User valued, user verifiable functionality

<action><result><object>

Calculate the total value of a sale.

Display the result of a translation.

Plan by Feature Features must take less than two weeks Can be much less Features are collected into Work Packages Which are released within two weeks Resources are the only challenge to scalability Used successfully on projects with team size of 500+ An unlimited number of Work Packages may be under simultaneous development

Features must take less than two weeks

Can be much less

Features are collected into Work Packages

Which are released within two weeks

Resources are the only challenge to scalability

Used successfully on projects with team size of 500+

An unlimited number of Work Packages may be under simultaneous development

Design by Feature More Design? Conversations happen! Inspection – bench testing (TDD?) Communication is the second key to successful projects People are the first!

More Design?

Conversations happen!

Inspection – bench testing (TDD?)

Communication is the second key to successful projects

People are the first!

Build by Feature Class ownership Code inspection Unit Testing Promote to Build

Class ownership

Code inspection

Unit Testing

Promote to Build

What? Traditional Software Engineering Activities? Design Inspections Testing Builds Can you implement these?

Design

Inspections

Testing

Builds

Can you implement these?

What? Traditional roles? Customer SMEs Project Manager Architect Chief Programmer Developers Testers Easier for some organizations to accept

Customer

SMEs

Project Manager

Architect

Chief Programmer

Developers

Testers

Easier for some organizations to accept

FDD is… Evolutionary, not revolutionary Builds on software engineering best practices Makes sense to ‘traditional’ engineers and managers Agile! Simple. But not easy. Can be used to complement Scrum by providing familiar and implementable engineering practices

Evolutionary, not revolutionary

Builds on software engineering best practices

Makes sense to ‘traditional’ engineers and managers

Agile!

Simple. But not easy.

Can be used to complement Scrum by providing familiar and implementable engineering practices

Summary Scrum doesn’t prescribe engineering practices so we go looking elsewhere XP provides engineering practices But they’re eXtreme. FDD provides engineering practices Simple Evolutionary, not revolutionary Can augment Scrum with proven, best practice practices (And can also be used on independently of Scrum)

Scrum doesn’t prescribe engineering practices

so we go looking elsewhere

XP provides engineering practices

But they’re eXtreme.

FDD provides engineering practices

Simple

Evolutionary, not revolutionary

Can augment Scrum with proven, best practice practices (And can also be used on independently of Scrum)

Q&A Thank you!

Thank you!