Tries to impart some knowledge about steps for agile transformation in large organisations and business units

1. Strategies for
Large Scale Agile
Transformation

2. Agenda
• Phase 1 – Introduction and Why Agile
– Identify the need for change
– Apprise Executive Management on Agile Organizations
• Phase 2 – Familiarize Current Picture
– Gauge current state of affairs
– Propose the change and ways to measure impact
• Phase 3 - In-Detail on Principles and Practices
– Apprise Team
– Identify and Impart Trainings
• Phase 4 – Applying Principles and Practices
– Select Pilot Project
– Showcase agile principles and methods in practice
– Challenges
– Next Steps
• Phase 5 – Inspect and Adapt

4. Introduction

5. How Did We Get Here?
Incremental and iterative development has been around for a
long time.
1960s 1970s 1980s 1986 1990s 1991 2000s 2001 2003
EVO Spiral
Model
Scrum
First Coined
XP
DSDM
RUP
Scrum
Formalized
AUP Agile LeanWaterfall
Defined
Time Line

6. February 2001 Snowbird, Utah
• 17 proponents of iterative, incremental and lightweight
methods
• They agreed on values based on trust and respect
• The Agile Alliance formed
• The Agile Manifesto written

7. Agile Manifesto
Weareuncoveringbetterwaysofdeveloping softwareby
doingitandhelpingothersdoit.
Throughthisworkwehavecometovalue:
• Individualsandinteractionsoverprocessesandtools
• Workingsoftwareovercomprehensivedocumentation
• Customercollaborationovercontractnegotiation
• Respondingtochangeoverfollowingaplan
Whilethereisvalueintheitemson theright,
wevaluetheitemsontheleftmore.

8. “Agile” is …
• a way of developing software that is consistent
with the principles of the Agile Manifesto
• a framework within which complex products in
complex environments are developed
• the ability to adapt to change and evolve
throughout the lifecycle of the project

9. Agile Practices
Scrum
Automated Testing Open Workspace
Test Driven Development
Executable Requirements
XP
Small Frequent Releases Coding Standards
OOAD and Patterns
Customer Team Member
Acceptance Testing Sustainable Pace

10. Why Agile?

11. Usage of Features
and Functions
Always
7%
Often
13%
Sometimes
16%
Rarely
19%
Never
45%
Source: Standish Group Study of 2000 projects at 1000
companies
Usage of Features and Functions In Typical System

12. More Bad News…
• 66%1 ofprojectssignificantlyoverruntheirbudget.
• 70%2 ofdefectsinproductionareintroducedintherequirementsstage
• 70%3 ofthetotalcostofownershipforsoftwareismaintenance.

13. Lower Cost of Change By High Quality Software

14. Effectiveness of standard “Waterfall” methods
1. Source: Standish Group, 2005 Chaos Report
2. Source: J. Johnson, Keynote speech, XP 2002 Italy
• Theaverageprojectexceedsitsscheduleby84%1
• 64%2offeaturesdeliveredareneverused.

15. What Businesses are interested in:
• Delivering fewer defects
• Delivering what the customer wants
• Open communication with the customer
• Being trusted by your customer
• Showing working software frequently
• Having control over the way you work
• Understanding who is supposed to do what
• Working at a sustainable pace
• Finding more satisfaction in your work

16. Agile is a Response to
• Too many artifacts
• Too much documentation
• Inflexible plans
• Late, over budget and buggy software
• Not delivering what the customer wants

17. Business Case for Agile
• Quicker to Market
• Better Understanding of Customer Needs
• Higher Customer Satisfaction
• Lower Risk Through Early Discoveries
• Lower Risk by Delivering Incrementally
• Higher Return On Investment
• Accelerates ROI
• Progress is Measured by Actual Working Software
Thereisan85%
overheadreduction
goingtoanAgile
model

18. Paradigm Shift
(Changing a “mass manufacturing, assembly line” mindset to an “innovative, new-product” mindset)

19. Acceptance Test
Driven Development
(Executable
Requirements)
Automated
Integration Testing
(Interface Driven
High Level Design)
Unit Test
Driven Design
(Low Level Design)
Unit Test
Driven Development
(Implementation)
V-Model to I-Model
(Changing a “waterfall” verification and validation testing mindset to test-driven defect prevention mindset)

20. Agile Adoption Trends

21. Global Agile Adoption Trend

22. Benefits of adoption Agile

23. Agile Adoption-India
Demographics of Agile Adoption.
Source: Agile Adoption India Survey
Report 2011 Thoughtworks
Factors Influencing Agile Adoption
Source: Agile Adoption India Survey Report 2011
Thoughtworks
Reported by economic times 6th Aug 2012

