Kumar Rajasekaran presented learnings from scaled agile implementations. Key topics included transitioning from a business process to an execution process, implementing a release train with focus on tools, metrics, user experience, agile coaching, trainings and workshops, and conducting agility assessments from team to program level. Challenges included priority/scope change management, sprint cycle duration, acceptance criteria, dependencies, capacity planning and standardization. Opportunities included delivering working software, aligning delivery to business value, and improving test practices.

1.  Kumar Rajasekaran- Agile Coach
Learnings from Scaled
Agile Implementation

2. Disclaimer: The information shared
in the presentation here is derived
from the experience of coaching
Agile teams and learnings from
participation in Agile Forums. They
are not attributable to any
Organization in particular
2

3. Scaled Agile Implementation
Scaled Agile Implementation
ASK
Business Process to Execution Process
Release Train Implementation: Key Focus Areas
Tools
Metrics
User Experience
Agile Coaching
Agile Trainings and Workshops
Agility Assessments
3

4. 4
4
• Any priority changes within the sprint
has impact on PI planning and needs to
be avoided.
• Revisit Sprint cycles for Agile projects
• Teams bringing in more work than their
established velocity
• Revisit Sprint cycles for Agile projects –
Time not reserved for support activities
• Not enough non-story capacity planned
• Acceptance Criteria is not clearly
documented
• Sprint Backlog contains only user stories
and no enabler stories
• Dependencies involved during
development is a key challenge
• Defects introduced/Story point, Sizing of
story points, Team velocity and
ceremonies needs to be standardized.
• Individual SCRUM teams are loaded
beyond 100% to meet release deadlines.
• Improvement stories from Retrospectives
are not added into the backlog
• Sprint objectives are modified unilaterally
without considering impact
• Scope change within a release is an UDO
• Demo is mainly discussion oriented/slides
instead of actual work
• Business Value Delivery Framework – not
defined by features - Value point system
required for feature prioritization.
• Features not adequately decomposed into
Stories
• User Voice is not used for Product Ready
Story description
• Improvement stories from Retrospectives
are not added into the backlog
• Test tasks are not scheduled for the sprint
• Time for testing is shortened due to
development delay
• Tests do not cover DoD
• Testers do not participate on planning /
refinement
• Testing is not documented
• No focus on test case automation
• Regression tests are not started early in the
development phase
• Critical/High defects are open for long
duration
• Teams using only the Qualitative metrics
and not the Quantitative Metrics in
Retrospectives
• Teams always view metrics as needed for
Management Review
A g i l e I m p l e m e n t a t i o n O b s e r v a t i o n s
Priority /scope change
management, Sprint Cycle
duration, Acceptance criteria,
Dependency, Capacity planning,
Resource Loading,
Standardization, Story sizing &
Decomposition, Test Practices,
Product Working software demo,
Delivery aligned to Business Value.
O p p o r t u n i t i e s

5. 5R e l e a s e C a d e n c e
Business expectation for continuous
Delivery especially for regulated
environments, Shared resources in
Agile teams in Multiple projects, Ideal
team size , Hierarchy in scrum teams,
Cadence for ceremonies, Team
Participation& Standardization of
release cadence
#02
 Cadence for ceremonies not followed
 Demo is mainly discussion oriented/slides
instead of actual work
 No focus on test automation.
 CI/CD practices are not adopted (not added to
backlog)
 Cadence – Need similar cadence for all Org ,
Same release dates for all projects.
 Regularity and Standardization of release
cadence is a Key priority.
 We do not have continuous Deployment as a
practice since our user bases are very special
groups of people E.g Pilots.
 Agile project milestones are not tied to
Marketing milestones.
 Marketing not on board with Agile process
– Lack of adoption, not completely
understanding Agile.
 Cross functional teams look at Agile only as
a Development methodology- not an over
encompassing mindset change.
 CI is ok but CD may not be applicable –
Industry not looking for changes
frequently
 Business not prepared for frequent
releases.
 Customer expectation for releases may
have variation.
 Revisit Sprint cycles for Agile projects –
Lyric dashboard Vs fusion scenario.
 Regulatory or compliance requirement is
a challenge for frequent releases. - E.g.
Industrial fire & Gas – a Small change
requires certification.
 Doing a sprint is ok however release in 2
weeks may not be practical in all
scenarios
B u s i n e s s A g i l i t y
 Team members are always having multiple
projects ensuring instability in Scrum teams
 Scrum Master does all the synchronization
 Team gets no inputs from Scrum of Scrums
 Team not adequately engaged during Story
refinement
 SCRUM team are too small 3 members (at
least 5 is recommended)
 Too many scrum team in a release train,
