Key success factors included dedicated cross-functional teams, executive support for minimum marketable features, and setting a

1. An approach to scaling Agile in Mid size
Enterprise Application Stack/ Products
Discuss Agile – Delhi June 2015
Scrum Bangalore 14th Meetup - September 5th 2015
Saikat Das
CSM, CSP, SAFe Agilist, ICP Agile, DAD- Yellow Belt

2. • Case introduction | Profile of the Company
• What is scaling Agile in brief and why difficult
• Some Scaling Frame work
• What is the motivation to look for Scaling Agile
• Journey pre and post scale
• The Model (Team and Cadence)
• Outcomes
• Factors enabling Better Success
• Challenges during scaling
Agenda

3. • This Scaled Agile Delivery model of non-food eCommerce
platform of one of the onsite’s biggest retailer
• around 6 lacs unique visitors per day; web demand of 1 million GBP;
1500 orders per hour, 18K orders per day
• Application Stack:
• Oracle ATG Commerce, Sterling commerce (OMS), Oracle PIM
(product induction), Tibco IL (business logic), Liferay portal(market
place) supported by in-house Customer profile management
system, Integration with third parties for payments, recommenders,
Customer Reviews etc.
• The following slides shares details from the actual Scaling of
Agile in the organization for few verticals.
• some information are not shared to respect confidentiality of
organization specific data
Introduction

4. • Repeating agile successes embodied
in large team across an organization
(could be multi-location )
• Applying agile thinking to cross-
product projects
• Applying agile and lean thinking to
development organizations
• Transitioning from small-scale agile
to large-scale one
What is Scaling Agile

5. • Complex and takes time
• Demands Discipline, Genuine Adaptation,
Cultural Changes, Top Down Approach and
Persistence
• Requires Agile maturity for progress of
Scaling and provide solid foundation.
• There is no perfect scaling formula that
guarantees success for every company.
• Standardized Frameworks (Safe, Less, DAD
etc.) definitely helps when you are blank
slate but sometimes it needs certain
organization specific tailoring.
Why Scaling Agile is difficult

6. SOME OF THE SCALING APPROACHES

7. Scaling and Agile Onion
Team Level
Program
Level
Portfolio
Level

8. Environment
Teams
Leadership
Values &
Principles
Process
Business/
Market Drivers
… just to show
major areas
for consideration
Number of
Products
developed
using Agile
Teams working
on the same
product
Agile Maturity
and Enterprise
Discipline
Organizational
Distribution
and
complexity
Amount of
Business
involvement
Geographical
Distribution
Agile Transformations are Multidimensional

9. • What is your primary business goal for improvement?
(decreased Time to market, increased customer
Satisfaction……)
• Do you need to scale all teams/ department etc. to reach that
goal?
• What kind of scaling is more important to reach that goal?
(vertical or horizontal or both)
• What scaling practices could help to reach that goal?
• Are there any quick wins by using low effort, high impact
practices?
Questions on why scaling?

10. Types of Scaling
Verticalscaling
Horizontal scaling

11. What is generally Scaled
• Number of Teams? (vertical)
• Coverage of Value Stream ? (horizontal)
• Business, Engineering, Support teams, Operations etc.
• Number of Organization Levels? (both)
• Classical Functional: Team, Department, Division, Enterprise
• Team, Program, Portfolio, Business Unit, Enterprise
• Large Scale Scrum (LESS): Feature Team, Requirement Area, Product
• Levels of Inspect and Adapt Cycles? (both)
• Iterations, Release, Road Map, Product Vision, Business Model

12. • To synchronize and align delivery of number of teams to realize
Ideas/ Business Epics at portfolio level
• Enable business leaders to prioritize aptly and control/cancel failing
projects early, lowering risk and potential waste.
• Reduce longer release cycle; respond fast to changing marketplace.
• Deliver value early and often to see results (ROI) quickly
• Improve collaboration between business leaders and development
teams to build stronger relationships and overall team spirit.
• Stop missing critical delivery dates with predictability & cadence
• Have matrix at Sprint, Release and Program levels
• Address quality issues due to late integration and high
dependencies on other systems
• Provide systems view where agile methods (Scrum, XP, Kanban)
constraints view beyond the team
Our motivation to look for Scaling Agile

