Agile Transformation Journey at Cisco

Cisco Confidential© 2013 Cisco and/or its affiliates. All rights reserved. 1
CSTG One Team. One Technology Portfolio. Built to Scale
A Program Journey to Agile Transformation
April2015
Prakash Bettadapur
pbettada@gmail.com

© 2013 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 2
•  Agile Introduction – Why Agile
!  Software Success and Failures
!  Program State before Transformation
!  How Agile Helps
!  How Agile is different from other SDLC methodologies
!  Principles and Values
!  What are the different Agile methods
!  What are the Agile Practices and Ceremonies
•  Workshop – Discuss Scenarios
•  Agile Journey
!  Initial Program State
!  Overview of the Journey
!  Significant Progress Phases

Success Challenged Impaired
Requirements/Users/Delivery Related 29% 37% 34%
Planning/Tracking Related 26% -- 15%
Executive/Stakeholder Support, Clarity Related 17% 24% 27%
Staffing (Technology, People) Related 15% 17% 15%
Misc/Other 13% 22% 9%
•  Traditional Projects Success and Failure factors
•  Grouped under broad categories
•  Based on CHAOS report
•  Results from 2004 - 2014

•  High number of customer problems
•  Partners and Customers discontent and disengaged
•  Work halted for several releases and resources diverted for other
programs
•  Large parts of BU funded by the program
•  Large distributed and scattered team
•  Many team members with dysfunctional attitudes on what they can
do for the project
•  Dysfunctional dev/QA relationship
•  Outdated infrastructure and architecture
•  3rd party vendor’s hardware/software/team members not integrated
with the rest
•  Development Partner (IT) team members not integrated with the rest
•  Too many meetings with too many stakeholders, everyone trying to
project manage from different perspectives
•  One excellent Product Manager handling most of the requests
Areas requiring
attention:
•  Product Quality
•  Partner & Customer
Collaboration
•  Team Composition
•  Team Dynamics
•  Outdated Architecture
•  Wasteful Activities

•  Encourage close Customer Collaboration
•  Address Customer needs timely manner
•  Build quality into the product upfront
•  Team Empowerment
•  Lean Thinking
•  Frequent Retrospection
•  Quick learning from failures
Areas requiring
attention:
•  Product Quality
•  Partner & Customer
Collaboration
•  Team Dynamics
•  Outdated Architecture
•  Wasteful Activities
Let$us$take$a$close$look$at$how$Agile$accommodates$these$aspects…$

•  Frequent Customer Deliveries
!  Early Value Delivery
!  Continuous Value Delivery
!  Highest Value Delivery
•  Managing Business Outcome
!  Promote close customer collaboration
!  Determine technical feasibility
!  Test market readiness
!  Leverage early revenue opportunities
!  Avert losing market opportunity
!  Salvage partly finished product
!  Enable roadmap reshuffle
Blog References:
https://www.linkedin.com/today/author/611516

!  Architecture dependencies
!  UE/UX dependencies
!  Inter-components dependencies
!  Inter-teams dependencies
!  Simplicity and Agility
Blog References:
https://www.linkedin.com/pulse/critical-software-success-factors-managing-prakash-bettadapur?trk=mp-reader-card

Blog References:

!  Adequate, just enough planning
!  Continuous
!  Daily
!  Iteration/Sprint
!  Release/Roadmap/Program/Project/
Product/Program Increment
!  Portfolio/Vision/Strategy
!  Agile estimation
!  Adequate risk management
!  Visibility to track projects
Blog References:

!  Continuous
!  Daily
Blog References:

•  Team Empowerment
•  Teams taking responsibility for decisions,
planning & delivery
•  Close Collaboration & Cooperation
•  Agile Leadership
•  When, what and how to delegate
•  Balance when to step-in/step-out
•  Obstacle removal
•  Coaching & Servant Leadership
•  Team Joy
•  Customer Satisfaction
•  Employee Satisfaction

Agile Values
•  Early and frequent delivery
•  Customer collaboration
•  Adaptation
•  People come first
Waterfall Values
•  Deliver on time and on budget
•  Make early commitments
•  Get it right the first time
•  Process comes first