sometimes, release train has as many as 160+
team members (recommended 125 to 150)
 Need to have vertical reporting based on
expertise – Firm line for all professionals to
the respective verticals. E.g. Dev ops
professionals can report to their respective
leads at a Global level.
 A SCRUM team should be formed by pulling
resources or professionals from a Global pull
of resources based on expertise. This will
enable a self-directed team drive Team
dynamics & right behaviors
 No hierarchy in SCRUM teams.
 Team not adequately engaged during Story
refinement
T e a m S t r u c t u r e
O p p o r t u n i t i e s

6. Context :: Agile Maturity 6
Agility in Business, Product
& Offerings is a key driver
 Ensure Continuous
reduction in time to
market
 Changing customer
needs are factored into
Products/ Offerings
 Foster Collaborations
Background
Drive Agile as one of the
Top 3 Initiatives
 Enable Business Process
Engine
 Reduction in Cycle Time
 Address Market Needs
 Sustain & Surpass our
Market Edge
The ASK Scope of Work
Understand Current state
and derive focused actions
for ideal future state
 Leverage existing maturity
management practices
 Drive a consistent, scalable
practices rigor using a
Defined Framework
 Sustain & Continuously
Improve

7. Business Process to Execution Process
7

8. Business Process to Execution Process 8
Customer
Scope
Concept
Validation
Definition Development Validation Launch
Execution
Process
Goals
•Define a Execution Process and Team
•Define & Adhere to Quality Criteria
•Maintain a Prioritized Backlog that directs All Work
•Plan and Develop on Cadence
•Continuously Inspect and Adapt Deliverables
•Continuously Inspect and Adapt the Process
•Define a Measurement and Analysis Plan
•Continuously Integrate and Deliver Working Software
•Define Configuration and Change Management Practices

9. Business Process to Execution Process 9
Customer
Scope
Concept
Validation
Definition Development Validation Launch
Execution Process

10. Release Train Implementation:
Key Focus Areas
10

11. Tools 11
Customer
Scope
Concept
Validation
Definition Development Validation Launch
Execution
Process

12. Metrics 12
Customer
Scope
Concept
Validation
Definition Development Validation Launch
Execution
Process
Measurement
Standard
Team Level
Program Level
Portfolio Level
DOR
Standard
Standard
s
Coding
Standards
DOD
Standard
Team Level
Program Level
System Increment Level
Defect
Classification
Standard

13. Metrics 13
Customer
Scope
Concept
Validation
Definition Development Validation Launch
Execution
Process
Program
Level
System
Increment
Level
Measuremen
t Standard
Team
Level

14. User Experience 14
Customer
Scope
Concept
Validation
Definition Development Validation Launch
THEMES
(outcomes)
EXPERIENCE
OUTCOMES (XO’S)
“What customer problems are we
solving and how high is the bar”
UXRL1-3
DESIGN INTENT
“How are we going to solve –
what is the design vision”
UXRL4-6
DESIGN DETAIL
“What will developers build in
the next sprint”
INITIATIVES
(design intent
which may span multiple PI’s)
EPICS
(manageable chunks of
software)
STORIES
(collection of functionality we
can build in a sprint)
SOFTWARE
PACKAGE
“ the developed solution”
EVALUATION
“Does the developed
solution match the
design ”
VISION
(business value)
USER
RESEARCH OVOC
“What problems exist”
DESIGN EPICS
“Manageable chunk of
design scope that delivers
end-to-end value”
UEWORKSTREAM
DEVELOPMENT
WORKSTREAM
PROGRAM
INCREMENT (PI)
SPRINT
RELEASE

15. Agile Coaching 15
Customer
Scope
Concept
Validation
Definition Development Validation Launch
Time Scale 9 – 12 months
Assess
Train and Coach teams in agile practices
Identify Champion
Coach the Champion
Coach Exit
(Consult)
Deliverables
• Scrum adoption with month-on-month
Agility assessment scores
• Training and coaching support
• Build internal champion for self-sustenance
Dependency
• “Agile” Managers – Dev Lead support
• SBU & Management support
• Tooling support
• Learning & Development agile training
Tooling Standardization
Ad-hoc Agile Doing Agile Being AgileTeam State
Execution
Process

16. Agile Trainings & Workshops
Industry Thought leaders led workshops for Leaders
Leading SAFe Certification trainings by certified SPCs for Program Stakeholders
Scrum and RT Fundamental 2 day Trainings
Workshops for Agile transformation
Value Stream Identification workshops
Skype Trainings
Recorded Webinars
Access to Learning Hubs
16

17. Agility Assessments- Team Level to Program
Level
17
Program Agility
Assessments

18. Questions?
18
Contact: Kumar.Rajasekaran@gmail.com