13. Setting foundation (essential for scaling)
• Pilot in few verticals, focusing on enabling Teams to deliver high
value, high quality work product incrementally and iteratively
• Incorporating feedback loop with actual customers
• User Advisory Groups, Core Agile Group
• Introducing Agile COP and Agile coaches building strong Scrum
Masters
• Inculcate culture
• Of Quality
• Of cross-team collaboration and transparency
• Shifting roles of teams, management, executives
• Resist temptation to solve enterprise problems just yet
• Be wary / mindful of them
• Have roadmap, but take incremental approach

14. High Capability, Low Willingness
• Have high degree of awareness when
coaching;
• be ready to jump in and actively
facilitate.
• Provide “personal” coaching - 1:1.
• If no change in a reasonable amount
of time, then switch team/member
High Capability, High Willingness
• This is your “sweet spot” where you
ideally would like to have everyone on
your team operate.
• This gives much greater chance for
operating successfully under Agile.
Low Capability, Low Willingness
• Consider immediate switch-out.
• Poor attitude combined in inability to
deliver can be a toxic combination to
the team. .
Low Capability, High Willingness
• This is your second choice of team
members.
• A good attitude with willingness to
learn and embrace Agile values and
principles greatly contributes to a high
performing team.
• Over time, technical skills can be
learned.
LowHigh
Low High
Willingness
Capability
 All 3 levels with high capability, high willingness (Appendix)
Setting foundation - team consideration (essential for scaling )

15. Our Agile Journey pre-scaling
• X Scrum teams in 2012 in India
• Release Management Team to do Air traffic control and align Teams’
output as every Team had different sprint cycle
• Had to wait 2 weeks for everyone to align and do release every 3-4
months
• Pre Release planning for 2 weeks to get release plan ready
• No Dev Scrum team in onsite all based out of Bangalore.
• UX used to happen in onsite
• UX and requirements was handed over to Bangalore team during Release
& Sprint planning
• Many Integration and post production deployment issues.
• More of Scrum Fall 

16. Agile Journey for scaling
• X + n Scrum Team across India and onsite.
• Decentralize work & decision making
• To have better coverage of Daily Time window, few Dev and Test
members travelled on rotation to onsite and vice versa to empower
cross functional learning.
• Apply cadence, synchronize with cross-domain planning
• Moved to 2 release cadences for the teams either fortnightly or monthly
• Followed Service oriented approach; service and product decoupled
from each other.
• Service would precedes the Product Sprints, if otherwise tested through
stubbing .
• Held Agile focused educational workshops with the core teams
• Disciplined Environment Refresh to better utilize the Real Estate
• Assumed Variability and preserved options for that and improved
with integrated learning cycles.

17. Agile Journey for scaling, continues….
• Hosted Big Room release planning workshop with PO, Architecture,
Scrum Team and dependent teams were introduced.
• For cross geography we used Tele Presence/ Video Conferencing
• Continuous Backlog grooming introduced with Feature Driven
teams (wherever Applicable) to best leverage domain and
technology expertise.
• More Telepresence and Visual Collaboration tool added for meetings
• Continuous Integration and Deployment in the Production like/
Staging Environment
• Incorporated Lean & Kanban principles – Visualize and limit WIP,
reduce batch sizes and manage queue lengths for some Value Flow
Streams.
• Used Kanban for support work with WIP management.
• Created SM Community of Practice (CoP)
• Share experiences, common “templates”, metrics, etc.

18. Domain 1
Domain 4
Domain 5
Non-foodOnlinePortfolio
Domain 3
Domain 2
W2 W3 W4
Sprint Sprint
W1
Domain 6
W6 W7 W8W5
Sprint Sprint
Domain 7
Domain
Teams
Scrum
Teams
Scrum
Teams
Scrum
Teams
Scrum
Teams
Scrum
Teams
Scrum
Teams
Scrum
Teams
Sprint and Release Cadence

19. Distributed Agile Team – Enterprise Level
Location B
Location B
Location B
Location B
Program Manager
Program Manager

