Agile Intro: History, Principles & Methods

Agile Methodology
An Introduction to the Concepts of the Agile Methodology

Copyright
This material is primarily for the use of Orange and
Bronze Software Labs, Inc.

No part of this material may be reproduced or
transmitted in any form or by any means, electronic or
mechanical, including photocopying, recording, or by any
information storage and retrieval system, without
permission in writing from the publisher.

www.orangeandbronze.com

Overview
• What is the Agile Methodology?
→ History
→ Principles

→ Characteristics

• Agile Method: SCRUM
• Agile Method: XP


History
• Evolved in the mid 90s as part of a reaction against
“heavyweight ” methods
→ e.g. heavily regulated, regimented, micro-managed use
of the Waterfall Method
• Sought to move away from the Waterfall Method
which was seen as bureaucratic, slow, demeaning, and
inconsistent with the ways that developers perform
effective work
• Initially called lightweight methods


History
• Earlier Methods
→ Scrum (1986)
→ Crystal Clear and Other Crystal Methodologies

→ Extreme Programming (XP) (1996)

→ Adaptive Software Development (ASD)

→ Feature Driven Development

→ Dynamic Systems Development Method (DSDM) (1995)

→ Agile Modeling

→ Lean Software Development

→ Agile Unified Process (AUP)

The Agile Manifesto
We are uncovering better ways of developing software
by doing it and helping others do it. Through this work
we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan


Agile Principles (The Agile Manifesto)
• Customer satisfaction by rapid, continuous delivery of
useful software
• Working software is delivered frequently (weeks rather
than months)
• Working software is the principal measure of progress
• Close, daily cooperation between business people and
developers
• Face-to-face conversation is the best form of
communication


Agile Principles (The Agile Manifesto)
• Projects are built around motivated individuals, who
should be trusted to get the job done
• Continuous attention to technical excellence and good
design
• Simplicity
• Self-organizing teams
• Regular adaptation to changing circumstances


Agile Characteristics
• More adaptive than predictive
• Focuses on the near future rather than the distant
future
• Focuses on adapting quickly to changing realities rather
than planning for the entire length of the development
process
• Has a lot in common with Rapid Application
Development


• Time periods are strict time boxes and are measured in
weeks rather than months
• Highly collaborative work
• Emphasizes real time communication
• Emphasis on building releasable software in short time
periods
• Customer is on site and part of the development team


• Phases
→ Inception
→ Elaboration

→ Construction

→ Transition


• Inception Phase
→ Smallest phase in the project
→ Ideally short

→ Goals:

• Establish a justification or business case for the project
• Establish the project scope and boundary conditions
• Outline the Use Cases and key requirements that will
drive design tradeoffs
• Outline one or more architectures
• Identify risks


• Inception Phase
→ Goals:
• Prepare a preliminary project schedule and cost estimate
• Establish a baseline by which to compare actual and
planned expenditures
→ Deliverables:
• Objectives and Scope of the Project
• High Level Use Cases
• Candidate Architectures
• Project Schedule and Cost Estimates


• Elaboration Phase
→ Project starts to take shape
→ Healthy majority of the system requirements is

captured
→ Analysis of the problem domain


→ Primary Goals:
• Address known risk factors
• Establish and validate system architecture
• Delve deeper into the requirements previously gathered


→ Deliverables:
• Detailed Use Cases
• Conceptual Diagrams
– Ex. Process Flow Diagrams, Activity Diagrams, etc.
• Package Diagrams
– Architectural Diagrams
• Stable System Architecture
• Plan for Construction Phase
– Including cost and schedule estimates


• Construction Phase
→ Largest phase
→ Where the bulk of the coding takes place

→ Use cases are translated to demonstrable prototypes

→ System is built under the foundation laid in Elaboration


• Construction Phase
→ Main Focus: Development of components and features
• Implemented in a series of short, timeboxed iterations
• Each iteration yields an executable release of software
→ Deliverables:
• First external release of the software
• Succeeding releases of the software as per iteration


• Transition Phase
→ Product moves from development team to end users
→ Feedback received may lead to further refinements

→ Refinements may be incorporated in several iterations


• Transition Phase
→ Activities:
• System conversion
• Training of end users and maintenance team
• Validation of system against end user expectation via
beta testing
• Quality level validation
→ Deliverables:
• Final release of the system


