an agile journey

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 April 2015

Prakash Bettadapur [email protected]

© 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 Composition

•  Team Empowerment

•  Lean Thinking

•  Frequent Retrospection

•  Quick learning from failures

Areas requiring attention:

•  Product Quality •  Partner & Customer

Collaboration •  Team Composition •  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:







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

FAQWho 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 BoardTools

Process

Shippable

Product

Sprint Review

Sprint

Daily

Scrum

Sprint

BacklogProduct

Backlog

Sprint

PlanningSprint

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 TermsTime 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-1

2

Aug

-12

Sep

-12

Oct

-12

Nov

-12

Dec

-12

Jan-

13

Feb-

13

Mar

-13

Apr

-13

May

-13

Jun-

13

Jul-1

3

Aug

-13

Sep

-13

Oct

-13

Nov

-13

Dec

-13

Jan-

14

Feb-

14

Mar

-14

Apr

-14

May

-14

Jun-

14

Jul-1

4

Aug

-14

Sep

-14

Oct

-14

Nov

-14

Use

r S

tori

es

Axis Title

117

207

329

184

344

1.10

1.11

, 1.1

1.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

Agi

le A

dopt

ion

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

Thank you.

an agile journey

Documents

cisco andor

cisco confidential

scattered team

technology portfolio

agile transformation

agile practices

agile introduction

agile helps