Aspect Agile Waterfall
Commitment
and Delivery
•  Organize to reduce cost of change (not
amount of work)
•  Balance between value delivery now & future
ability
•  Deliver frequently, on cadence; scope varies,
quality important
•  Team responsible
•  Artifacts reviewed & approved; changes can
be costly
•  Scope fixed, cost & schedule varies based
on factors
•  Deliver on deadline; early commitment
matters
•  Project manager responsible
Decisions and
Adaptability
•  Effective before efficiency
•  Defer decisions to last responsible moment
•  Fail fast and cheaper; maximize learning
•  Optimize utilization
•  Make early commitment; minimize changes
•  Get it right first time; no room for failures
Tracking
progress
•  Time boxed; Deliver shippable quality
•  Continuous value delivery tracked for %
progress
•  Delivery on final deadline; review for quality
compromises
•  Progress is % completion of initial plan
Individuals •  People, respect, trust, transparency
•  Broad expertise, T-shaped skills
•  Resources, technical skills matters, experts
•  Deep expertise, specialist “resources”
Interactions •  Self-organizing teams; keep colleagues
informed
•  Teams share ownership of decisions &
results; work by consensus
•  Servant leaders in trusting, supportive
relationship
•  Hub & spoke model – manager coordinating
and organizing
•  Teams not feeling ownership; look to
manager for decisions
•  Command and control relationship

Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more Satisfy the
Customer
Welcome
Change
Deliver
Frequently
Collaborate
Daily
Support &
Trust
Motivated
Teams
Promote
Face-to-Face
Conversations
Deliver
Working
Software
Promote
Sustainable
Pace
Promote
Technical
Excellence
Maximize
Through
Simplicity
Have
Self-
Organized
Teams
Reflect &
Adjust
Regularly

•  Acceptance test-driven development
(ATDD)
•  Agile Modeling
•  Backlogs (Product and Sprint)
•  Behavior-driven development (BDD)
•  Cross-functional team
•  Continuous integration (CI)
•  Domain-driven design (DDD)
•  Information radiators (Scrum board,
Task board, Burndown chart)
•  Iterative and incremental development
(IID)
•  Pair programming
•  Planning poker
•  Refactoring
•  Scrum meetings (Sprint planning, Daily
scrum, Sprint review and retrospective)
•  Test-driven development (TDD)
•  Agile testing
•  Time-boxing
•  Use case
•  User story
•  Story-driven modeling
•  Retrospective
•  Velocity tracking
Source: Wikipidea

