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