Agile Development

November 3rd, 2011

Justin F. Brunelle

Purpose

• Introduction to Agile methodologies

– Who what where when why

• Introduction to SCRUM

– Implementation of Agile in Sprints

Surprise!

• Most programmers already implement agile

engineering!

– Rapid Prototyping

– Cyclic development cycles

– Stakeholder feedback

– Ever-growing queue of requirements

Waterfall

• Traditional Development

• Incremental

• Linear

• What happens if

you fail at

Verification?

http://en.wikipedia.org/wiki/File:Waterfall_model_%281%29.svg

Daily Trivia

• First presentation on Waterfall Model?

• MITRE!

– Development of SAGE (Semi-Automated Ground

Environment)

• Messages to bomber aircraft

– 1950s

Goal of Agile Development

• Continuous delivery of working software

– Iterative

– User feedback driven

• Iterations produce releasable product

• Goal is not speed!

Agile Approach

• Adaptive, empirical process

– Small repeating cycles

– Short-term planning with constant feedback, inspection and adaptation

• Fail-early lifecycle

– Iterative development

brings most of the risk

and difficult work

forward to the early

part of a project

Agile Manifesto • 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.

User Role in Agile

9

Release

Plan

Design

Code Test

Assess

Plan

Design

Code Test

Assess

Plan

Design

Code Test

Assess

Plan

Design

Code Test

Assess

Plan

Design

Code Test

Assess The User is involved in all

aspects of the iteration –

this helps ensure true user

driven development

Shippable

Product

What is “Done”?

• At the end of every iteration, the only work

that is declared “Done” is work that has gone

through the proper engineering activities and

could be used by Clients

– Requirements

– Code

– Testing (unit, integration, user)

– Stakeholder feedback

SCRUM

• Type of Agile

• Self-organizing teams

• Product Backlog

• Sprints

• Releases/Retrospective

• Rinse and repeat

SCRUM

User

Feedback Incorporated Into Product Backlog

Storyboarding

Who SCRUMS?

• Defined roles

– Product Owner

– Scrum Master

– Scrum Team

• No “Bus Person”

Product Owner

• Define the features of the product

• Decide on release date and content

• Be responsible for the success of the product

• Prioritize features according to market value

• Adjust features and priority every iteration, as

needed

• Accept or reject work results

The ScrumMaster

• Represents management to the project

• Responsible for enacting Scrum values and practices

• Removes impediments

• Ensure that the team is fully functional and productive

• Enable close cooperation across all roles and functions

• Shield the team from external interferences

The Team

• Typically 5-9 people

• Cross-functional:

– Programmers, testers, user experience designers, etc.

• Everyone knows a little about a lot

• Teams are self-organizing

– Ideally, no titles but rarely a possibility

Storyboarding

• Creation of user stories

– Populates the backlog

– Multiple backlog entries per story

• Methods

– Whiteboard

– Photoshop

– Layout “Straw-men”

– Verbal Process

Backlog

• The requirements expressed as user stories – [COUGH – CRC Cards – COUGH]

• A list of all desired work

• Prioritized by the product owner

• Reprioritized at the start of each sprint

• “I want the product to do X”

SCRUM Sprints

• Scrum projects make progress in a series of

“sprints”

• 2–4 weeks

• “Byte”-sized chunk of the project is

designed, coded, and tested during the sprint

– Normally:

• Subset of backlog

• 2-3 stories

Sprint Review Process

• Review Process:

– Demo Software

• Entire team (remember the “Bus Person”)

– Get Feedback

– Update Backlog

• Reprioritize

• Entries not taken out until next sprint

Sprint Retrospective

• Retrospective (15-30 min. mtg):

– What went well?

– What went wrong?

– What will we do different?

“SCRUMmary”

• Incremental

• Iterative

• Fail early

• User involvement

Will it work for You?

• Shouldn’t be a “Big Bang”

– Phased implementation

• Identify Roles

• Create backlog

• Determine sprint length

• RUN!