Scaling Agile has been the topic of conversation for years, has been achieved for years as well yet rarely documented and socialized. In 2009, while leading an Agile transformation in the parent company at the same time standing up new Scrum teams in their startup subsidiary Ben realized that Scrum should or at least would in his case be the foundational framework for scaling Agile. Keeping it simple with a collection of small, manageable, functional teams vertically sliced into portfolios, programs and projects to help mitigate the risk of loosing site of the goals and/or objectives of the organization while keeping true to the Agile principals Ben will show you how he and his team scaled Agile multiple times throughout multiple enterprise international organizations, using Scrum as the foundational framework complimented with Lean, Deming, XP and Kanban. Something important to know is you must use TDD and/or BDD with a continuous integration environment as well as feature/code prefixes and vertical slicing.

1. How to scale Agile
With Scrum as the Foundational Framework
September 21, 2013
Ben Clay
Benjamin.clay@yoh.com
Director of Agile Practice
Agile Coach
© 2013 PracticalScrum. All Rights Reserved
PRACTICAL AGILE

2. © 2013 PracticalScrum. All Rights Reserved
What Practical Agile is
NPV ROI
BEPTCO

3. © 2013 PracticalScrum. All Rights Reserved
What Practical Agile is NOT

4. © 2013 PracticalScrum. All Rights Reserved
Seven (7) Planning Layers of Practical Agile
Program
Product Vision
(Project)
Product
Roadmap
Product Release
Portfolio
Sprint/Iteration
Daily
The Chief Product
Officer/Owner works with
other key stakeholders
and/or leadership to
identify/define/plan near
and far term strategic
goals and/or objectives
Product Owners work
with business leadership
to create the product
vision aligning business
needs
The product team defines
the upcoming release and
plans it with the team
The Team manages work
daily
Product Owners work with
the business leadership to
create the vision to meet
business needs; Product
Owners outline the
roadmap for the product
team to complete
Team plans and executes
the current Sprint/Iteration
Lead Product Owners work
with business leadership to
plan near term project
goals and/or objectives

5. © 2013 PracticalScrum. All Rights Reserved
High Level Portfolio Roadmap
Q2
In progress
Q3
Planned
Q4
Anticipated
Q1
Anticipated
• DB as a Service
• Health Information
Exchange as a Service
September
July
• Infrastructure as a Service
August November
• Client Side PACS System
December
• Mobile Prescription Writing
October
• PCI Compliance in the Cloud
January
February
March
• Card Linked to Offer
• Proximity Purchase
• Agile Portfolio Tool
May
• Centralized Access
Control as a Service
June
• Monitoring as a Service

6. © 2013 PracticalScrum. All Rights Reserved
Product Vision Description Sample Template
What is needed? Why do we need it? Who is it for?
For all ____________________ who ________________________________,
our product __________________ is ________________________, providing
_________________________________________________________________
____. Unlike _____________________________, our ____________________
_________________________.

7. © 2013 PracticalScrum. All Rights Reserved
Release Schedule Sample Template

8. © 2013 PracticalScrum. All Rights Reserved
Practical Agile Portfolio

9. © 2013 PracticalScrum. All Rights Reserved
Practical Agile Portfolio Team

10. © 2013 PracticalScrum. All Rights Reserved
Practical Agile Program

11. © 2013 PracticalScrum. All Rights Reserved
Resource Backlog Example

12. © 2013 PracticalScrum. All Rights Reserved
Resource Budget Example

13. © 2013 PracticalScrum. All Rights Reserved
Budget Burndown Example
15
10
9
8
7
5
4
3
2
1
0
6
30
25
20
Q1 Q2 Q3 Q4 Q1 Q2
Quarter
Dollars Spent Budgeted
DollarsinMillions
Q3 Q4 Q1 Q2

14. © 2013 PracticalScrum. All Rights Reserved
NPV, ROI, BEP

15. © 2013 PracticalScrum. All Rights Reserved
Practical Agile Program Team

16. © 2013 PracticalScrum. All Rights Reserved
Practical Agile Project Team

17. © 2013 PracticalScrum. All Rights Reserved
BONUS: Important Topics for Practically
Scaling Agile

18. © 2013 PracticalScrum. All Rights Reserved
BONUS: Vertical Slicing Slides

19. © 2013 PracticalScrum. All Rights Reserved
The Layers of a Vertical Slice
UX/UI
Service
Data
Additional Top Layer
Additional Middle Layer
Additional Bottom Layer

