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