20. Group Roles – Enterprise Level
Product Ownership/
Management
• Pool of Product owner/ managers
• Some of them plays Lead PO for one or
more programs based on experience
• contribute to understand the product/
business vision and requirement
• Add items to Product Backlogs
Program Management
• Pool of Program managers
• Some of them plays Lead PO for one
or more programs based on
experience
• help to run programs achieving
Business roadmap
Scrum of Scrum
• For all the scrum in a vertical or
Domain
• Sometime cross domain to
handle bigger programs
Lead PO
PO Group
Lead SM
SM Group
Lead PgM
Pgm Group

21. Team Structure & Roles – Org level

22. Team Structure & Roles – Scrum level
Scrum
Master
Test Test/
Automation
Dev
Tech Expert/
Dev
Dev
Dev
Test/
Automation
Dev
UX
DBA DEV OPs UX Testers
SME
Product
Owner

23. W1 W2 W3 W4 W5
DevOps
Overnight Automation Regression Pack
Shared Resources
Like UI/UX, Architect
Sprint 1 Sprint 2
ALIGNMENT
Chief Architect/
Architecture
Board
[responsible for
initial technical
architecture of
Epics and
Features]
ReleasetoProd
Execute
S
p
r
i
n
t
P
l
a
n
n
i
n
g
S
p
r
i
n
t
P
l
a
n
n
i
n
g
Scrum Team & Sprint
Backlog
Release on Demand
HardeningActivities
Product
Backlog
UX Regression pack
Chief Product
Owner
[responsible for
initial Idea and
Epics]

24. Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan
Coordinate release planning with generic framework
Planning cycle for next release
RELEASES
Release Cycle

25. Continuous Release Plan & Backlog grooming Cadence

26. Continuous Backlog Grooming
• Continuous Backlog grooming 3-6 hours a week between PO, Architect and
focused group from Scrum team
• Grooming done for next Sprint – Story Split, Acceptance Criteria Finalization,
Estimation, Business Value, Dependency call out etc.

27. Release Plan and Program Board

28. States and Sub-states for Managing Engineering Flow
IDEA REFINE BUILD DEPLOY LIVE
To do
In
Progress Done
To Be
Refined
In
Refine
Ready
for
Build In Build
In
Test
Ready
to
Deploy
In
Deploy Deployed Done
 High level T
Shirt sizing
done
 Features
called out as
feature story
 Tech design
blue print
created
 High level
Technical
Dependencie
s called out
 High
Functional
Dependencie
s called out
 Epics
reviewed
with
Technical
Expert
 Low level Functional
dependencies called
out
 Low Level Technical
dependencies called
out
 User story with clear
acceptance criteria
defined
 Low level Tech
Design discussion
Start
 NFR's defined
 Business value
defined at story level
 Stories prioritized in
the backlog
 Story definition and
technical documents
discussion
developers
 MVP definition
created
 Estimation done in
story points
 Wire frames created
and reviewed
 UX and Tech design
starts
 User stories
walkthroug
h by PO
 Wireframes
1st level
review by
PO
 Tech design
reviewed
by SA
 Test
scenarios
reviewed
with PO
 Sonar quality
metrics met
 Peer code review
completed and code
review comments
incorporated
 Static checks and
gated check-in
passed
 Unit testing
completed
 Switch / dormant
configuration
document updated
 Any new stories
added back to the
backlog
 Test automation
suite extended for
new functionality
 Integration testing
completed via stubs
/ virtualization
 Any alerting or
monitoring
implemented and
verified
 Performance
baslining completed
 Any knowledge
transfer document /
page / LLD updated
 UX
regression
completed
 Regression
Automation
Suit passed
 DB
Backward
Compatibilit
y testing in
NFT
 App roll
forward in
NFT
 Functional
Sanity in
NFT with
Automation
 NFT Base
line Test for
NFRs
 Measure
Site
confidence
journey
timings
 Operational
Acceptance
test
(optional)
 Prod
Package
Build and
RFC creation
 Execute
Pre-
Deploymen
t Steps
 UXP
repoint to
live copy
 Execute
