Get Ready for Agile Methods: How to manage constant and rapid change in IT projects

Get Ready for
Agile Methods!
How to manage constant and
rapid change in IT projects

Dr Dimitris Dranidis

Presentation outline
Traditional methodologies
Problems
Agile methods
Extreme Programming
SCRUM
Conclusions

Get Ready for Agile Methods * D Dranidis * CITY College 2

Driving forces…
“Deliver quickly.
Change quickly.
Change often.
These three driving forces compel us to
rethink traditional software engineering
practices.”

-- Jim Highsmith

Classic
“Waterfall” development model


Characteristics of the
Waterfall development model
Heavy documentation
Every phase delivers a
complete document
Late product delivery
Big-bang approach
No code is written before the Coding phase
Late feedback – low customer involvement
Customer is involved at the beginning and at the
end of the project.


The problems
Business environment changes at
increasing pace.
Unpredictability of requirements
Traditional methodologies fail to satisfy
environment changes due to:
Resistance to change
Change increases cost
Conformance to an initial plan

Cost of change
Late discovery of
design defects
Changing
requirements
Result:
costly over-runs
and, often,
project
cancellation.

Waterfall tries to avoid change by freezing requirements
(contracts)

Risk
In a waterfall process, you don’t know if you
have a problem until late in the lifecycle.

Risk is very high
until you see some
results


Customer feedback was late!


Following plans when feedback is
absent
With feedback

Without feedback


How can we deal with…?
Continuous change?
Change is inevitable!

Unpredictable requirements?

High risks?


Agile methods
Agile = flexible, adaptable

Embrace change!
Try to reduce cost of change

Focus on
customer satisfaction (and feedback)
rather than conformance to a plan
Early product delivery


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


Common characteristic of all agile methods:

Iterative process
Development is broken
down in short iterations
Every iteration
repeats a “small Waterfall”
Delivers some functionality
Incremental approach
Iterations are time-boxed:
No extensions of deadlines

There is a product even if
the project is cancelled


SCRUM
Software development process for small teams
(max 9) and small projects (few months)

Very simple, only very few principles and rules
Emphasis on agile project management practices

Toyota uses it since the early 1990s


SCRUM process overview
Iterative
Incremental
Time-boxed


Initial planning phase
Establish vision,
budget
Initial Product
Backlog
List of identified,
prioritized features
Prepared by the
customer


Sprints - iterations
15-30 day iterations

Sprint planning

Sprint
Daily Scrum meetings

Sprint review


Sprint planning
Spring backlog
List of features to be
implemented in the
current Sprint
The most important
features from the
Product Backlog
Expanded to list of
tasks by team


SCRUM - Sprints
The team is left alone and produces the best
software possible

No changes are allowed during a sprint
Anything can change before and after

Daily SCRUM meetings


Daily SCRUM meetings
15 – 30 minutes stand-up
meetings
at the same place at the same
time every work day
Questions to be answered by
each team member:
What have you done since the last scrum meeting?
What obstacles stand in the way?
What do you plan on doing between now and the next scrum
meeting?

Management’s role:
remove any obstacles and to supply all necessary resources.

Sprint review
At the end of a sprint:
Meeting with all stakeholders
Product demonstration
Anything can be changed
Continue?


SCRUM closure phase
Completes product
development
Operational deployment
Documentation


SCRUM Roles:
Product owner (Customer)
Responsible for creating and
prioritizing the Product Backlog

Chooses goals for the next
Sprint

Reviews the system after the
Sprint


SCRUM Roles:
Scrum Team (developers)
Expand the Sprint Backlog to
Tasks

Work on the Sprint Backlog
tasks

Develop the system

Daily meetings


SCRUM Roles:
Scrum Master (Project Manager)
Ensures Scrum practices
are followed

Mediator between
management and team

Removes obstacles

Conducts Sprint review


SCRUM Logs:
Product Backlog
Kept by the Product
owner (Customer)
List of identified,
prioritized tasks
Drives team activity
Updated and prioritized
before each sprint
Checked in each meeting


SCRUM Logs:
Product Backlog


SCRUM Logs:
Sprint Backlog
List of tasks to be
completed by the Scrum
Team in the current
Sprint.

Tasks in the range of 4-
16 hours
Estimates are updated
daily!
Total estimated time
calculated


SCRUM Logs:
Sprint Burn-down graph
Remaining Actual Ideal
estimated
time to
complete
all tasks


