This document discusses agile transformations and provides guidance on successfully implementing agile practices within an organization. It addresses the differences between agile adoption and transformation, what it means to be "agile", managing expectations, and key success practices. Barriers to transformation are outlined, along with case studies of challenges experienced and recommendations provided. The presentation concludes by discussing the paradigm shift required and outlining phases of agile adoption.

1. The
Transformation
Journey
Agile transformations look different across organizations
but they share a common goal : a desire to deliver more value.
By
Avinash Bais
&
Sahil Potdar
09 July 2016 1

2. Agenda
Adoption vs.Transformation
What Does it Mean to be “Agile”?
ExpectationVs. Reality
Success Practices
Elements of Development “Ecosystem”
What we change and what we don’t
Key barriers to agile transformation
Case - we experienced and we suggested
Adoption Phases and Baseline Story
09 July 2016 2

3. Adoption
vs.
Transformation
 Agile Adoption is about, what we do…
 practices,
 tools,
 ceremonies etc.
 AgileTransformation is about, who we are…
 it reflects in the organization structure and
 culture, and
 impacts the people.
For long term success, BothTransformation and
Adoption are essential.
09 July 2016 3

4. What Does it
Mean to be
“Agile”?
BeingAgile means taking a disciplined approach to
decision making in order to make the best possible
decisions with the information known at the time.
Being “Agile” simply means
Reacting quickly to every little issue that arises, right?
09 July 2016 4

5. Expectation
vs
Reality
09 July 2016 5

6. Success
Practices
Project
Management
Business / Product
Management
Team
Practices
Technical
Practices
ProjectVision Customer
Representative in
theTeam
Standup meetings Pair Programming
Stakeholder Roles Agile Requirement
Analysis
Iteration / Sprint
Planning
Collective code
Ownership
Project & Release
Management
Requirement
Definition
Cross functional
Team
Test Driven
Development
Information
Radiator
Requirement
Prioritization
Collaborative
workshops
AutomatedTesting
Project
Management
Deliverables
Minimum sub-set
of Requirements
Team Deliveries Continuous
Integration and
Build
Team Retrospective SimpleArchitecture
and Design
Team Rewards Refactoring
09 July 2016 6

7. Elements
of
Development
“Ecosystem”
09 July 2016 7

8. What we
change ?
What we
don’t change ?
Organization Structure
Roles and Responsibilities Process
Tools
Mindset Values
BeliefCustoms Behavior
Traditions
09 July 2016 8

9. Key barriers
to
agile
transformation
 Requires role changes
 Requires structural
changes
 Requires cultural shift
 Requires governance
changes
 Human resource
policies
 Complex product
organizations
 Uneven portfolio
investment
 Project based
organizations
 Local optimization
 Practices over
principles
 Need for certainty
 Value vs. Valuable
 Neglecting distributed
teams
 Forgetting to celebrate
successes
An experienced Agile Practitioner can help an organization avoid missteps09 July 2016 9

10. Case 1-
We
experienced
 Horizontal and Vertical
reporting structure.
 Frequent change
 Priority
 Scope
 Resource
 Allocating Sprint and non
sprint work leading to
delay in delivery
 No communication on
Plans (Release, major
milestones, etc)
 Different practices within
project
 Release time = Hardening
timeline
 No Ownership of
responsibilities
 Not Reviewing the
learning.
 No Grooming
 Overall No Transparency
 Half Yearly Release
 Progress Tracking on AC’s
not on Stories
 My work and Your work
09 July 2016 10

11. Case 1-
We
suggested
 Try to work with Co-
located team
 Avoid movement of
Resources
 Bring Transparency in
planes
 Trust team about work
 Communicate all stuff
 Mindset shift
 Reporting structure shift
 From Component level
estimation to velocity
 All document first to
evolving requirement
 No Ac tracking, story
tracking
 Size Stories Properly
 Remove some fields from
JIRA (Todo-progress-done)
 Estimate the work
09 July 2016 11

12. Case 2 –
We
Experienced
 No BA deliverables, including User Stories or
Acceptance Criteria, leading to Scope Creep
 No Sprint plans or Release Plan
 No requirements traceability or prioritization, only
high level Use Cases
 No defined Product Backlog
 No Scrum ceremonies/events
09 July 2016 12

13. Case 2 –We
Suggested
Scrum Master role introduced,
defined Release scope and
iteration plan for one team
Introduced Scrum ceremonies
(daily standups), and artifacts
(Jira for sprint planning and
Burndown metrics)
Provided walkthrough to
stakeholders for Agile concepts
and Jira
Started using
Jira for Product
backlog, sprint
backlog,
grooming.
Introduced
Acceptance
Criteria
Challenges:
1. Team structure – multiple applications,
smaller teams, no L3, Config managers.
Cross-functionality is not achieved.
2. UX and SIT are separate teams, so Pipeline
Iteration structure suggested. ((BA 
Dev+CIT  SIT)
09 July 2016 13

14. ParadigmShift
Tries to be predictable
FixesTime, Price and Scope
Measures Project Success by
conformance to the plan
Values methodology and
processes more than people
Resists requirements and
development process changes
Considers system specification
as the generated
documentation
Accepts that complete
predictability is impossible to
achieve
FixesTime, Price but not Scope
Success is measured by the
Value to customer
Values people more than
process, hence accepts process
rather than imposing one
Adapts to requirements and
development process changes
Considers system specification
as the developed code
The ‘Waterfall Mindset’ The ‘Ágile Mindset’
Agile
Transformation
09 July 2016 14

15. Adoption Phases
Start Small And / Or
Simple
AgileEnterprise
over Time
Non-Agile Enterprise Exploration Process Definition Strategic Alignment Transformation
Baseline story is
09 July 2016 15

16. 09 July 2016 16
And That’s
how we have
Started…