2. Agenda
Overview of Agile
Overview of SCRUM
Traditional vs. Agile Software
Development
A Typical Road Map (and how to avoid
the pot-holes and speed-breakers)
4. History of Agile
Mid-90s
◦ Lightweight software development methods
evolved as a reaction against Heavyweight
(waterfall) methods
◦ Birth of SCRUM, XP, Crystal Clear, DSDM,
FDD and Adaptive Software Development
2001
◦ The Manifesto for Agile Software
Development
◦ Principles behind the Agile Manifesto
◦ Agile Alliance
5. Agile Definition
Agile is about delivering the highest
business value possible faster by focusing
on people and continuous improvement
(iteration).
6. Agile Characteristics
• Empirical (relies on observation and
experience)
• Lightweight
• Adaptive
• Fast – but never hurried
• Exposes wastefulness
• Customer-centric
• Pushes decision making to lower levels
• Fosters trust, honesty and courage
• Encourages self-organization
7. Agile Manifesto
Individuals and interactions over Process and tools
Comprehensive
Working software over
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.
Source:
www.agilemanifesto.org
10. Cost of Change in Waterfall
Approach
Courtesy: Declan Whelan
11. Cost of Change in Agile Approach
Courtesy: Declan Whelan
12. Comparison between Various
Methodologies
Waterfall Incremental Agile
Analysis
Design Time
Implementation
Test
Scope
13. Benefits- examples
16% increase in productivity
37% faster Time-to-Market
84% said defects down by >25%
30% said defects down by >10%
58% said Stakeholder Satisfaction was
higher
86% said higher job satisfaction
Sources:
QSMA (Michael Mah 2008)
David Rico (2008)
VersionOne (2008)
14. Agile is being used by
•Microsoft •Intuit
•Yahoo •Nielsen Media
•Google •First American Real Estate
•Electronic Arts •BMC Software
•High Moon Studios •Ipswitch
•Lockheed Martin •John Deere
•Philips •Lexis Nexis
•Siemens •Sabre
•Nokia •Salesforce.com
•Capital One •Time Warner
•BBC •Turner Broadcasting
•Intuit •Oce
15. Misconceptions about Agile
• It is not disciplined
• It is a specific methodology
• It does not work for large projects
• No documentation
• It works only with teams physically located at one
place
16. Agile Frameworks
Framework What is it?
Scrum Adaptive, flexible, implements small, self-organizing
development teams
Extreme Programming (XP) Customer driven, small teams, daily builds
Lean & Kanban Prioritization and limiting work-in-progress
Crystal Family of methodologies, tailoring approach for each
project, two rules and two techniques, pre & post
reflection workshops
Dynamic Systems Evolution of Rapid Application Development (RAD)
Development Method
(DSDM)
Feature Driven Five-step process, short iterations, plan, design, build &
Development (FDD) promote feature
Rational Unified Process Activity driven role assignment, business modeling, tool
(RUP) family support
Adaptive Software Adaptive culture, collaborative, iterative development,
Development (ASD) focuses on concept and culture
18. Scrum in 100 words
• Scrum is an agile process that allows us to focus on
delivering the highest business value in the shortest time.
• It allows us to rapidly and repeatedly inspect actual
working software (every two weeks to one month).
• The business sets the priorities. Teams self-organize to
determine the best way to deliver the highest priority
features.
• Every two weeks to a month anyone can see real working
software and decide to release it as is or continue to
enhance it for another sprint.
19. Characteristics of Scrum
• 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”
21. Agile in the Product Development
framework
Strategy
Portfolio Other teams in the
company plan here
Product
Release
Sprint
Day Agile teams plan here
22. Nested Time-boxes
Planning
Project
Planning
Release
Planning
Release …
Planning
Planning
Review
Review
Retro
Retro
Sprint … Sprint
Order and Structure
…
Pressure and Focus
Cost limits
No “Analysis Paralysis”
Daily Scrum
24. Multiple Backlogs
Search for options
Search by author
Select the best option
Search by
Buy a Book Enter shipping information popularity
Search by price
Make a payment
Search by rating
Shipment
Product Releases
Sprints
25. Release, iteration, & velocity
Release Planning
A release comprises
multiple iterations
Each iteration can be
thought of as a same
sized box
Stories are put into each
box until it‟s full …….. Sprint n
The size of the box is the
planned velocity
Sprint 1 Sprint 2
Courtesy: MountainGoat Software
28. Product Owner
• Define the features of the product by
interfacing with stakeholders
• Decide on release date and content
• Be responsible for the profitability of
the product (ROI)
• Prioritize features according to market
value
• Adjust features and priority every
iteration, as needed
• Accept or reject work results
• Communicate progress to the external
world
29. Scrum Master
• Makes SCRUM work - responsible for
enacting Scrum values and practices
• Removes impediments
• Ensures that the team is fully functional and
productive
• Enables close cooperation across all roles
and functions
• Shields the team from external
interferences
• Is a “Servant Leader”
30. SM vs. PM
Scrum Master Project Manager
Facilitates the process, team has Hierarchical, command and control
control mentality
Is a peer Is a “boss”
Helps team focus on managing risks Focuses on managing risk
Facilitates release and sprint Plans for the project – scope, time and
planning cost
Is not involved in estimation Estimates for the project and its tasks
Facilitates continuous improvement Responsible for continuous improvement
Team picks and manages their work Prioritizes, assigns and tracks team‟s work
according to the defined priority
Has allegiance only to the team Has allegiance to team and management
Team is responsible for success PM is responsible for success of the
project
31. The Team
• Typically 5-9 people
• Cross-functional:
Programmers, testers, user experience designers, etc.
May have a “Bouncer”
• Members should be full-time
May be exceptions (e.g., database administrator)
• Teams are self-organizing
Ideally, no titles but rarely a possibility
• Membership should change only between
sprints
• Responsibilities of Team
• Attend the Daily Scrum
• Update the Sprint Backlog
• Carry out the tasks as per the Sprint Backlog
35. Product Backlog
• A list of all desired work on the project
• Ideally expressed such that each item
has value to the users or customers
of the product
• Prioritized by the product owner
• Reprioritized at the start of each
sprint
• Contains:
• Requirements (E.g. User stories)
This is the • Defects
product backlog • Risk-related actions
• Change requests
• Any work that was not planned initially and
was added later
36. A Sprint Backlog
Remaining Work
Tasks Mon Tues Wed Thu Fri
Code the user interface 8 4 8
Code the middle tier 16 12 10 4
Test the middle tier 8 16 16 11 8
Write online help 12
Write the foo class 8 8 8 8 8
Add error logging 8 4
Courtesy: MountainGoat Software
37. Sprint Burndown Chart
Tasks Mon Tues Wed Thu Fri
Code the user interface 8 4 8
Code the middle tier 16 12 10 7
Test the middle tier 8 16 16 11 8
Write online help 12
50
40
30
20
10
Hours
0
Mon Tue Wed Thu Fri
Courtesy: MountainGoat Software
39. Traditional Vs. Agile
S No. Traditional Agile
1 Resist change Embrace change
2 Comprehensive documentation „Just-Enough‟ documentation &
working software
3 Document-driven communication Team collaboration & necessary
documentation
4 Upfront planning Continual planning
5 Detailed requirements Customer collaboration
6 Test after development Test early & often
7 Predictive Adaptive
8 Design before development Emergent design
9 Delivery at end Frequent delivery
40. DSDM‟s Inverted Triangle
Model
Functionality Resources/Cost Time
fixed
Agile
Traditional
vary
Time Resources/Cost Functionality
41. When to Transition?
◦ Ask - does your current process work?
Does it help us deliver high customer value?
Does it help us deliver on time?
Does it help us stay within budget?
Is our competition always ahead?
Are our requirements changing?
Are our customers happy?
Are our teams happy?
43. Road Map to Agile
Decide on the roll-out approach
Form Agile teams
Decide on a minimal process
Appoint Scrum Masters and Product Owners
Create Product Backlogs
Training and Orientation
Intensive coaching for the first few sprints
Tailor the process
Improve … Improve … Improve
Get help from an Agile Coach!!
44. Roll-out Approach
Two options:
• Big bang - All teams
• Gradual - Pilot in one or two teams
How to choose?
• Size of the company
• Size of the problem
• Ability to succeed
• Availability of skilled coaches, POs, SMs
45. Select a Right Pilot Project
Large Pick This
One
Project
Size
Duration
Short Long
Small
46. Form Agile teams
Cross-functional
End-to-end functionality
5-9 people
Full time resources
What other supporting teams will you
need?
47. An Agile Organization -
Example
Management
Marketing Dev
Teams
Testing
Team
Product SM /
Team Process
SCRUM Team
SCRUM Team
SCRUM Team
SCRUM Team
Product
Supporting Teams
Technical Experts, Integration and Build Teams, Domain Experts, Regression
Test Teams
48. Decide on a “minimal” process
Sprint duration and schedule
Release schedules
Demo schedules
Build schedules
Mandatory standards like Code
Mandatory tasks like Code Review
Unit and Regression Test automation
Defect handling
Agile tools for tracking
What else??
49. Appoint Scrum Masters
A very critical role!
Look for the correct attitude and
aptitude!
Leads are not potential Scrum Masters
Mid-level people work best
We rotate this role after some sprints
One SM can have one (ideal) or two
(max) teams
The SM must not handle sprint tasks
50. Appoint Product Owners
Also a very critical role!
Look for the correct attitude and
aptitude!
Leads can be potential Product Owners
We must not rotate this role
One PO can ideally handle only one
team
A PO must not handle sprint tasks
51. Create a Product Backlog
Break up requirements into end-to-end
functionalities
Define Agile requirements – small,
detailed, with acceptance criteria, e.g.
user stories
Address needs of all “customers”
Address needs of the team
Prioritize!
52. Training and Orientation
Involve everybody
• Customers, Senior management, Sales and
marketing, Business analysts, Portfolio managers, Project
managers, Agile teams
Can use standard programs like CSM, CPO
Half to Two Day modules are enough – a lot
happens as we go along with a coach
Teams love this approach, others take some
time to adapt!
53. Intensive coaching for the first few
sprints
Involve an Agile Coach in
◦ Sprint planning and estimation
◦ Daily scrum
◦ Retrospectives
◦ Group and one-on-one coaching sessions
with SMs and POs
◦ Ensures all in the team learn to perform their
roles
54. Process Tailoring
• Start with normal Agile, tailor based on
experiences
• Needs to be done with care –
interconnected practices
• View agile methods as tools
• Change for the good
• Treat the cause, not the symptom
• Try small doses
55. Improve … Improve … Improve
Improve the Product
Improve the Process
Improve the Skills (People)
Every retrospective brings about
improvements
56. Methodology Anti-Patterns
• One size for all projects
• Intolerant
• Heavy
• Embellished
• Untried
• Used once
Courtesy: Alastair Cockburn
57. Principles for Project Success
• Face-to-face communications
• Excess methodology weight is costly
• Larger teams need heavier methodologies
• More ceremony for more critical projects
• Increasing feedback and communication
reduces the need for intermediate deliverables
• Discipline / skills / understanding over process
/ formality / documentation
• Efficiency is expendable in non-bottleneck
activities
Courtesy: Alastair Cockburn
58. Agile Adoption: Barriers and
Concerns
Source: VersionOne, 5th Annual “State of Agile Development” Survey 2010”
59. Leading Causes of Failed Agile
Projects
Source: VersionOne, 5th Annual “State of Agile Development” Survey 2010”
60. To Summarize
Necessary for Successful Transition (ADAPT
model)
◦ AWARENESS that the current process does
not deliver
◦ DESIRE to adopt Scrum as a way to address
the current problems
◦ ABILITY to succeed with Scrum
◦ PROMOTION of Scrum by sharing experiences
◦ TRANSFER of the implications of using Scrum
across the organization
Courtesy: Lori Schubring
61. Thank You
My contact info: anu.khendry@gmail.com
Some slides in this presentation are from freely
shareable resources at MountainGoat.com