Scaling Agile Scaling Agile

across a Portfolioacross a Portfolio

An experiential journey … continues

Venkatraman L

Agile – Pretty Simple :-)

Agenda

• Overview of the Organization and Teams• Experiments & Experiments ! • Scaling Agile • Recommendations

Organization Overview

Yes, teams were not cross-functional

Project, Program & Portfolio

Portfolio > Programs > Feature Releases

Executive Expectations

• Need Predictability into releases • Build credibility with business teams • Provide visibility into what’s happening• Manage the dependencies

With the challenges

• Sorry, no pilot projects • Ok, who all do we need in this release ? #search• I made this change long back. Aren’t you aware ? • Well, this is overall priority but that’s MY team's priority• I have clarity on my team’s work – not sure about when this is

being done in other teams – Do you know? #depth vs breadth• The requirement is not yet FROZEN #agile?• Oh Agile ? Too many meetings ! • I just merged this to trunk, you want me to rollback ? #rework

Meta Issues

• No firmed up prioritization criteria• Changing technical contracts b/w teams once finalized• Technical Infrastructure (build, automation) • C O M M U N I C A T I O N within and beyond• Goal of the organization Vs goal of the team• Missing the big picture • Visibility ** (Too much and too little)• Lack of simple process to tie the entire puzzle together

Common Queries

• What’s the VALUE of doing this Vs that ? • We are just fine. Why Agile ? • I am a developer, I am not sure of when this will be hit

production – Maybe Ops will know • Why is this Team A burndown better than Team B?

Foremost: Gap Identification

1. Inter-team dependencies

2. Intra-team dependencies

3. Visibility at all levels (Executive, Senior Leadership,

Marketing, Sprint Teams)

4. “Plan of Record” – One single place for information

5. Agile Scrum training & gradual adoption across the

teams ( focused on critical few )

Approach 1 - Virtual Teams

Approach 2 - “Stack Sprints”

Finally, Virtual + Sprints + Release Standups

Push & Pull (Scrum-Ban)

Push

1. Backlog gets pushed to the teams during release breakup

2. Teams pop the requirements off the backlog as and when they plan

Pull

1. Kanban used during sprint execution to notify the status of the

requirements (Development Complete, Code Review, Ready for

QA, Ready for Deployment etc)

So, what did scale ?

• Duration : Q4 2011 through Q4 2013 • Team members increased from 60 to 200 • Teams increased from 6 - 14 • #PM team increased from 4 - 10 • Consequently, # Releases increased from 15 > 45 > 80+

The good news is that the framework seamlessly scaled to accommodate the growth in teams and the #releases

Current Focus

• Value driven prioritization • Capacity Visibility and Planning using APLM Tools• Aligned teams to business units (for greater focus) • Continuously improve engineering practices • Adopt ScrumBan across the entire organization• Predictability throug 6-sprint planning • Ease of APLM Tool Usage **

6-Sprint Look-ahead PlanningTeam A

Team B Team N

Sprint 1Release 1

Release 2 Release 2 Release 2

Sprint 2Release 1 Release 1

Release 3

:Sprint 6

Release 3 Release 3

Recommendations

** Sponsor / Exec Support **

• Get the buy-in, consistently

• Solve the right problems than what you think they are

• Be open to feedback and criticisms

Have an open mind to “experiment”

• Mix it up ! • Choose the best of

what works for you • Adapt, Revise and

Re-implement in faster cycles

• Make it happen !

Intensely Focus on Architecture and Design

• Agile does not talk about ignoring it

• Design activities can start few sprints ahead

• Spike ! • Influence the backlog• Plan (for) the future !

Break the Wall of Confusion – ** Embrace DevOps **

Source:http://dev2ops.org/2010/02/what-is-devops/

• Work as a team than in Silos for faster deployments

• Unified Vision and Individual Goals

• Break the “my territory” rule

• Shift Left

Collaborate (effectively)

• Be active than a passive contributor

• Effective Retrospectives

• Focused Release & Sprint Planning

• Focus on problems than people

Quality is Prime

• Definition of Done (@ all levels)

• Shift Left • Test Driven

Development• Unit Tests • Acceptance Tests • Automation • …..

Measure

• Keep it simple• Measure only what

you can manage • Automate the

metric capture • Manage them well

Pick what you can manage from..Technical Operational Business

Project Test CoverageEscaped

Defects In Sprint

Defects Cost of

reworkCode Quality PerformanceDefect

ingestion

Story point velocity Available capacity Capacity utilization Cost of the sprint($)Story points accepted / not

acceptedNew scope added Technical DebtStretch factorTime spent on Bugs vs

feature Risk Register Updates

Business Value delivered

Customer Satisfaction

Program Cycle Time Process cycle efficiency (%)Release Burn up Scope creep

Contractual metrics ($)

Portfolio Pie-chart of releases Health of the portfolioPrioritization changes

ROI in the portfolio Contribution Margin

Keep them visible !

• Information Radiators • Its all about

transparency• Out of sight is out of

mind !

Agile != Scrum • Embrace XP, Lean Kanban, FDD ….

Source: Version One Survey, 7th Annual State of Agile

Source: Version One Survey, 7th Annual State of Agile

And the surveys too confirm

In Summary,

• @ Engineers – your problems are largely technical, focus and solve for them ! • Using the guiding Agile Manifesto & Principles • Using the Agile Planning & Estimating Techniques

• @ Line Managers / Scrum Masters – Remove impediments every single day (if not hourly) • Look ahead planning

• @ Management – Aid Value Driven Prioritization and insulate the @ Engineers from being randomized

B E G I N N O W

Source: Google Images

Thank you !

http://about.me/venkatramanL