1. Transforming your Software
Development to Agile
Anu Khendry PMP, PMI-ACP, Six Sigma Black Belt
Coach, Consultant and Trainer – Agile, PM, SPI

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)

3. Overview of Agile

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

8. Project Chaos Level
Agile works
here

9. Iterative & Incremental
Development
Incremental
Iterative
Courtesy: Jeff Patton

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

17. Overview of SCRUM

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”

20. Scrum 24 hours
Sprint
2-4 weeks
Sprint goal
Return
Sprint backlog Potentially shippable
Return
Cancel product increment
Gift wrap
Coupons
Cancel
Gift wrap Coupons
Product
backlog
Courtesy: MountainGoat Software

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

23. Progressive Elaboration
Product Sprint
Backlog Backlog
Sprint Stories, Themes
Priority
Release Epics
Future Ideas
Releases

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

26. Scrum Framework
Roles
•Product Owner
•Scrum Master
•Team
Ceremonies
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artifacts
•Product backlog
•Sprint backlog
•Burndown charts

27. Scrum Roles
Roles
•Product owner
•Scrum Master
•Team
Ceremonies
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artifacts
•Product backlog
•Sprint backlog
•Burndown charts

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

32. Scrum Ceremonies
Roles
•Product owner
•Scrum Master
•Team
Ceremonies
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artifacts
•Product backlog
•Sprint backlog
•Burndown charts

33. Scrum Ceremonies
Sprint Planning
Sprint Review
Sprint Retrospective

34. Scrum Artifacts
Roles
•Product owner
•Scrum Master
•Team
Ceremonies
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artifacts
•Product backlog
•Sprint backlog
•Burndown charts

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

38. Traditional vs. Agile Software
Development
What needs to change?

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?

42. Sample Road Map for
Transition

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