• Principles on Code Production
→ Keep it simple
→ Have one shared metaphor

→ Regularly restructure the system ( Refactoring)

→ Continuously integrate and test

→ Follow coding standards


• Agile Best Practices
→ Daily kickoff and review of goals
→ Short release cycles

→ Responsive development

→ Generalism

• Use of generic skill sets that are common across the
team, instead of reliance on specific skill sets that are
scarce


• Advantages
→ Customer decides scope, priority, and dates from a
business perspective, while technical people estimate
and track progress
→ Incremental development

→ Emphasis on responsibility for quality


• Advantages
→ Emphasis on keeping it simple, regular refactoring, and
continuous integration and testing
→ Lightweight, efficient, low-risk, flexible, scientific, and

fun way of developing software


• Criticism / Disadvantages
→ Puts strong dependence on trust
→ Code-centered rather than design-centered

→ Lack of orderly design process and structured reviews

may lead to extensive and time consuming tests


• Criticism / Disadvantages
→ Lack of structure and necessary documentation
→ Only works with senior-level developers

→ Reliance on verbal communication

→ Requires too much cultural change to adopt


Suitability with Types of Projects
• AGILE Homeground
→ Low criticality
→ Senior developers

→ Requirements change frequently

→ Culture that thrives on “chaos” or changing realities


Suitability with Types of Projects
• PLAN-DRIVEN Homeground
→ High criticality
→ Junior developers

→ Requirements don't change too often

→ Large number of developers

→ Culture that demands order


Agile Methods
• Scrum
• Extreme Programming (XP)
• Agile Modeling
• Agile Unified Process (AUP)
• Agile Data Method
• Test Driven Development (TDD)
• Feature Driven Development (FDD)
• Behavior Driven Development (BDD)
• Essential Unified Process (EssUP)

SCRUM
• Originally a rugby term which is short for “scrummage”


SCRUM
• Characteristics
→ An iterative incremental process commonly used with
the Agile Methodology
→ Can be used:

• For managing software development projects
• As a program management approach (Scrum of Scrums)
→ Works hand in hand with the PSA Time and Material
Model


SCRUM
• Characteristics
→ A process skeleton that includes a set of practices and
predefined roles
→ Employs “Sprints” - a time period, usually 15 – 30 days,

in which development occurs on a set backlog items
that the team has committed to


SCRUM Roles
• Pig Roles – The ones committed to the project and the
Scrum process (Scrum Team)
• Chicken Roles – The ones not part of the actual Scrum
process but are only involved


Pig Roles
• Product Owner
→ The voice of the customer
→ Responsible for maintaining the Product

Backlog
• Scrum Master (or Facilitator)
→ Responsible for the Scrum process
→ Ensures that Scrum is used correctly and its

benefits are maximized


Pig Roles
• Team
→ A cross-functional group of people
→ Responsible for managing itself to develop

the product


Chicken Roles
• Users
→ Who the software is built for
• Stakeholders
→ People who have interest in the project
→ People within or outside an organization

that may influence the project's objectives
and outcomes
• Managers
→ The people who will set up the environment
for development

SCRUM Documents
• Product Backlog
→ The WHAT that will be built
→ High level document for the entire project

→ Prioritized list of high level requirements

→ Contains broad descriptions of all required features,

wish list items, etc.
→ Contains rough estimates


SCRUM Documents


SCRUM Documents
• Sprint Backlog
→ Tells HOW requirements are to be implemented in the
upcoming Sprint
→ Greatly detailed document enumerating tasks to be

completed during the Sprint
→ Broken down list of tasks, with each task being no more

than 16 hours
→ Tasks are never assigned, but signed-up for by team

members


SCRUM Documents
• Burn Down Chart
→ Publicly displayed chart
→ Shows the amount of remaining tasks for the current

Sprint
→ Updated daily

→ Gives a simple view of the daily progress of the team

during a Sprint


SCRUM General Practices
• Customers are part of the development team
• Frequent intermediate deliveries with working
functionality
• Frequent risk and mitigation plans
• Transparency in planning and module development


SCRUM General Practices
• Frequent stakeholder meetings to monitor progress
• No one is penalized for recognizing or describing any
unforeseen problems
• Workplaces and working hours must be energized