24. Scrum Leading Agile Transformation Globally

25. Agile Organizations

26. Agile Organizations
• Cross-functional teams aligned directly to
solve business problems
• Products
• Features
• Programs
• Components
• Services
• Business Capabilities

27. Agile Organizations
• Clear voice of the business and a willingness
to make tradeoffs to meet time and cost
constraints
• Highly engaged product ownership
• Willingness to deal with reality
• Focus on maximizing value and reducing risk

28. Agile Organizations
• Individual empowerment and shared
accountability for outcomes
• Establish boundaries and ownership but empower
within those boundaries
• Teams own outcomes not activities

29. Agile Organizations
• Disciplined attention to technical excellence
and product quality
• Technical excellence stabilizes the requirements
delivery function

30. Agile Organizations
• Predictable, accountable, able to consistently
make and meet commitments
• Teams have the ability to consistently do what they say
they are going to do
• Predictable agile teams are the foundational element
of a predictable agile enterprise

31. Agile Adoption and
Transformation Journey

32. Adoption vs. Transformation
• First... Let’s understand the two terms that often
used interchangeably
– Agile Adoption is about what we do...
practices, tools, techniques, ceremonies, and habits
– Agile Transformation is about who we are...
reflected in both the structure of the organization
and who we are as people
• For long term success organizations need both adoption and
transformation

33. Adoption vs. Transformation
• Second... we want clearly explain the three major
focus areas that must be addressed
• Organizational Structure is about how you create teams
and how you organize them
• Agile Practice is about the methods and tools you choose
to introduce
• People and Culture is about changing hearts and minds of
the individuals in the organization
– All three aspects are essential to sustain agility of any
organization

34. Incremental vs. Iterative
• Third... we want introduce the notion that
introducing Agile is an iterative and incremental
process for you organization
• Iterative is when parts of the system are developed at
different times and integrated as they are completed
• Incremental is when you go back over parts of the system
making improvements
– The strategy is to increment the organization by
building teams and iterate the teams over time

35. Adoption/Transformation Cycle
• Incrementing and Iterating the Agile
Enterprise
– Change physical structures and introduce teams
– Teach people new practices and ways of working
– Help people internalize the value system

36. Adoption/Transformation Cycle
• Organizational Transformation
– Establish top to bottom structure and roadmap
– Incrementally make changes and establish teams
– Define policies and working agreements between
teams

37. Adoption/Transformation Cycle
• Adopting Practices
– Sprint planning, daily stand-ups, product
reviews, and retrospectives
– Identify and train a Product Owner and Scrum
Master
– Teach TDD, CI, Story Maps, and MMF

38. Adoption/Transformation Cycle
• Personal Transformation
– Develop an ability to deal with uncertainty and
adaptation
– Help people work toward common organizational
goals
– Help foster empathy, trust, and teamwork

39. Common Anti-Patterns
• Establishing teams without breaking down
the strict functional silos and rigid role
definitions
• Running daily standup meetings that
devolve into status updates for the project
manager
• Coming back from Agile training only to find
that there is no way to form agile teams and
no interest in agile

41. Understanding Current State of
Affairs

42. Understanding Current State of Affairs
• Management Engagement
• Team Engagement
• Measure Current Process Maturity
• SWOT Analysis

43. Management/Leadership Engagement
• Engage with mid-level to upper level managers
• Talk to them to understand on how they perceive
general work trends and issues/concerns and
current state of affairs
• Create openings for collaboration
• Attend as many currently running meetings as
possible
• Just Listen – Don’t offer any suggestions or
solutions

44. Team Engagement
• Engage with teams on the shop floor
• Talk to as much individual team members on
general work trends and issues/concerns and
solutions, if any
• Create rapport with teams
• Attend as many currently running meetings as
possible
• Just Listen – Don’t offer any suggestions or
solutions

45. Measure Current Process Maturity
• Engineering Processes (Quality Management
System)
• Engineering Practices
• Compliance to Mandatory Regulations
(FDA, SFDA, etc.)

46. SWOT Matrix
• Prepare SWOT Matrix to find out
– Areas of strength
– Areas for improvement
– New opportunities/practices to adopt
– Threats if not adapted to changing environment
w.r.t business

47. Results

48. Current State of Affairs
• Inorganically grown organization
• Waterfall + iterative model for development
• Specialised teams for each function
(Development, Testing, Product
Management, etc.)
• Teams are always busy with new programs or
maintaining existing ones