Post UXP
Steps
(publishing
changes_)
 DB Roll
forward in
Prod
 App roll
forward in
Prod
 Post App
roll forward
steps
 Hyper Care
Testing by
POs
 Cutovers
Steps

29. End to End visualization on Scrum Board

30. Delivering early and often – Environment Usage
Development
Environment
Functional
Test
Environment
Non-
Functional
Test
Environment
Production
Development
Environment
Non-
Functional
Test
Environment
Production
Systems
Integrated
Testing (SIT)
Environment
before Scaling
Functional Test
Environment
Systems
Integrated
Testing (SIT)
Environment
After Scaling

31. Continuous Integration, Deploy, Delivery & Support
Done in Dev Local box
Check-in in central source control repository ( with Gated Checking),
Static Code analysis done post check-in (PMD , Check Styles, Sonar)
Deployed in on a production like environment
Check if packages installed correctly? Automated Regression suit pass?
Done using automation when we release once or twice in a month
Supports all above and post production activities

32. CHARACTERISTIC OUTCOME(S)
Scrum Team
Performance
Generally good to excellent –
 60 % fewer bugs
 Throughput of the team increased substantially
 Collaboration within Team greatly increased; teams
functioning as teams more engaged and empowered
Executive Team
Activities
 Adopted mindset of Minimum Marketable Features
(MMF) for customers
 Excellent engagement with their Customers
Customer Satisfaction  Generally quite higher at the Scrum team level via
continuous delivery of working software and making
adjustments due to feedback
 Moderate improvement at the Customer’s Executive
levels? Portfolio level
Did Scaling happen?  Yes – at least for the Domain and Team targeted, with
more planned upon leaving
Delivery Cycle Time  Average Delivery Cycle time is down from 3+ months to
1 month resulted from 4 released to 10 in a year
 More than 96% project delivered on Time and in Budget
 30% cost to Deliver Reduction
Product Management  Significant improvement in Product Management and
Development Team work.
Outcomes

33. What factors
enabled greater
success?
 Tremendous work ethic
 Belief in product
 Demonstrating Agile
Principles at 3 levels
 Dedicated, Continuous
Teams
 Sprint Review Participation
 Execs/Mgmt. Curiosity
Work through pivots
 Set foundation to scale
 Actions

34.  Teams ready to work towards the same goal, in a rhythm and keep them
in sync?
 Coordination exists between the teams (resolving dependencies
between the smaller teams)?
 Do you have a decision making framework in place?
 Do you have plot to integrate teams’ work products (working software)?
 Have platform to Involving all major stakeholders during planning,
discussion and demonstration
 Do you practice Program, Portfolio management and Market releases?
 How Immature is your Agile teams? Can they be Trained on priority
(consistent Agile Practices)?
 Is your Organizational structure Simple or overtly complex?
 Do you have Infrastructure for Scaling and following process supporting
Agile and continuous delivery?
Challenges when SCALING

35.  Do your Executives:
 Believe there is a problem with the status quo of the
organization?
 Agree there is need to alter their behavior in order for the
organization to change?
 Understand they need to reestablish relationships with their top
customers, help their customers come along with the
transformation journey as well?
 Have the fortitude to prioritize on a limited set of key strategic
initiatives and let others go?
 When it comes to the act of releasing product incrementally:
 Is your organization ready to go for incremental releases?
 Are your customers willing to accept incremental releases?
 Ready roll out a set of Standard practices incrementally across
organization?
Challenges when SCALING? Continued…

36. QUESTIONS?
https://in.linkedin.com/in/saikatdas16
@dsaikats

37. REFERENCES
Books:
 A Tale of Two Transformations: Bringing Lean and
Agile Software Development ... By Michael K.
Levine
Books:
 Agile estimation and planning – Mike Cohn
 Software Estimation : Demystifying the black art –
Steve McConnell
Organizations:
• Scrum Alliance (www.scrumalliance.com)
• Mountain Goat Software
(www.mountaingoatsoftware.com/)
• Scaled Agile Framework
(www.scaledagileframework.com)
• Discipline Agile Development
(www.disciplinedagileconsortium.org)
Online Resources:
• www.slideshare.net