%in Stilfontein+277-882-255-28 abortion pills for sale in Stilfontein
An approach to scaling Agile in Mid size Enterprise Application Stack/ Products
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
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?
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
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
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.
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
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…
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