SCRUM Process


Extreme Programming (XP)

“Extreme Programming is a discipline of software
development based on values of simplicity,
communication, feedback, and courage. It works by
bringing the whole team together in the presence of
simple practices, with enough feedback to enable the
team to see where they are and to tune the practices to
their unique situation.”
– Ron Jeffries (2001)


• Founded by Ron Jeffries, Kent Beck & Ward Cunningham
• A deliberate and disciplined approach to software
development
• Stresses customer satisfaction
→ It is designed to deliver the software needed by the
customer and when it is needed


• Empowers developers to confidently respond to
changing customer requirements, even late in the life
cycle
• Emphasizes teamwork
→ Managers, customers and developers are all part of a
team dedicated to delivering quality software
• Involves changing the way we program, putting greater
emphasis on producing simple, high quality code



Ron Jeffries
Ron Jeffries Kent Beck
Kent Beck Ward Cunningham
Ward Cunningham


XP Values
• Communication
→ Accomplished through documentation
→ Goal is to give developers a shared view of the system

which matches the views held by the users
• Simplicity
→ Start with the simplest solution, extras can be added
later
→ Focus on today, not tomorrow

→ Simple design with simple code can be easily

understood

XP Values
• Feedback
→ From the system through unit tests
→ From the customer through functional / acceptance

tests
→ From the team through changes in the requirements

• Courage
→ Enables developers to feel comfortable in refactoring
their own code
→ Knowing when to throw obsolete code away

→ Persistence


XP Values
• Respect
→ Respect for each
member's work
→ Nobody on the team

should feel
unappreciated or
ignored


Requirements


Capturing Requirements: User Stories
• Each story is a short description of the behavior of the
system, from the viewpoint of the user
• The system is specified entirely through stories


Capturing Requirements: User Stories


Iterative Development
• What is an iteration?
→ A complete development cycle
• Planning, Designing, Implementation, Testing
→ Customer selects features to implement at the start of
the iteration
→ By the end of an iteration, the system should have

acquired additional business behavior that implements
business value to the customer


Velocity
• The number of IPDs (Ideal Programming Days)
completed per iteration
• Used to determine the amount the work that can be
accomplished by the team or an individual in an
iteration
• The pace of the team or individual


Software Release Cycle
• Software is built incrementally by iteration
• Each iteration lasts from 1 – 3 weeks
• Customer defines the release
→ Customer decides what to release at the end of one or
more iterations


Customer Defines Release
• In each release cycle, the customer controls the scope:
→ What to do, what to defer
→ Provide the best possible release by due date

• Towards or at the end of each iteration, the customer
decides whether enough functionality has been added
to warrant a release


Common Problem: Too Much to Do
• Not Enough Time
→ No solution: Can't create time
• Too Much to Do
→ Have solutions:
• Prioritize and defer some things
• Reduce the size of the things you need to do
• Ask someone else to do things


Planning the Budget
• The Items: Stories
• The Cost: Estimates
• The Budget: Team Velocity
• The Constraints: Business and technology constraints
discovered


Planning the Release
• Customer: Write enough stories to define a successful
product or system
• Development Team: Estimate effort of implementing
each story
• Customer: Prioritize stories based on business value
and difficulty
• Development Team: Divide stories into iterations based
on team velocity (in previous iterations)


XP Development Cycle


XP Basic Activities
• Coding
• Testing
• Listening
• Designing


XP Core Practices


XP Core Practices
• Fine Scale Feedback
→ Pair Programming
→ Planning Game

→ Test Driven Development

→ Whole Team

• Continuous Process
→ Continuous Integration
→ Small Releases

→ Refactoring or Design Improvement


XP Core Practices
• Shared Understanding
→ Coding Standards
→ Collective Code Ownership

→ Simple Design

→ System Metaphor

• Programmer Welfare
→ Sustainable Pace


XP Core Practices
→ Pair Programming
• Ensures all production code is reviewed by at least one
programmer
• Results in better design, better testing, and better code
• A good way to pass knowledge