Artifacts
To-do list (also known as Backlog item) for the Sprint
Created by the Scrum Team
Product Owner has defined as highest priority
Sprint Backlog – (SB)
Chart showing how much work remaining in a Sprint
Calculated in hours remaining
Maintained by the Scrum Master daily
Burndown Chart – (BC)
Same as the Product Backlog. May involve one or
more sprints dependent on determined Release date
Release Backlog – (RB)
Meetings
Product backlog prepared prior to meeting
First half – Team selects items committing to complete
Additional discussion of PB occurs during actual Sprint
Sprint Planning – Day 1 / First Half
Team presents “done” code to PO and stakeholders
Functionality not “done” is not shown
Feedback generated - PB maybe reprioritized
Scrum Master sets next Sprint Review
Sprint Review
Occurs after first half done – PO available for questions
Team solely responsible for deciding how to build
Tasks created / assigned – Sprint Backlog produced
Sprint Planning – Day 1 / Second Half
Held every day during a Sprint
Lasts 15 minutes
Team members report to each other not Scrum Master
Asks 3 questions during meeting
“What have you done since last daily scrum?”
“What will you do before the next daily scrum?”
“What obstacles are impeding your work?”
Opportunity for team members to synchronize their work
Daily Scrum
Estimating
“DONE”= Potentially Shippable!
List of all desired product features
List can contain bugs, and non-functional items
Product Owner responsible for prioritizing
Items can be added by anyone at anytime
Each item should have a business value assigned
Maintained by the Product Owner
Product Backlog - (PB)
SCRUM CHEAT SHEET
Attendees – SM and Team. PO is optional
Questions – What went well and what can be improved?
SM helps team in discovery – not provide answers
Sprint Retrospective
Roles
Accountable for product success
Defines all product features
Responsible for prioritizing product features
Maintains the Product Backlog
Insures team working on highest valued features
Product Owner (PO)
Holds daily 15 minute team meeting (Daily Scrum)
Removes obstacles
Shields the team from external interference
Maintains the Sprint Burndown Chart
Conducts Sprint Retrospective at the end of a Sprint
Is a facilitator not a manager
Scrum Master (SM)
Team is cross-functional and consists of 5-9 people
There are no set project roles within the team
Team defines tasks and assignments
Team is self-organizing and self-managing
Maintains the Sprint Backlog
Conducts the Sprint Review
Scrum Team
FAQ
Who decides when a Release happens? At the end
of any given Sprint the PO can initiate a Release.
Who is responsible for managing the teams? The
teams are responsible for managing themselves.
What is the length of a task? Tasks should take no
longer than 16 hours. If longer then the task should be
broken down further.
Who manages obstacles? Primary responsibility is
on the Scrum Master. However, teams must learn to
resolve their own issues. If not able then escalated to
SM.
What are two of the biggest challenges in Scrum?
Teams not self-managing, Scrum Master
managing not leading.
White Board containing teams Sprint goals, backlog items,
tasks, tasks in progress, “DONE” items and the daily Sprint
Burndown chart.
Scrum meeting best held around task board
Visible to everyone
Task Board
Tools
Process
Shippable
Product
Sprint Review
Sprint
Daily
Scrum
Sprint
BacklogProduct
Backlog
Sprint
Planning
Sprint
Retrospective
A very high level definition of what the customer wants
the system to do.
Each story is captured as a separate item on the
Product Backlog
User stories are NOT dependent on other stories
Story Template:
“As a <User> I want <function> So that <desired result>
Story Example:
As a user, I want to print a recipe so that I can cook it.
User Stories
A simple way to initially estimate level of effort expected
to develop
Story points are a relative measure of feature difficulty
Usually scored on a scale of 1-10. 1=very easy through
10=very difficult
Example:
“Send to a Friend” Story Points = 2
“Shopping Cart” Story Points = 9
Story Points
Capacity = # Teammates (Productive Hrs x Sprint
Days)
Example – Team size is 4, Productive Hrs are 5, Sprint
length is 30 days.
Capacity = 4 (5 x30) = 600 hours
NOTE: Account for vacation time during the Sprint!
Estimate Team Capacity
Each User Story in the Product Backlog should have a
corresponding business value assigned.
Typically assign (L,M,H) Low, Medium, High
PO prioritizes Backlog items by highest value
Business Value
Glossary of Terms
Time Box - A period of time to finish a task. The end
date is set and can not be changed
Chickens – People that are not committed to the project
and are not accountable for deliverables
Pigs – People who are accountable for the project’s
success
Single Wringable Neck – This is the Product Owner!
The rate at which team converts items to “DONE” in a
single Sprint – Usually calculated in Story Points.
Velocity
Visibility + Flexibility = Scrum
From www.rgfgroup.com

•  Eliminate waste
•  Deliver fast
•  Defer commitment
•  Create knowledge
•  Build quality in
•  Respect the team
•  Optimize the whole
•  Partially done work
•  Extra features
•  Relearning
•  Handoffs
•  Task switching
•  Delays
•  Defects
How$did$we$apply$all$these$values$and$principles$in$our$journey?$

•  Discuss at your tables the assigned scenarios and report back to the team
•  20 minutes

•  High number of customer problems
•  Partners and Customers discontent and disengaged
•  Work halted for several releases and resources diverted for other programs
•  Large distributed and scattered team
•  Many team members with dysfunctional attitudes on what they can do for the project
•  Dysfunctional dev/QA relationship
•  Outdated infrastructure and architecture
•  3rd party vendor’s hardware/software/team members not integrated with the rest
•  Development Partner (IT) team members not integrated with the rest
•  Too many meetings with too many stakeholders, everyone trying to project manage from
different perspectives
•  One excellent Product Manager handling most of the requests
Let$us$look$at$the$summary$of$the$transforma=on$and$then$details$in$each$phase…$