49. Other Challenges
• Persistent customer complaints w.r.t quality and
performance of the products
• Significant cost and schedule overrun
• Silos
• No clear understanding of progress made
• No common processes followed
• Frequently changing requirements
• Most time spent on fire fighting
• High attrition rates

51. Solution

52. Proposed Solution
• Adopt Agile principles and practices to have short-
cycled releases to facilitate instant/early feedback from
Customers
• Invite selected customers for demos and pilot
programs to build trust and transparent
communication
• Encourage and incentivise cross-team communication
and collaboration
• Provide and environment conducive of collaborative
development (as proposed by Agile principles)
• Create Product Owners with responsibility for the ROI
of the product lines

53. Which Agile Practices to Adopt
• Scrum
– Lightweight Framework for Program/Product
Management
– Very minimal prescriptions
– Importance to Customer value generation all the time
• XP (eXtreme Programming)
– Solid engineering practices and principles
• Portions of UP (Unified Process)
– Enhances product vision and goals for better
execution of business strategy and goals (long and
short term)

54. Why Scrum
• Widely adopted agile practice
• Promotes Short-cycle releases instead of big-bang releases
– Thereby increases opportunity for early customer feedback and
improvement opportunities
• Bring in the concept of Product Owner (PO)
– Responsible for product life cycle and ROI
• Promotes the idea of Potentially Shippable Product Increments
(PSPI)
• Promotes Iterative development (called Sprints)
– Short, time-boxed delivery of mutually agreed items between team
and PO.
• Requires cross-functional teams (Dev+Test+Product Management)
– Breaks the silos and creates a multi-talented teams capable of tackling
business priorities

55. Why Scrum
• Moots the concept of self-managed teams
– Places the job of estimating tasks and feature into the people who
actually develops them
– Improved estimates
• Team only picks items/features that are clear and
unambiguous
• Requires Prod. Mgr ( or Product Owner) to constantly
reprioritise requirements (product backlog) according to
changing business needs
• Promotes minimal upfront design so as to improve scalability
and minimised impact of requirement changes down the line
• Promotes review and retrospection of the iterations
completed to improve practices and process

56. Why XP
• Promotes a set of Engineering Practices that will
enhance productivity and quality of the products
developed
– TDD (Test Driven Development)
– Pair Programming (detects and help to remove code
defects very early)
– CI (Continuous Integration) to make sure code quality
is maintained
– Refactoring to remove any technical debts
• Inline with agile principles and complements
Scrum framework

57. Why UP (Unified Process)
• Establish product and release vision
– Helpful in prioritising requirement for a release
– Helps to identify the targeted customer base w.r.t a
release
• Agile Modelling
– Helps to have an overall architectural design in mind
– Brings in architectural clarity w.r.t items chosen for a
given iteration
– Helps in measuring architectural impact of changed or
new requirements brought into the release

59. Rollout

60. Proposed steps for Rollout – Principles and Practices
• Ensure Executive buy-in
• Implement Scrum as program/product
management framework
• Introduce XP Engineering practices
• Small, incremental rollout is proposed
• Identify pilot product to implement the agile
principles and practices
– Create cross-functional, co-located teams
– Create open workspace for better collaboration

61. Pilot Rollout

62. Pilot Rollout – Trainings
• Agile and Scrum trainings for the entire team
– Developers
– Testers
– Product Owner/Product Manager
– Identify Scrum Master(s)
– Requirements writing (Stories, Use Cases)
– Estimation Techniques
• Relative Estimation Technique
• Story point Estimates
• Planning Poker

63. Pilot Rollout – Trainings
• Engineering Practices Trainings
– Test Driven Development
– Writing Unit Test Cases
– CI tools (Hudson, CruiseControl, etc.)
– Configuration Management Tools (ClearCase, SVN,
etc.)
– Architectural best practices
– Automated Testing (functional, performance, and
some GUI)
– Automated Build Management including automated
testing (unit and functional)

64. Pilot Rollout – Product Development
• Coach PO and teams on how to plan releases
• Includes
– Vision Workshop
– Identify the release timeframe and requirements that
need to be implemented
– Prioritize the requirements (user stories)
– Estimate requirements
– Participated by Team, PO, Scrum Master, stakeholders
(if any)
– Product Backlog Creation

65. Pilot Rollout – Product Development
• Coaching teams on Sprint Planning
• Includes
– Tactical development plan
– Team commitment
– User Stories are broken down into tasks
– “Definition of Done”

66. Pilot Rollout – Product Development
• Coaching teams on Daily Planning
– Shared accountability
– Daily adjustments
– Generates burndown metrics

