Upload
vineet
View
4.957
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Vineet's presentation on "Introduction to Agile" at the at the Intro to Agile workshop on 28th June 2008
Citation preview
Introduction to AgileIntroduction to Agile
2
Who am I?Who am I?
Software Practitioner & Evangelist 13 years of building software and learning
Certified Scrum Master
Lead Impetus Labs, Consulting and Research I am available for
Speaking on Technology & Agile
Help & Support your Agile journey
(m) 931 310 2111
3
AgendaAgenda
Introduction to Agile Lets begin by having fun..
History of evolution
What is Agile?
What Agile is NOT
Common myths and misconceptions
4
Lets Have Some Fun …Lets Have Some Fun …
Need a few volunteers
Clearing the Obstacle Course – Strategy 1 Our volunteers will be working in a team 1 Manager and other workers Worker cannot do anything on his own, he has to
verbatim follow the instructions of the Manager Goal of the team is to clear the obstacle course Please observe them as they go through different
the obstacle course Productivity (Individual & Overall) Happiness Ability to react to impediments
5
Lets Have Some Fun …Lets Have Some Fun …
Clearing the Obstacle Course – Strategy 2
Our volunteers will be own their own
Goal of the volunteers is to clear the obstacle course
Please observe them as they go through the obstacle course
Productivity (Individual & Overall)
Happiness
Ability to react to impediments
6
EvolutionEvolution
Agile is evolutionary not revolutionary
The context of developing software is changing
Technology driven business innovation
Dynamic Market conditions
Time to Market
Requirement Stability
What does it mean for software development?
You cant win a 20-20 game with a test match strategy
7
Some facts …Some facts …
1995 : The CHAOS Report ** Type 1 : Project Success
On time on budget, all features are delivered (16.2%)
Type 2 : Project Challenged Completed and operational but over budget, fewer features
than specified (52.7%)
Type 3 : Project Impaired Cancelled at some stage (31.1%)
**Tom Clancy 1995 | The Standish Group International
8
Some facts …Some facts …
Traditional Processes were not helping
Customers unhappy
Requirement Changes are dealt through risk avoidance strategy i.e resist requirement change
Eliminating change means business failure
So ? These led to evolutions in the way we approach software
development
9
Introducing AgileIntroducing Agile
The BRAVE new way of developing software
Don’t avoid risk, take it as unavoidable and accept it
Requirement Changes are dealt through risk acceptance strategy
10
Agile ManifestoAgile 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
“That is, while there is value in the items on the right, we value the items on the left more.”
11
Waterfall ManifestoWaterfall Manifesto
12
Waterfall ManifestoWaterfall Manifesto
13
Principles Behind Agile ManifestoPrinciples Behind 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
14
Principles Behind Agile ManifestoPrinciples Behind Agile Manifesto
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
15
Principles Behind Agile ManifestoPrinciples Behind Agile Manifesto
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.
16
So, What is Agile?So, What is Agile?
Simply Stating … It a way of developing software that follows the Agile Principles
There are a number of agile software development methods; most attempt to
minimize risk by developing software in short timeboxes, called iterations, which typically last one to four weeks
Each iteration is like a miniature software project of its own, and includes all of the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation
17
So, What is Agile?So, What is Agile?
18
Myths & MisconceptionsMyths & Misconceptions
Agile methods are sometimes characterized as being at the opposite end of the spectrum from "plan-driven" or "disciplined" methodologies This distinction is misleading, as it implies that agile methods are
"unplanned" or "undisciplined“ A more accurate distinction is to say that methods exist on a
continuum from "adaptive" to "predictive” Adaptive methods focus on adapting quickly to changing realities
When the needs of a project change, an adaptive team changes as well
An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method will be about what will happen on that date
An adaptive team can report exactly what tasks are being done next week, but only which features are planned for next month. When asked about a release six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost.
19
Myths & MisconceptionsMyths & Misconceptions
Predictive methods, in contrast, focus on planning the future in detail
A predictive team can report exactly what features and tasks are planned for the entire length of the development process
Predictive teams have difficulty changing direction
The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently
Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered
20
Myths & MisconceptionsMyths & Misconceptions
Agile methods v/s CMM/CMMi CMM/CMMi is NOT a method or a process
model
It is a reference process benchmark
CMM/CMMi don’t prescribe what process (for developing software that is) to use
Agile Software Development process can be benchmarked on CMM/CMMi models
Initial, Managed, Defined, Quantitively Managed & Optimizing
21
Myths & MisconceptionsMyths & Misconceptions
Agile __________ Is a silver bullet Will solve my resource issues Has no planning/ documentation/architecture/
<insert pet peeve> Is a license to hack Creates quality issues Is undisciplined Doesn’t build on my previous experience /
expertise Is not proven Is not being used by industry leaders
Thank YouThank You
Questions?