XP Core Practices
→ Planning Game
• Addresses two key questions:
– What should/will be accomplished by the due date?
– What to do next?
• Emphasis on steering the project
• Release Planning
– Desired features are determined and estimates are done
• Iteration Planning
– Features are broken down into tasks
– Costs are estimated in a finer level of detail


XP Core Practices
→ Test Driven Development
• Aims to improve the system; always notching forward,
never backsliding
• It's not enough to write tests, you have to run them
• 100% or bust
• Provides immediate feedback


XP Core Practices
→ Whole Team
• Everyone on an XP team contributes in any way they can
• The best teams have no specialists, only general
contributors with special skill (Jeffries, 2001)


XP Core Practices
→ Continuous Integration
• It is encouraged to integrate multiple times a day
• Infrequent integration usually leads to “integration hell”


XP Core Practices
→ Small Releases
• The team releases running, tested software, delivering
business value chosen by the customer, every iteration
(Jeffries, 2001)
• Ultimate goal is to have software that is visible, which is
given to the customer at the end of each iteration


XP Core Practices
→ Refactoring or Design Improvement
• Focuses on:
– Removal of duplicate / obsolete code
– Increasing cohesion
– Decreasing coupling

“High cohesion and low coupling are recognized as
hallmarks of well-designed code for at least thirty years.”
-- Ron Jeffries

XP Core Practices
• Share Understanding
→ Coding Standards
• All the code looks as if it were written by a single – very
competent – individual (Jeffries, 2001)
• All the code looks familiar to the developers


XP Core Practices
• Share Understanding
→ Collective Code Ownership
• Code gets the benefit of many people's attention,
increasing code quality and reducing defects (Jeffries,
2001)


XP Core Practices
• Shared Understanding
→ Simple Design
• Start simple, maintain through programmer testing and
design improvement / refactoring
→ System Metaphor
• A simple evocative description of how the program
works (Jeffries, 2001)
• Provides a common vision for the team
• A way to get everyone on the same page


XP Core Practices
• Example of a Metaphor:
“ This program works like a
hive of bees, going out for
pollen and bringing it back
to the hive.”
→ Description for an agent-
(Roberts, 2006) based information retrieval
(Roberts, 2006)
system
(Jeffries, 2001)


XP Core Practices
• Programmer Welfare
→ Sustainable Pace
• XP teams work at a pace that can be sustained
indefinitely
• Maximize productivity week in and week out
• XP teams are “in it to win it, not to die” (Jeffries, 2001)


Strong Opinions Against XP
• Unstable Requirements
→ Informal change requests may lead to costly rework and
scope creep
• User Conflicts
→ Dependence on programmers being able to assume a
unified client viewpoint


• Requirements are expressed as automated acceptance
tests rather than specification documents
• Requirements are defined incrementally, rather than
trying to get them all in advance
• Developers are required to work in pairs


• No “Big Design Up Front ”
→ Most design activities take place on the fly
• A customer representative is attached to the project
• Scalability
→ Historically, XP only works in teams of twelve or fewer
people


Benefits of XP
• Allows one to be more Agile
• Focus on programming
• Enables quicker delivery of quality software than
traditional methods
• Enables more flexibility than traditional methods


References
• Beck, K., Beedle, M., Bennekum, A., Cockburn, A.,
Cunningham, W., Fowler, M., et al. (2001) Manifesto for
Agile Software Development. Retrieved from
http://agilemanifesto.org
• Clark, T., Vizdos, M. (2006) The Classic Story of the Pig
and Chicken. Retrieved from
http://implementingscrum.com
• Jeffries, R. (2001) What is Extreme Programming?
Retrieved from
http://www.xprogramming.com/xpmag/whatisxp.htm

References
• Landingin, R. (2008) Agile Methodology Workshop
[Powerpoint Slides].
• Patel, N. (2006) Agile Methods [Powerpoint Slides].
Retrieved from
http://greenbay.usc.edu/csci577/spring2006/site/presentat
• Roberts, H. (Artist). (2006) Bees swarming around a
beehive [Digital Image]. Retrieved July 31, 2008 from
http://bluebison.net/sketchbook/2006/0906/bees.png
•


Agile Intro: History, Principles & Methods

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Agile Intro: History, Principles & Methods

Similar a Agile Intro: History, Principles & Methods (20)

Último

Último (20)

Agile Intro: History, Principles & Methods