The PPT is about scaling agile across various non-cross-functional teams and the various experiments that were done before arriving at a methodology that worked for the teams.

1. Venkatraman L

2. Agile – Pretty Simple :-)

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

4. Organization Overview
Yes, teams were not cross-functional

5. Project, Program & Portfolio
Portfolio > Programs > Feature Releases

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

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

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

9. 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?

10. 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 )

11. Approach 1 - Virtual Teams

12. Approach 2 - “Stack Sprints”

13. Finally, Virtual + Sprints + Release Standups

14. 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)

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

16. 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 **

17. 6-Sprint Look-ahead Planning
Team A
Sprint 1
Team B
Team N
Release 1
Release 2
Release 2
Release 2
Release 1
Sprint 2
:
Sprint 6
Release 3
Release 3
Release 1
Release 3

18. Recommendations

19. ** Sponsor / Exec Support **
•
•
•
Get the buy-in,
consistently
Solve the right
problems than
what you think
they are
Be open to
feedback and
criticisms

20. 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 !

21. 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 !

22. Break the Wall of Confusion –
** Embrace DevOps **
• Work as a team than
in Silos for faster
deployments
• Unified Vision and
Individual Goals
• Break the “my
territory” rule
• Shift Left
Source:http://dev2ops.org/2010/02/what-is-devops/

23. Collaborate (effectively)
• Be active than a
passive contributor
• Effective
Retrospectives
• Focused Release &
Sprint Planning
• Focus on problems
than people

24. Quality is Prime
•
•
•
•
•
•
•
Definition of Done
(@ all levels)
Shift Left
Test Driven
Development
Unit Tests
Acceptance Tests
Automation
…..

25. Measure
• Keep it simple
• Measure only what
you can manage
• Automate the
metric capture
• Manage them well

26. Pick what you can manage from..
Technical
Operational
Business
Test Coverage
Escaped Defects
In Sprint Defects
Cost of rework
Code Quality
Performance
Defect ingestion
Story point velocity
Available capacity
Capacity utilization
Cost of the sprint($)
Story points accepted / not
accepted
New scope added
Technical Debt
Stretch factor
Time 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 portfolio
Prioritization changes
ROI in the portfolio
Contribution Margin
Project

27. Keep them visible !
•
•
•
Information Radiators
Its all about
transparency
Out of sight is out of
mind !

28. Agile != Scrum
• Embrace XP, Lean Kanban, FDD ….
Source: Version One Survey, 7th Annual State of Agile

29. And the surveys too confirm
Source: Version One Survey, 7th Annual State of Agile

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

31. BEGIN
W
NO
Source: Google Images

32. Thank you !
http://about.me/venkatramanL