67. Product Backlog: Organized, Prioritized Requests
Sprint 1
Release
Planning
Session 1
Sprint 2
Sprint 3
Sprint 4
Sprint 5
Releasable Code
Release
Planning
Session 2
Release 1
Agile Process Flow

69. Tracking Progress

70. Pilot Rollout – Tracking Progress
• Collect Metrics
– Velocity (number of story points delivered per
iteration)
– Sprint Burndown (tasks completion rate in an
iteration)
– Release Burndown (stories/features completion
rate)

71. Pilot Rollout – Tracking Progress
• Identify improvement opportunities by
discussing the metrics with teams
– Improving estimation techniques
– Improving requirements/user stories
– Improving technical skills
– Improving physical assets of the team, etc.
• Elicit suggestions from team for improvement
• Assist teams in implementing the suggestions
by talking to appropriate stakeholders

72. Some Challenges

73. Pilot Rollout – Challenges
• High cost of training and related changes in
the organisational structure
• Fear of Loss of productivity during the pilot
phase
• Executive Leadership push for all-out rollout of
agile practices
• Training vs. implementation of Agile and
Scrum principles and Practices
• New methods for estimation (Story points)

74. Pilot Rollout – Challenges
• Management expectation of high/improved
productivity from first iteration itself
• Low productivity during initial iterations
(sprints) induces low morale and confidence
among teams and management
• Push back/inertia from existing team
members against Scrum and Agile adoption

75. Pilot Rollout – Resolving Challenges
• Reiterating the value-based delivery model of
agile
• Clear upfront communication about “reduced”
productivity during initial stages of adoption
• Hand-holding team whenever and wherever
necessary to allay any doubts they might have
w.r.t agile and scrum practices
• Explain the importance of organisational change
and the associated cost
• On-the-shop floor coaching and mentoring

76. Pilot Rollout – Resolving Challenges
• Regular executive updates on adoption
progress, challenges, and resolution to sustain
the confidence level
• Progress towards less-intrusive coaching and
mentoring by creating scrum masters and
technical experts to carry forward the
momentum
• Targeted sessions on different aspects of project
and product management w.r.t agile and scrum

77. Pilot Rollout – Resolving Challenges
• Technical Colloquium to find and moot
reusability across product lines
– Facilitated by Chief/Enterprise Architect
– Can result in creating a platform approached
owned and developed by different teams as
required
– Explore newer architectural best practices that
could be adopted to reduce overall development
cost

78. Pilot Rollout – Resolving Challenges
• Impart trainings and touch-points to improve
– Technical, functional, and domain expertise within
teams
– Cross-pollination via short sessions of different
product lines and their applicability in the market
• Open Workspace
– Improved collaboration
– Reduce email clutter

79. Pilot Rollout – Resolving Challenges
• Weekly Architects’ Round-up
– Identify common components/code
– Continual design (means ahead of next sprint)
• Daily Scrum-of-Scrum
– SMs of all teams to share update with each other
– Identify common problems
– Fix or escalate

80. Pilot Rollout – Resolving Challenges
• Monthly Product Management Round-up
– To recalibrate the product backlogs according to changing
business priorities and release content according to team
velocity
• Monthly deep dive
– To be done with Business Leadership/stakeholders
– To identify and escalate any issues that need leadership
intervention or help
– To be done by scrum masters of each team

81. Next Steps

82. Next Steps
• Introspect on the outcome of the pilot rollout
with executive management and senior
leadership
• Explain the metrics, areas of improvement,
and future plan
• Secure buy-in from the business stakeholders
for continued rollout

83. Next Steps
• With the help of executive management, select teams
that need to transformed next
– Big bang is still not preferred as we have 40+ teams across
multiple sites
– Make sure to include a multi-site team for transformation
• Introduce Large scale Agile transformation using Scrum
for multi-site teams
• Repeat Phase 2 (if necessary, else start from Phase 3)
through phase 5
• Inspect and adapt practices as and when
transformation progresses

84. Sustaining the Change

85. Rollout – Sustaining the Change
• Regular executive updates on adoption
progress, challenges, and resolution of issues to
sustain the confidence level
• Progress towards less-intrusive coaching and
mentoring by creating internal coaches, scrum
masters and technical experts to carry forward
the transformation
• Targeted sessions on different aspects of project
and product management w.r.t agile and scrum

86. Thank you
Exciting new transitions

87. Appendix
• The contents of this material was influenced
by below mentioned people
– Craig Larman – his work, teachings, and books
have inspired the section on multi-site scaling of
Scrum
– Mike Cottmeyer – his ideas were adopted in the
agile organization and transformation journey
sections