An approach to scaling Agile in Mid size Enterprise eCommerce Scrum Bangalore 14th MeetupSeptember 5th 2015
Saikat DasCSM, CSP, SAFe Agilist, ICP Agile, DAD- Yellow Belt
• 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
• This Scaled Agile Delivery model (VFQ) Case Study is used for DDR [Design, Development and Run (DevOps)] of non-food eCommerce platform of one of the UK’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
• 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
• 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
SOME OF THE SCALING APPROACHES
LAST Conference Melbourne 11/07/2014 - Bernd Schiffer
LAST Conference Melbourne 11/07/2014 - Bernd Schiffer
LAST Conference Melbourne 11/07/2014 - Bernd Schiffer
LAST Conference Melbourne 11/07/2014 - Bernd Schiffer
LAST Conference Melbourne 11/07/2014 - Bernd Schiffer
LAST Conference Melbourne 11/07/2014 - Bernd Schiffer
LAST Conference Melbourne 11/07/2014 - Bernd Schiffer
LAST Conference Melbourne 11/07/2014 - Bernd Schiffer
LAST Conference Melbourne 11/07/2014 - Bernd Schiffer
LAST Conference Melbourne 11/07/2014 - Bernd Schiffer
LAST Conference Melbourne 11/07/2014 - Bernd Schiffer
Scaling and Agile Onion
Team Level
Program Level
Portfolio Level
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
productAgile Maturity and Enterprise
Discipline
Organizational Distribution
and complexity
Amount of Business
involvement
Geographical Distribution
Agile Transformations are Multidimensional
• 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?
Types of Scaling Ve
rtica
l sca
ling
Horizontal scaling
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
• 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
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
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.
Low
Hig
h
Low HighWillingness
Capa
bilit
y
All 3 levels with high capability, high willingness (Appendix)
Setting foundation - team consideration (essential for scaling )
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 UK all based out of Bangalore. • UX used to happen in UK• UX and requirements was handed over to Bangalore team during Release
& Sprint planning• Many Integration and post production deployment issues. • More of Scrum Fall
Agile Journey for scaling
• X + n Scrum Team across India and UK.• Decentralize work & decision making• To have better coverage of Daily Time window, few Dev and Test
members travelled on rotation to UK 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.
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.
Domain 1
Domain 4
Domain 5
Non
-food
Onl
ine
Portf
olio
Domain 3
Domain 2
W2 W3 W4Sprint Sprint
W1
Domain 6
W6 W7 W8W5Sprint Sprint
Domain 7
DomainTeams
Scru
m
Team
sSc
rum
Te
ams
Scru
m
Team
sSc
rum
Te
ams
Scru
m
Team
sSc
rum
Te
ams
Scru
m
Team
s
Sprint and Release Cadence
Distributed Agile Team – Enterprise Level
Location B
Location B
Location B
Location B
Program Manager
Program Manager
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
Team Structure & Roles – Org level
Team Structure & Roles – Scrum level
Scrum Master
Test Test/ Automation
DevTech Expert/
Dev
Dev
Dev
Test/ Automation
Dev
UX
DBA DEV OPs UX TestersSME
Product Owner
W1 W2 W3 W4 W5
DevOps
Overnight Automation Regression PackShared Resources
Like UI/UX, Architect
Sprint 1 Sprint 2
ALIG
NM
ENT
Chief Architect/ Architecture
Board [responsible for initial technical architecture of
Epics and Features]
Rele
ase
to P
rod
Execute
Sprint Planning
Sprint Planning
Scrum Team & Sprint Backlog
Release on Demand
Hard
enin
g Ac
tiviti
es
ProductBacklog
UX Regression packChief Product
Owner[responsible for initial Idea and
Epics]
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
Continuous Release Plan & Backlog grooming Cadence
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.
Release Plan and Program Board
Goal
Current
States and Sub-states for Engineering FlowIDEA REFINE BUILD DEPLOY LIVE
To doIn
Progress DoneTo Be
RefinedIn
Refine
Ready for
Build In BuildIn
Test
Ready to
DeployIn
Deploy Deployed Done
High level T Shirt sizing done
Features called out as feature story
Tech design blue print created
High level Technical Dependencies called out
High Functional Dependencies 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 walkthrough 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 Compatibility 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-Deployment 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
End to End visualization on Scrum Board
Delivering early and often – Environment Usage
Development Environment
Functional Test
Environment
Non-Functional
Test Environment
Production
Development Environment
Non-Functional
Test Environment
ProductionSystems
Integrated Testing (SIT)
Environment before Scaling
Functional Test
Environment
Systems Integrated
Testing (SIT)
Environment After Scaling
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
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 CustomersCustomer 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 ReductionProduct Management
Significant improvement in Product Management and Development Team work.
Higher Returns, reduced investments in unfinished work.
Outcomes
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. CuriosityWork through pivots Set foundation to scale Actions
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
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…
BACKUP SLIDES SAMPLES FROM THE CASE STUDY
Idea and Product Backlogs - Examples
Sprint Planning is done using Planning Poker and Relative Story pointing Techniques
For newer teams use Affinity estimation to further confirm that estimation is agreed by team.
Sprint Planning
Scrum Team at work
Scrum Board aligns to agreed States WIP added and managed effectively
Team also started recording some parameters to record cycle time on board and box scope to capture rework
Lean is used for some matured team for wastage reduction and Cycle Time improvement from Concept to Cash
Scrum Board with Visualization and Story Card
Using different color cards to log impediment on the Scrum board Team members sticks them on the board (with start time) as and
when they are impeded and also discuss in DSM From there is captured by Scrum Master in Impediment Log
Impediment Tracking
Stage-wise lead time for each stories Or Lead time for each stage It will help us to understand bottle necks in Flow and able to find
out which story, stages and/or swim lane is causing maximum lead time
Cumulative Flow Diagram
Retrospective Outcome – Sail Boat Technique Windmills are acknowledged; Sails are appreciated Storm is identified as Risk – move to Impediment tracker to be
monitored ; Anchors are planned for improvements moving forward – Goes to Impediment log
To work on the Dev Ops Issues and then move them through other stages as they progress
Kanban for production support/ Dev Ops
QUESTIONS?
http://www.slideshare.net/sgreene
https://in.linkedin.com/in/saikatdas16@dsaikats
REFERENCESBooks: 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