SCRUM Practices:
Project management ..
Self-directed teams
No guidance from management or Scrum Master
Don’t add to iteration
Nothing changes during a sprint
Scrum Master firewall
Team is not interrupted by anyone
Scrum Master removes obstacles
Decision in one hour
Decisions for removing blocks are taken immediately
Bad decisions are better than no decisions
Blocks removed in one day

SCRUM Practices:
Project management ..
Chickens and Pigs
In a SCRUM meeting only the SCRUM Team may talk (the
pigs)
Everybody else (the chickens) can attend silently


Other SCRUM practices
Small teams
Ideally 7 members
Larger projects can be multiple teams
Common room
Daily Build


SCRUM…. the name?
A scrum is a team
pack in Rugby
Everybody in the pack
acts together with
everyone else to
move the ball down
the field


Four Variables ...
Control variables of software development
Cost
Available budget
Time
Project duration
Quality
Product quality
Scope
Product features


Four Variables ...
It is impossible to control all four
variables

Customers can choose to control
any 3 of the variables
Developers pick the resultant value
of the 4th variable


Four Variables ...
All variables should be visible to customer

Scope is the best variable to control
Fix cost, time and quality
Adjust scope correspondingly
If there is no time to complete the whole
project remove some functionality
(customer chooses)


XP Practices
XP is based on the
extreme application of
12 practices that
support each other.


12 XP Practices


XP Practices:
Planning Game .....
Pieces: user stories

Requirements on index cards

Written by the customer


XP Practices:
Planning Game .....
Players: customer & developer
Customer
decides priorities
(Business value)
Developer
estimates effort

Value and Risk first!


XP Practices:
Planning Game .....
Iteration planning (before each iteration)
Time-boxed: 2-3 weeks long
Customer selects “user stories” fitting current
iteration
Developers break user stories in tasks


XP Practices:
Planning Game .....
Inside the iteration
No new “user stories” are added

Completeness is measured in terms of
completed “user stories”


XP Practices:
Planning Game …..
End of iteration
Iteration ends at the pre-specified date
Even if not all user stories were
implemented

Estimations are evaluated and readjusted for
next iterations


XP Practices:
Frequent Releases
A release cycle is usually up to
3 months

A release cycle consists of
iterations up to 3 weeks

In each iteration the selected
user stories are implemented

Each user story is split in
programming tasks of 1-3 days

small and frequent releases
provide frequent feedback from
the customer


XP Practices:
Pair programming ..
Two programmers sit
together in front of a
workstation
one enters code
one reviews the code and
thinks
“Pair programming is a dialog
between two people trying to
simultaneously program and
understand how to program
better”, Kent Beck
Continuous quality
inspection!

XP Practices:
Pair programming ..
Pairs change continuously (few times in a day)
every programmer knows all the aspects of the
system
a programmer can be easily replaced in the middle of
the project
Ensures continuous code inspection

Costs 10-15% more than stand-alone
programming but….
Code is simpler (fewer LOC) with less defects (15%)


XP Practices:
On-site customer
The customer must always be available to
answer questions
resolve ambiguities
set priorities
review the product

Customer is considered part of the team
Continuous feedback!


Requirements for the success of
agile methods
Collaborative environment
People-centered organizations
Small to medium sized teams
(avg. 9 persons)
Common open workplace
Commitment
Customer commitment
Management commitment
Developers commitment


Wrap-up
Agile methodologies in a fast changing
world!
Embrace change!
The people factor
Trust your team!
User involvement
Involve the customer!
Useful practices even in a traditional
development process

Thank you!

“It is not the strongest of the
species that survives, nor
the most intelligent that
survives. It is the one that is
the most adaptable to
change.”
Charles Darwin


About me…
Senior Lecturer
Computer Science Dept
CITY College, International Faculty of the University of Sheffield

Programme director of the
MSc in Software Engineering & Telecommunications

Leader of the "Software Engineering & Service-Oriented
Technologies" research group, research interests:
service-oriented computing, model-based testing, object-oriented
analysis and design, formal methods, software engineering education,
agile software development methodologies, and artificial intelligence.

http://www.city.academic.gr/csd/dranidis/


Experience in software project
management
>10 years of management of >50 short (6-9
pms) software projects
Industrial Group Projects
Teams of undergraduate and postgraduate
students developing software for the industry
Plenty of successes and failures

http://invent.city.academic.gr/


Get Ready for Agile Methods: How to manage constant and rapid change in IT projects

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (11)

Semelhante a Get Ready for Agile Methods: How to manage constant and rapid change in IT projects

Semelhante a Get Ready for Agile Methods: How to manage constant and rapid change in IT projects (20)

Último

Último (20)

Get Ready for Agile Methods: How to manage constant and rapid change in IT projects