Expanding the Scaling Conversation. … · Growing “Agile Native” Company • Disruptive...
Transcript of Expanding the Scaling Conversation. … · Growing “Agile Native” Company • Disruptive...
© 2015 Scrum
Inc.
Who We AreScrum Inc. is the Agile leadership company of Dr. Jeff Sutherland, co-creator of
Scrum. We are based at the MIT Cambridge Innovation Center, MA.
Chief Content Officer JJ Sutherland maintains the Scrum
framework by: • Capturing and codifying evolving best practices (Scrum Guide) • Conducting original research on organizational behavior • Publishing (3 books) and productizing ScrumLab
CEO Jeff Sutherland helps companies achieve the full benefits of Scrum leading our
comprehensive suite of support services and leadership training: • Adapting the methodology to an ever-expanding set of industries, processes and
business challenges Training (Scrum Master, Product Owner, Agile Leadership,
online courses, etc.) • Consulting (linking Scrum and business strategy, customizing Scrum) • Coaching (hands-on support to Scrum teams)
Find out more at www.scruminc.com.
We run our company using Scrum as the primary management framework, making
us a living laboratory on the cutting edge of “Enterprise Scrum”
Principal Hardware Engineer Joe Justice leads our hardware consulting practice: •Worldwide consulting at leading hardware companies • 700-800% performance improvement in hardware development • Builds 100 mpg cars in his garage with help from 500 people in 32 countries
© 2015 Scrum
Inc.
Agenda
• Explore additional Scrum@Scale modules
• New Scrum@Scale component – Organizational Development
• Discuss most requested components
• Announce Scrum@Scale Workshops
• Closing
© 2015 Scrum
Inc.
Focus for Today
Three Dimensions of Growing your Scrum
Scale = number of coordinating teams;
Complexity of projects
Distribution = number of different coordinated geographic locations
Saturation = Degree Agile principles have pervaded organization Breaking down traditional “silos”
Distribution
Saturation
Scale
Improvements along any dimension will grow your Scrum4
© 2015 Scrum
Inc.
We Will Use 3 Very Different Example Companies to Illustrate the Benefits of Modular Scaling
Large Defense
Contractor
• Top-down agile
transformation motivated
by perceived external
market pressure • Company vision to halve
the cost of projects
Mid-size Software
Company
• Opportunistic agile
implementation triggered
by acquisition of a small
Scrum company • Market leader Looking to
stay ahead of competition
Growing “Agile Native”
Company
• Disruptive technology
innovator with successful
product looking to scale to
keep up with demand • Leadership are steeped in
agile principles
A B C
Name Classified Autodesk Spotify
Key Context: • Complex, integrated multi-
year hardware/software
projects • Each project has one
customer • Reliability a key priority • Must deliver to detailed
contract requirements
Key Context: • Redeploying a legacy
software product to cloud-
based SaaS model • Goal to increase pace of
innovation • Historically, releases a
disruption for customers
Key Context: • Web/app-based product • Product and company set
up modularly • Allows teams to work
independently with
minimal coordination • Teams co-located
5
1
© 2015 Scrum
Inc.
Modular Framework for Scaling Scrum
Product Ownership Cycle
Scrum Master Cycle
Backlog Prioritization
Backlog Decomposition &
Refinement
Release Planning
Team-Level Process
Release Management
Product & Release Feedback
Metrics & Transparency
Continuous Improvement & Impediment Removal
Cross-Team Coordination
Strategic Vision
Organization Level
Enterprise
Business Unit
Team
Organizational Development
© 2015 Scrum
Inc.
Scrum at Scale Modules are Defined by their Goals, Inputs and Outputs
Goals to be achieved
Required Inputs
Outputs to other modules
Goals Define what the module is intended to accomplish
InputsDescribe the information or resources needed from other modules to accomplish those goals
OutputsOutline what information or product this module generates that are needed by other modules
ANY specific practice that meets the module’s required Goals,
Inputs and Outputs will work with all of the other Scrum at Scale
modules…This is “Contract-First Design.”
© 2015 Scrum
Inc.
Your Requests
• Cross Team Coordination
• Covered in Scrum@Scale Part 2
• Free at: scruminc.com/scrum_at_scale_part_ii
• Backlog Decomposition
• Covered in Scrum@Scale Part 1
• Free at: scruminc.com/scrum_at_scale_part_ii
8
• Release Planning Management • Covered in Scrum@Scale Part 1 • Free at: scruminc.com/scrum_at_scale_part_i
© 2015 Scrum
Inc.
Final Backlog
• Organizational Development – Module #0
• Strategic Vision – Module #2
• Release Planning – Module #5
• Continuous Improvement – Module #89
© 2015 Scrum
Inc.
© 2011 Scrum Inc.
Leadership needs to implement the
Organizational Development Module
to assist the organization in scaling
10
© 2015 Scrum
Inc.
Module Goals:
•Align the development of the entire organization along a shared and transparent
organizational transformation strategy
•Manage the high level transformation process based on a prioritized organizational
transformation backlog with a primary focus on removing waste
•Continuously inspect and adapt the approach according to identified needs, results and impediments
•Support the PO and SM cycle of the Scrum@Scale model through mentoring,
coaching and challenging
0. Organizational Development (Transformation)
Output
Input
0. Organizational Development
Measures and
interventions to
implement the
transformation backlog
Feedback on interventions
Information on transformation status
and process in the organization
Organizational transformation strategy
Vision & goals regarding organizational
culture, structure,values, norms etc.
Up-to-date Organizational transformation backlog
Identified impediments
Other organizational
metrics to provide transparency
Business Strategy and market trends
Status of organizational development
Other organizationaldevelopment
initiatives
© 2015 Scrum
Inc.
The Meta Scrum: Operational Execution of Scaled Scrum
L
Leadership
SH
Stakeholders
PO
Product Owners
Aligned Product Backlog
L
SHPO
Sprint/Time
Aligned Product Backlog
L
PO
Aligned Product Backlog
L
PO
• A gathering of Key
Stakeholders, Leadership,
and Product Owners
• Run by Chief Product Owner
• The forum for stakeholders
to express preferences and
remove blocks (they should
not try to alter product
vision between Meta
Scrums)
• Can be held at regular
intervals or on an ad-hoc
basis
• Allows teams to progress
efficiently down a single
work path
Meta Scrum
Meta Scrum
Meta Scrum
SHSH
SHSHSH
SHSHSH
© 2015 Scrum
Inc.
© 2011 Scrum Inc.
As an organization, we need a
Strategic Vision to scale Scrum
successfully
14
© 2015 Scrum
Inc.
2. Strategic Vision
Module Goals: • Clearly align the entire organization along a shared path forward • Compellingly articulate why the organization exists • Describe what the organization will and won’t do to leverage key assets in
support of its mission • Update and fine-tune vision continuously based on feedback to
outmaneuver the competition
Clear goals
and principles
for ordering
the backlog
and managing
tradeoffs
Input
Output
Hypotheses on
market needs and
growth engine to
be tested
Consumer, market
and competitive
positioning insight
Feedback on
released
product
Other team
metrics to
support
transparency
Additional context
clarifying
organizational
culture, vision,
goals and norms
Feedback on
release
progress
2. Strategic Vision
15
© 2015 Scrum
Inc.
Example: Vision Statement for ScrumLab™
For experienced Scrum practitioners (Jill) who are “in the trenches”
Who need clear and actionable information to answer specific Scrum questions whenever they arise
ScrumLab Is the authoritative, curated on-demand source for Scrum Inc.’s leading edge thinking
That: • Clearly explains Scrum and its underlying principles (the why) • Shares successful advanced practices for different contexts • Provides actionable solutions to implement successfully • Is available whenever you need it
Unlike other online Scrum resources
Our product captures decades of successful experience and wisdom from the co-creator of Scrum and his hand-picked team of thought leaders
16
© 2015 Scrum
Inc.
Alternate Approaches to Satisfy the“Strategic Vision” Module
Contract
Mgmt. Team
• Corporate vision still set
and established in
traditional model • Vision includes goals to
halve project delivery cost
thru agile • Corporate vision translated
to project-level vision and
goals through customer
discussion & contract
negotiation
PO Team
• Corporate leadership
articulates enterprise-level
vision and goals and
updates to reflect market • Chief PO for each product
maps these goals to given
product and maintains
working vision that
incorporates regular
feedback and team
discussion
Empowered POs
• Strong culture of team
empowerment & collective
ownership • Leadership articulates
corporate “objectives &
key results” quarterly • “Tribes” of component
teams work together
facilitated by POs to
interpret that vision at the
component level
A B C
Pro: Does not yet require large
organization or customers to
change what they are used to
doing; meets core productivity
goals
Con: Still very traditional
“waterfall” process that limits
ability to innovate faster using
customer feedback
Pro: Provides a highly centralized
vision, while also responding to
change and leveraging product/
team-level input
Con: Still quite hierarchical and
enterprise-level vision, in
particular, not updated as
frequently
Pro: Lightweight approach;
leadership focused on big picture
only, and teams develop
ownership of vision
Con: Stronger potential for
conflicting views on how to
achieve objectives; Risk of sub-
optimizing vision at component
level 17
© 2015 Scrum
Inc.
© 2011 Scrum Inc.
As an organization we need
Continuous Improvement to
maximize success
18
© 2015 Scrum
Inc.
8. Continuous Improvement and Impediment Removal
Module Goals: • Identify impediments that slow teams down and reframe them as
opportunities to get faster • Maintain a safe and structured environment for prioritizing and removing
impediments, and then verifying the resulting improvement • Ensure visibility at the right level(s) in the organization to effect change
Impediments raised
by individual Scrum
teams
Measured improvement
documented sprint by
sprint
Input
Output
Velocity data for
all teams
Visibility to leadership,
stakeholders and teams
about impediment status
8. Continuous
Improvement
& Impediment RemovalUpdates on
impediment
removal
19
00. Organizational Development
Kaizen identified and
acted on for every sprint
© 2015 Scrum
Inc.
Alternate Approaches to Satisfy the“Continuous Improvement” Module
Agile PMO
• Individual teams identify
impediments • Impediments discussed at
regular Scrum of Scrums,
and escalated if needed • “Agile PMO” is available to
support removal of
corporate, contract, or
systematic impediments • Agile PMO logs and tracks
impediments
Escalation with
Exec. Support
• Individual teams identify
impediments • Impediments discussed at
regular Scrum of Scrums,
and escalated if needed • Executive “sponsor team”
tasked with removing
major impediments fast • Systemic impediments
referred to functional
“Centers of Excellence”
Flexible
• Individual teams identify
impediments • Cross-cutting issues can
be discussed in “chapters,”
“guilds”, ad hoc, or with
team’s executive mentors • Culture of continuous
improvement encourages
employees to help resolve
team impediments
A B C
Pro: Structured process to
provide teams with support to
remove impediments; provides
audit trail for ISO and contract
requirements
Con: Involves greater
overhead; in practice, has a
mixed record removing
impediments in a timely way
Pro: Traditional escalation model
for removing impediments;
teams get support, but
impediments removed at lowest
level possible
Con: Requires greater overhead
in terms of meetings and
staffing; can take time for
impediments to percolate up
Pro: Very informal approach
allows for different solutions to
different impediments; reinforces
culture of collaborative
empowerment
Con: Little formal structure can
make it difficult to recall what
was or wasn’t done; depends on
supporting culture 20
© 2015 Scrum
Inc.
© 2011 Scrum Inc.
As an organization, we need
Release Planning to align
stakeholders and anticipate delivery
21
© 2015 Scrum
Inc.
5. Release Planning
Module Goals: • Forecast delivery of key features and capabilities • Communicate snapshot of delivery expectations to stakeholders • Inform updated prioritization, as needed, based on stakeholder input
Prioritized Product
Backlog
Input
Output
Requests to re-
prioritize backlog
elements based on
current delivery
expectations
Team velocity for all teams
Stakeholder input on
implications of current
delivery trajectory
Burndown
chart(s) of
progress towards
release
Historic data on emerging
requirements, defect rates
and other additional
activities
5. Release Planning
Roadmap of
upcoming
functionalitySprint
Release
Backlog
(points)
400
© 2015 Scrum
Inc.
Alternate Approaches to Satisfy the“Release Planning” Module
Tightly Managed
Deliverables
• Contract management
team outlines and verifies
feasibility of meeting
contractual release
milestones • Monitors burndown
progress and emerging
requirements • Identifies “at risk”
deliverables early and
negotiates responses
Release Train
Burndown
• Product Owner team
meets regularly to: • Discuss progress • Update release plan • Re-prioritize backlogs as
needed to align
complementary
functions for quarterly
releases • Stakeholders updated of
any changes
Stakeholder
Transparency
• Team Product Owners
update metrics and
backlog at end of each
sprint • Individual team tools and
information radiators
available to anyone • Provides visibility, if
stakeholders disagree with
current plan, they can
raise concerns
A B C
Pro: Better than traditional
waterfall planning because
forecasts based on actual
progress, and interventions can
happen much earlier.
Con: Still relatively rigid,
hierarchical, and not as
responsive to new learning
Pro: Straightforward way to plan
releases that align key
dependencies across teams and
provide transparency to all teams
and stakeholders
Con: Process not automated;
Requires more overhead than
independent release approach
Pro: Provides transparency for all
stakeholders; low overhead for
teams and POs
Con: Requires product modules
to be largely independent; not
systematic across all teams;
burden of proof for identifying
conflicts falls on stakeholders23
© 2015 Scrum
Inc.
Scrum Allows us to Break the Iron TriangleComplete More Scope in Less Time with Fewer People
Scope
Time
Resources
• Traditional planning views Scope, Time and Resources as locked in a fixed relationship
• In theory, any dimension can change to meet release requirements…
• …But, in practice resources seen as easiest to change, while scope & time seen as fixed constraints
24
© 2015 Scrum
Inc.
Scrum Allows us to Break the Iron TriangleComplete More Scope in Less Time with Fewer People
Velocity
But in Scrum we find: • Small & stable teams are key
• Flexing scope actually much easier than changing resources • Requires scope defined as independent features,
and prioritized by value
• Increasing velocity allows team to get more done in the same time • Accomplished by removing impediments
Scope
Time
Resources
25
© 2015 Scrum
Inc.
Release Plan Links Concept and Physical Worlds
Vision/Roadmap
Sprint Goals
Feature Availability
Product Release
Shippable Increment
Backlog Item
(User Story)
Conceptual View Physical Product View
26
© 2015 Scrum
Inc.
Elements of a Scrum Release Plan
• Clear Vision
• Tied to concrete business value
• Aligns stakeholders
• Vision decomposed into independent features
• Prioritized and estimated
• ROI and customer need driven
• Burndown chart of progress on prioritized backlog items
• Measured in Points!
• Feature availability timeline
• Best guess – subject to change
1
2
3
4
Sprint
Release
Backlog
(points)
400
Story
Story
Story
Feature
Story
Story
Story
Feature
Story
Story
Story
Feature
Story
Story
Stpry
Feature
27
© 2015 Scrum
Inc.
20
Q4200
Q3200
June2008
May2008
Apr2008
Release Burndown Chart Makes
Team’s Velocity Implications Visible
Sprint/Time
Points
Sprint/Time
Points
28
© 2015 Scrum
Inc.
Three More Considerations for Anticipating Burndown
All three factors must be accounted for to determine accurate burndown
Bugs and Customer
Feedback
29
Emerging
Requirements
Additional user stories beyond those known in the backlog that are “discovered” as the project evolves and require the team to do more work.
Generally happens as a consistent percentage of estimated work, which can either be added to the backlog as a “buffer” or subtracted from velocity in calculating burndown.
Undone Work
Additional work needed to release features to the customer. Teams without a robust Definition of Done will leave work undone that must be completed before release.
This often materializes as software that is isn’t fully tested or integrated, documentation that isn’t written, or an involved release process. Analyze how many points of additional work are consistently needed before a product can be released and factor that amount into your release plan.
Addit ional work that cannot be anticipated in the release plan, but you know it will come up as product functionality is released.
Track as a separate buffer as a percent of estimated work, and try to manage down the percent of velocity devoted to bugs as a way to speed up the team.
© 2015 Scrum
Inc.
Roadmap Helps Stakeholders Know when to Expect New Features
• Facilitates conversations on feature priority
• Aligns stakeholders and heads off distraction
• Ground rule: Timeline is only an estimate, and subject to change
Q1
Q2
Q3
Q4
• Basic platform with ability to create new user • Homepage and introduction • Ability to view account status
• Ability to update account information/address • Select communication options and preferences • “Share with friends” link
• Ability to rate individual articles • Ability to sort by top rated articles • Ability to refer friends for a referral bonus
• New premium content offering • Corporate portal for company viewing
30
© 2015 Scrum
Inc.
Deadline–Based Release Planning Medco Case Study
On July 7 2006, Medco CEO promised Wall Street analysts a completely new pharmacy fulfillment system to be implemented by July 7, 2007 • Unfortunately, he didn’t check with the development team first!
TimeJul‐06 Dec‐06 Jul‐07 Dec‐07
Plan
Code
Promised
Delivery Date
Test
31
Chapter 6
Plan Reality Not Fantasy
© 2015 Scrum
Inc.
Deadline–Based Release Planning Medco Case Study
Points
On July 7 2006, Medco CEO promised Wall Street analysts a completely new pharmacy fulfillment system to be implemented by July 7, 2007 • Scrum Inc team did week long release planning in January
1,000
TimeJul‐06 Dec‐06 Jul‐07 Dec‐07
1
Promised
Delivery Date
1,000
880
60
500
32
Teams generated
transition team
impediment list 1. ……
2. ……
3. ……
4. ……
5. ……
6. ……
7. ……
8. ……
9. ……
10. ……
11. ……
© 2015 Scrum
Inc.
Deadline–Based Release Planning Medco Case Study
Points
On July 7 2006, Medco CEO promised Wall Street analysts a completely new pharmacy fulfillment system to be implemented by July 7, 2007
1,000
TimeJul‐06 Dec‐06 Jul‐07 Dec‐07
1
Promised
Delivery Date
1,000
880
60
500
33
290
790
Transition Team
removed all
impediments in a
week 1. ……
2. ……
3. ……
4. ……
5. ……
6. ……
7. ……
8. ……
9. ……
10. ……
11. ……
X
2
© 2015 Scrum
Inc.
Deadline–Based Release Planning Medco Case Study
Points
On July 7 2006, Medco CEO promised Wall Street analysts a completely new pharmacy fulfillment system to be implemented by July 7, 2007
• Team executed Scrum Emergency Procedure (scrumplop.org)
1,000
TimeJul‐06 Dec‐06 Jul‐07 Dec‐07
1
Promised
Delivery Date
1,000
880
60
500
34
290
790
3
Medco Stock
550
3
© 2015 Scrum
Inc.
Scrum@Scale Workshop
• Are you concerned that a cookie-cutter approach to scaling won’t work for your organization?
• Join Scrum Inc. at Salesforce.com on 11 February in San Francisco or 4 March in Stockholm to: • Lay out the business case for your organization to use a
modular scaling framework • Present an overall vision for modular scaled Scrum that
spans the Team, Business Unit, and Enterprise levels to link vision with effective execution
• Share specific examples of different successful practices within each module
• Help attendees work through their own scaling challenges in the context of the framework
• Participants will leave with a workbook showing tailored progress towards their scaling solution, and the experience will equip them to lead a productive conversation of what the organization really needs from scaling Scrum.
Salesforce.com
1 California Street
San Francisco
California
11 February 2015
© 2015 Scrum
Inc.
Questions?
Available from Crown Business
Order at Amazon or Barnes and Noble
“Scrum is mandatory reading for any leader, whether they’re leading troops
on the battlefield or in the marketplace. The challenges of today’s world
don’t permit the luxury of slow, inefficient work. Success requires
tremendous speed, enormous productivity, and an unwavering commitment
to achieving results. In other words success requires Scrum.”
General Barry McCaffrey
© 2015 Scrum
Inc.
Stay Connected
E-mail • [email protected], [email protected]
Twitter, Facebook, and G+ • @Scruminc, @Wikispeed, #Scrum, #Agile
Our Website • www.scruminc.com • check in for announcements, new content and services, book
releases, and more!
ScrumLab • Scrumlab.scruminc.com • Articles, videos, papers on all things scrum
Online Courses • Advance your learning with our interactive online courses. Visit
scrumlab to view upcoming topics.