20. © 2013 PracticalScrum. All Rights Reserved
Vertical User Story
LOGIN
Email
Password
remember me
Forgot Password
As a <USER ROLES>, I must be able to login to my company portal so that I can
perform the functions of my job.
Acceptance Criteria
• Verify that I can log into
the system
• Verify that my login
credentials will be
remembered
• Verify that I can reset my
own password by clicking
the "Forgot Password"
link
• Verify that I cannot
navigate back to the
landing page without first
logging in

21. © 2013 PracticalScrum. All Rights Reserved
The Layers of Login
UX/UI
Service
Data
Vertical
To vertically develop all slices encapsulated therein, they must be accounted for.

22. © 2013 PracticalScrum. All Rights Reserved
Dissected by Layer
The developers will need to know what files they will have to create and/or extend.
bootstrap class
session class
UX/UI
Service
Data
index.jsp
CSS
constance class / config file
user bean
database class / ORM
database
function class
template class
login service
login.jsp
landing.jsp
JavaScript

23. © 2013 PracticalScrum. All Rights Reserved
BONUS: Vertical User Story Template Slides

24. © 2013 PracticalScrum. All Rights Reserved
Product Backlog Grooming
Prioritized from 1 - whatever (Example 1 - 500)
• Prioritize each stack ranked list
• From most business value to least business value offered
• Not everything is a MUST HAVE, if you it doesn’t meet one of the listed MUST HAVE’s above then it
isn’t a MUST HAVE
• Use this as a guide, a place to start and create your own
Must have
• Patient safety
• Legal concerns
• Regulatory mandates
• Core functionality
• Minimal marketable
features
Should have
• Increase productivity
• Could have more on this
list based on your
business type
Would like to have
• Fluff
• Not something that is
needed, but enhances
end user experience

25. © 2013 PracticalScrum. All Rights Reserved
Definition of Ready For Vertical User Stories
Vertical User Story
Confir
m
e d pr ior ity
All dependencies have been provided (API’s, server access and the like)
Impacts to existing business process (Example: Changes to the way some-
one logs in)
Scenarios
Acceptance criteria has been identifie
d
Wireframes, designs, copy content provided (Anything you need to com-
plete a story in the sprint/iteration)
Defin
e
d and agr eed upon busi ness rul es
NOTE: the checklist
is a guide or a place to
start, but you may have
more or need less and
also keep in mind that
you may not need all
the listed to make the
vertical user story
ready. A good idea is to
take a look at bill
wake’s INVEST criteria
and determine what is
needed for you.

26. © 2013 PracticalScrum. All Rights Reserved
Vertical User Story, “Must Have”
TYPE OF USER
ONE ACTION
REASON
NOTE: in the template I used,
“must have” and I must means you
cannot do without it because of end
user safety, legal, regulatory,
financial and/or simply that the end
user cannot do their job without it.

27. © 2013 PracticalScrum. All Rights Reserved
Vertical User Story, “Should Have”
TYPE OF USER
ONE ACTION
REASON
NOTE: in the template we used,
“should have” and should have
means that the end user should have
this feature in order to make their job
easier, streamlined and/or whatever
it is.

28. © 2013 PracticalScrum. All Rights Reserved
Vertical User Story, “Would Like To Have”
TYPE OF USER
ONE ACTION
REASON
NOTE: in the template we used,
“should have” and should have
means that the end user should have
this feature in order to make their job
easier, streamlined and/or whatever
it is.

29. © 2013 PracticalScrum. All Rights Reserved
Release Backlog Grooming
Facilitated by the Scrum Master/APM attended by the Product Owner, Business Analyst, Subject Matter
Expert (SME) and team representatives. The reason I say team representatives is because you may not
have the time and/or space for the entire team.
What happens in this meeting?
This meeting is where you want to ensure each user story is vertical and meets all the requirements of the
definition of ready.
It is important to the success of your project that the user stories are something the Team can complete. If
the team cannot complete a story in the sprint/iteration it was intended for then the story didn’t meet the
definition of ready.
Frequency:
Duration:
Attendees:
Goal(s):
Every week (May extend out after you have at least three (3) sprints/iterations worth of vertical user stories groomed.
You may adjust the priority as needed, but get all the other, “Definition of Ready” completed.)
Two (2) - four (4) hours, doesn’t mean can’t be shorter if it ends sooner then it does.
Product Owner, Senior Dev & QA Team Members (Leads), BA, Scrum Master, SME (As needed)
To have enough stories ready for the coming sprints/iterations
NOTE: The team needs to have enough stories to plan and execute at least the next sprint/iteration. Meet as much as
you need in order to compile a prioritized list of user stories that all me the definition of ready.

30. © 2013 PracticalScrum. All Rights Reserved
NOTES:

31. CORPORATE CONTACT INFORMATION
1500 Spring Garden Street
Philadelphia, PA 19130
215.656.2650