$30M
$60M
$90M
0
50
100
150
200
250
300
350
400
May-12
Jun-12
Jul-12
Aug-12
Sep-12
Oct-12
Nov-12
Dec-12
Jan-13
Feb-13
Mar-13
Apr-13
May-13
Jun-13
Jul-13
Aug-13
Sep-13
Oct-13
Nov-13
Dec-13
Jan-14
Feb-14
Mar-14
Apr-14
May-14
Jun-14
Jul-14
Aug-14
Sep-14
Oct-14
Nov-14
UserStories
Axis Title
117
207
329
184
344
1.10
1.11,1.11.x
1.12
1.12.x,1.13
1.13.x,1.14
$31.5M
FY12
$49.5M
FY13
$88.1M
FY14
Business
Engineering User Stories
AgileAdoption
Content Quantity Delivery Improvement over 2.5 years since starting Agile: 3 times
Productivity Improvement considering funding reduction from $1.9 M to $600K:10 times
What contributed to the success of Agile and contribution to Productivity?
1950K/Qtr
1250K/Qtr
950K/Qtr
600K/Qtr
Let$us$review$what$principles$and$values$got$applied$in$which$phase…$

•  Team Structure & Collocation
•  Establish well defined, collocated teams
•  Right sized, right membership, good mix of junior &
senior developers
•  Insist on collocated dev and QA members; emphasize
the need for more permanent QA members
•  Filling Essential roles
•  Identify scrum masters for each team and appropriate
scaling
•  Identify product owners from engineering team to scale
product management bandwidth
•  Training
•  Train teams in effective scrum techniques and also
strategies for release planning
•  Seed trained/experienced team members into other
teams

•  Budget waste
Identify areas where money spent, not contributing to
program
Re-assign members to other projects in budget
spreadsheet – those who were not part of this program
•  Non-contributing team members
Allow them to go to different teams/programs or out of
CSTG/Cisco
•  Grow team in India as they took on more responsibilities
•  Process waste
Too many meetings requiring too many participants
Cut down must meetings to 2 per week
Reduce time spent in wasteful discussions on imaginary
scenarios and risks

•  Retrospectives after 1st agile release completed
•  Dev/QA handoff issues
Strict handoff needs
Named/dated/fixed builds
No participation in standups
Documentation needs
•  Release needs
Regression test suites
Identifying need for test automation
•  Troubled Deployments

•  Attended Partner Summit; visited partners for feedback
•  Teams taking more responsibilities & risks
Some team members removed
Architectural & Infrastructural Enhancements (LCM, CCIX)
Major performance enhancements
•  Teaming with 3rd Party framework vendor
Major performance enhancements from vendor also
Responsibly handling failure scenarios; part of Cisco team
•  Collaboration with Partners and BDMs
“Product is on Steroids” feedback
•  DevOps – CI/CD implemented
Test Automation engineers hired
•  Process Enhancements
Release Planning
Develop on Cadence; Release on Demand
CSDM/SSDM

•  Drastic reduction in budget due to macro factors in BU
•  Loss of many key members; Reduction in output
capacity
•  Great partnership with Product Management to
reevaluate and reprioritize deliverables
Careful analysis – implementing customer high value
features
Minimum Viable Product delivered
Others delayed for future releases

•  Low investment continues
•  Engineering executives not in sync with business
priorities
•  IT Development Partner loses all resources; all their
work falls on our engineering teams
•  As we complete 80% of our roadmap, our team takes
up rest of IT roadmap and delivers them too
•  A well oiled lean engineering team delivers
significantly higher output
Due to motivation & confidence within the team
Fantastic teaming with Product Mgmt & IT development
Partner groups
One month extension in release deadline helped get
more into the release

•  Biggest success factor – great partnership with Product
Management team
•  Right team structure and collocation considerations
•  Dedicated team members – people, not resources
•  Management 3.0 – Servant Leadership

Agile Transformation Journey at Cisco

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Agile Transformation Journey at Cisco

Similar a Agile Transformation Journey at Cisco (20)

Agile Transformation Journey at Cisco