Wolfgang hilpert scaling agile war stories - scrum germany 2017-11-17

11/18/2017
1
2017
Wolfgang Hilpert
(Axoom GmbH)
Agile War Stories
“… and yet it
moves"
with contributio ns from
Nicolas Dürr & Volker Sameske
„War Stories“ Track
10:15 – 11:00 Uhr
© Copyright 2017 Wolfgang Hilpert
Speaker Background – Wolfgang Hilpert
• Product & Technology Leader in various roles
• Chief Technology Officer, Head of Engineering / Software Development, Chief Product Owner
• @ startup, mid-size and industry leading ISVs incl. IBM, MSFT, SAP
• Entire product life cycle from idea on drawing board, design, development, market
introduction & adoption
• Within plan-driven & agile product development environments
• Initiated and led several lean & agile transformations
• @ SAP (Netweaver), @ AGT International, @ Sophos (NSG)
• Product owner, Scrum master, scaled agile (SAFe)
• Established cross-functions for User eXperience, Quality Management & Engineering
Excellence, Product Line Architecture and Program Management
• Personal
• Husband & father of 2 teenagers
• Football player, runner (HM), cross-country skier
www.linkedin.com/in/whilpert

11/18/2017
2
Scrum Teams and Lab Locations
Vancouver (CA)
Budapest (HU)
Karlsruhe (DE)
Bangalore (IN)
Ahmedabad (IN)
• >200 Engineers in 5 locations
• Different cultures – region & company
• Diverse skills, processes, tools
Predictibility Issues – Outcome of Release n-1
• Case – Timeline: Lack of Predictability
• Release n-1 required 35% more time than initially planned
• Long path towards Concept Commit
• More time spent for stabilization than for development
Reality
Plan
Planning
Development
Hardening

11/18/2017
3
Some War Stories
➢Which level of support does the agile transformation need?
➢Scaling agile methods – yes!
➢However, based on which framework?
➢„Scrum hurts. - Really?“
➢Metrics & Transparency help to make the current state and developments visible.
➢How does an 18-months product roadmap fit into an agile project plan?
➢How do agile Scrum product owner and a product manager fit together?
➢How can the agile transformation of global organizations
➢distributed across locations, time zones & cultures be successful anyway?
➢Is implementing agile methods a necessary or sufficient condition
➢for a successful product development?
➢Doing agile vs. being agile
Some War Stories

11/18/2017
4
Buy-in for Agile Transformation on all levels
• Leadership provides the
frame for the transition
• Teams own the execution
8
Agile
Development
Agile
Support
Development Level
Management Level
Executive Level
Buy-in for Agile Transformation on all levels
• Some teams delayed their agile
transformation
• Historical reasons
• Interface issues
• Resistance to adoption
• This hurts a lot
• Be patient!
• Improve collaboration
between teams
• Align all teams
on agile approach
9
Phase 1 Phase 2
Agile
Development
Agile
Support
Development Level
Management Level
Executive Level

11/18/2017
5
Support
Escalations
Backlog
< 80
Before
Engineering as „Sandwich“ between Product
Management & Support
After
0
200
400
600
2014 2015 2016
Outstanding
Customer
Support tickets
(Average)
„Top X“
Support Escalations
Backlog
> 400
Engineering
Product Mgmt
Scrum POSupport
Engineering
Product MgmtSupport
„Scrumban“ w/
support Swim lane
Foster new Experiences …
and change will happen

11/18/2017
6
Boundary Conditions
• Don‘t disrupt agile transformation
• Transparency -> Burn up chart of accomplished product increment
• Quality -> early tests, significantly reduce defects previous vs.
next rel.
• Predictability -> 4 months delay vs. 2 weeks (previous vs. next release)
• Stay true to core agile principle, e.g.
• Magic triangle, commit only based on estimates provided by the engineers
• Still a lot of runway for improvement (TA, UT, etc.)
• Provide visibility of roadmap for annual business planning
• Visibility into 12 months vs. 3 months
Quality =
f ( mix of
S / R / T )
Resource Time
Scope
Agile Transformation
Hard to achieve, easy to lose!
13

11/18/2017
7
Some War Stories
Attributes of Scaling Agile
▪ Team size
▪ Specialization of roles
▪ Iteration length
▪ Synchronized cadence
▪ Release definition
▪ Batch size
▪ Product owner role
▪ User role
15
Compare five-perspectives-on-scaling-agile blog post
Steve Denning

11/18/2017
8
Common Approaches for Scaling Agile
Approach Author
Scrum First-generation agile methodology (other: XP,
Crystal)
Ken Schwaber &
Jeff Sutherlad
SAFe
2012: 1.0
2013: 2.0
2014: 3.0
2015: 4.0
2017: 4.5
Scaled Agile Framework
most well-known scaling framework;
highly structured and prescriptive method; go-to
option for large, software-intensive projects with
highly interdependent teams
Dean
Leffin-
well
DAD
developed 2009-
2012 (DAD 1.x),
updated 2015
(DA 2.0)
Disciplined Agile Delivery
process decision framework,
providing an end-to-end approach for agile software
deliver within enterprise-class organizations
Scott
Ambler
& Mark
Lines
LeSS
applied with
clients since
2005
Large Scale Scrum
minimal framework with high degree of flexibility;
Scrum applied in multiple levels to suit large-scale
development
Craig
Larman
& Bass
Vodde
RUP Rational Unified Process
Nexus Scaling framework minimizing cross-team
dependencies
Ken Schwaber
Source: IBM developerworks
https://www.ibm.com/developerworks/community/blogs/c914709e-8097-
4537-92ef-
8982fc416138/entry/comparing_approaches_to_scaling_agile?lang=en
Scaled Agile Framework (SAFe 4.5) for Lean Enterprises
▪ Scales successfully to large
numbers of practitioner and teams
▪ Synchronizes alignment,
collaboration and delivery
▪ Well-defined in books and on the
Web
▪ Core values
• Code Quality
• Program Execution
• Alignment
• Transparency
▪ Additional roles
• Business owners
• Value Stream engineer
• System architects
• UX professionals

11/18/2017
9
Nexus Framework
https://www.agilest.org/scaled-agile/nexus-framework/
https://jaxenter.de/nexus-scrum-framework-skalierung-48588
Further sources:
www.think-pi.de/Nexus
https://www.scrum.org/resources/scaling-scrum
https://www.scrum.org/resources/nexus-guide
Quarterly Business Cycle Approach
20
Product
Owner
BC
Planning
Review
Retrospective
Prev.
BC
Next
BC
Planning
6
Sprints
per Team
Team Sprint
2 weeks
6 Sprints per Business Cycle
Business Cycle
3 months
Business
Owner
Business
Backlog
Business
Increment
Product
Increment
Scaled lean & agile
approach:
• Plan only next
Business Cycle, i.e. 3
months business
increment in detail
• All other business
epics to be added to
and prioritized
within business
backlog

11/18/2017
10
Business Cycle Concept
▪ Follows Scrum practices & ceremonies
• Backlog grooming prior to planning session
• Planning session to align priorities and find out dependencies
• “Real-time” tracking of execution, addressing risks and issues
• Demo session at the end of the cycle
• Review session at the end of the cycle
• Retrospective session at the end of the cycle
▪ Enhance visibility of execution for the planning window
▪ Early addressing of inter-team dependencies
▪ Set right expectations among stakeholders:
Product Mgmt, Program Mgmt, Engineering team
▪ Gives confidence of achieved results through demos
Program Plan Reflects Feature Delivery, Dependencies and
Milestones
t.
Planned User
Stories of one
Feature team
with incoming
dependencies
from other teams
tracked in JIRA

11/18/2017
11
Scaled Agile Engineering – Federated Approach
Scrum
ToT-A
Scrum
ToT-B
Scrum
ToT-C
Cross
functions
Engineering
Product Line Architecture
(Usability, user eXperience,user documentaion)UX
(ProcessManagement, Transparency,Compliance, Engineering Excellence) QM & EE
(joint development & project model) PMO
How
Core Team /
Center of Excellence
Expert Community of Practice
Scope Time Budget Customer Expectations
What
Decoupling
Cost of Development
Reuse
Standards
Quality Attributes
Process and Tools
Guidance
Best practices/methods
Continuous Testing
(validate system integrity) Security
(Tools,Test autom. FW, CI, HW lab, Certification)Developer Productivity
Setting Standards – Key Success Factor to Scale
• Common Definition of Ready
• Common Definition of Done
• Code Flow Handling
• Common Toolset
• Build System
• Test Automation Framework
• Unit Testing Framework
• Testcase Management
• Defect Management
• „Dogfooding“

11/18/2017
12
Some War Stories
Scrum hurts! Really?
Team burn-down charts to detect deviations and issues early
Example of a bad sprint
(visible already after the first few days)
Example of a good sprint
Team velocity
• to measure productivity improvements
• for better plans and projections

11/18/2017
13
Scrum is:
• Lightweight
• Simple to understand
• Difficult to master
• Opportunity to challenge
the status quo
That is:
• You will encounter impediments!
At least we did.
• Scaling Scrum will amplify this!
At least we experienced that.
• You will run into difficult conversations,
discover mistakes or incorrect assumptions.
• Change is hard. Agile transformation is no exception.
Defect Management, Metrics, Transparency
• Explicit and detailed entry criteria for each of the different phases
• a. closed beta, b. public beta, c. staged release
• Defect classification by
• severity and
• by visibility
to improve transparency of quality status and help teams to focus their efforts
• Weekly ops meetings more efficient and targeted to improve quality
• Drove quality improvement of next product release
- while adding 108 discrete new features
• Reduced „technical debt“ by including > 600 defects
carried over from previous release
• within bug fixing & stabilization efforts for next release
Target
Current
Status

11/18/2017
14
How we did it: make it a team sport ...
Quality Feedback
Enabled and solicited early feedback
• Beta
• More beta feedback compared to Release n-1
• Private beta (76 external beta testers invited)
• Public beta ~ 200 deployments during first 4 weeks
• “Dog-Fooding” by Internal IT
• Release n-1 - Limited dog-fooding (only one location), hence not enough testing in production-like
environments
• Next release - ambitious dog-food plan with IT:
5 different locations running different scenarios in production before general availability of release
• Sales Engineering & Marketing
• Exploratory testing by Sales Engineering team
• 2 rounds with 143 feedback items, primarily UX improvements
• Bug Bounty by engineering team
• 293 findings
30

11/18/2017
15
31
Organization and
leaders promote this
by „letting them
invest time & money“
Do not blame
people, help teams
to overcome their
existing issues!
Teams deliver data, insights and
ideas for improvements
=> Change is not a burden,
IT‘S A CHANCE!
“Change comes from new habits, from acting as if, from experiencing the inevitable discomfort of
becoming.” ~ Seth Godin
Some War Stories

11/18/2017
16
Product Roadmaps
33
– Handle with Care!
Reminder:
Agile Approach  Defer Commitment
➢Delivers great value to our customer
➢Enable us to adopt and change the plan
when necessary
➢Highly Visible, open and honest
➢Lets make promises we can keep
OR
➢Promises value to our customer
➢Hard to adopt and change plans when necessary
➢Usually leads first to over-commitments,
disappointments and then sandbagging
➢More likely to miss promises than not

11/18/2017
17
Scrum Principles
36
Factor of
uncertainty
Time
*) “Work expands to fill the time available for it’s completion”
Parkinson’s Law
*)

11/18/2017
18
Planning Horizons and Planning Model
37
Vision
Product
Strategy
Product
Roadmap
Product
Backlog
Sprint
Goal
3-5 years
Life cycle
stage
12 months 3 months 1-2 weeksTimeframes
After
several
pivots
quarterly quarterly
When new
user data is
available
source: http://www.romanpichler.com/blog/choosing-the-right-planning-horizons-for-your-product
Re-planning
Cadence
Goal-Oriented Product Roadmap
• Goals such as
• user acquisition, activation or
retention
• shifts conversation to
agreeing on strategic
objectives making smart
investment decisions, and
aligning stakeholders
Goal-Oriented product roadmap
designed for creating products
with
• Lean Startup or
• Scrum
38
TBD!
 source: Roman Pichler
http://www.romanpichler.com/tools/product-roadmap/

11/18/2017
19
Proposed Quarterly Business Cycle Planning
and Rolling Annual Roadmap Projection
Quarter Q1
immediate next
Q2 Q3 Q4
Plan for engineering
capacity of up to ...
80% 50%-60% 35%-45% 20%-35%
Product Manager
responsibility
Prioritized business
backlog with business
epics
Business epics Business epics Business epics
(Scrum) Product
Owners responsibility
Epics mapped into
detailed user stories
Support in sizing Support in sizing Support in sizing
Level of granularity of
estimates
User story points (user
story)
T-size (Epic) T-size (Epic) T-size (Epic)
Confidence level Committed forecast
Per Executive
directive -
balance
between:
• Foundation
• Differentiators
• Game
changers
Remember …
”When you get it right, a strategic roadmap is a powerful tool for
aligning the team.
But you will not get there by jumping
straight into the technical details."
From <https://blog.aha.io/this-is-not-a-product-roadmap/>

11/18/2017
20
Some War Stories
Is the Scrum Product Owner the same
as the Product Manager?
• No, usually not.
• Typically, Product Manager are outward and upward facing.
• Traditionally, product managers only participate in initial „sign off“ on
requirements and then have little interaction with engineering teams until the
end of the project.
• Agile product owners focus on
• close collaboration with the engineering team and exploration,
customer feedback, quality and value-based delivery; plus
• Leading traditional project management acts of estimating,
planning and tracking together with their team.
• In smaller setups, PMs may assume the role of POs.
• In my experience, for mid-size to larger development teams
(~ > 5 Scrum teams) that is unlikely.
43

11/18/2017
21
Some Observed Dysfunctions of
PM / PO Interaction
PM PO
- Tried to define technological details ( how) - Did not align product backlog with roadmap and
strategy
- Lack of communication of his vision and strategy
( what and why)
- Lack of communication about business implications
about technical constraints
- Failure to include PO in technical discussions with
other teams or organizations;
- Misrepresentation of technical implications,
engineering costs etc.
Resulted in mutual lack of trust
Product Owner & Product Manager
POPM
Compare:
https://280group.com/wp-content/media/Product-Owner-vs.-Product-Manager-Role-Visualization.png
• Ensure user stories are
„Ready“
• Backlog grooming including
user story prioritization
• Close collaboration w/
engineering team
• Release tracking
• Story acceptance
• Defect Management
• Customer advocate in
engineering
• Challenge engineers on
business value of technical
investments
• Challenge PM on business
value of features
• Business case
realization
• Portfolio management
• Product Strategy
• Business value
definition
• Segmentation
• Buy vs. Build
• Competitive analysis
• Pricing, promotion,
place
• Forecasting
• End of life
• Vision / Roadmap
• Release Planning
• Personas
• Needs definition
• Feature definition
• Positioning & Value definition

11/18/2017
22
Planning Horizons and Planning Model
46
Vision
Product
Strategy
Product
Roadmap
Product
Backlog
Sprint
Goal
Product
Manager
Product
Manager
Product
Manager
Product
Owner
Product
Owner
Owns
Product
Owner
Product
Owner
Product
Owner
Product
Manager
Contributes
Foundation of productive collaboration
between PM and PO roles
Trust
TransparencyTools
47
• No hiding – neither
the good, nor the bad
• Vision, strategy and
roadmap should be well-
known to both roles
• Mutual trust is critical for success
• Both roles should act as a team
• Look for appropriate
tools that support both
• Best practice: Schedule
& attend regular sync-up
calls (if not co-located)

11/18/2017
23
Product Manager
DOs
• Crisply define the what and the
why of product strategy
• Respect authority of PO towards
the engineering team for
managing the details of the
backlog
• including priorities of user stories
DON‘Ts
• Define implementation details
(how)
• Pushing items into the current
sprint/iteration
• Bypassing PO by
putting workload
on the team
directly
Product Owner
DO‘s
• Challenging the PM by
requesting the business value of
a feature
• Challenging the engineering
team to come up with excellent
solutions/implementations
DON‘Ts
• Pushing requests of the
stakeholders to the sprint
without considering
implications, trade-offs etc.
carefully
• Forget to focus on
product quality
and externally
invisible improvements

11/18/2017
24
Traditional vs. Scrum Roles
50
Source:
pm.stackexchange.com
Some War Stories

11/18/2017
25
Diversity
52
Give room for new experiences
„Un-learn“ some old & adopt new behavior, e.g.
• Estimation by (project) manager
vs. development team
• „Build-when-we-can“ vs.
daily (nightly) build AND integrate early
• Component vs. feature teams
• Every team drives own practice vs.
define and verify adherence to standards
• Tool diversity vs. standardization of tools
• Joint training: PO & Scrum Master training

11/18/2017
26
Aim for Full Feature Teams
Observed scenario
• Need to add a new incremental UI enhancement
• Multiple teams (in different locations) need to contribute
• Due missing separation of concern (APIs), every change had to be discussed in detail
and required several iterations
• Frustrating for all teams involved; bad impact on team morale
Desired scenario
• Feature teams are fully functional feature teams
• Appropriate APIs and UI framework incl. documentation minimize need
for skill-transfer & time zone impact
optimal
scenario
observed
scenario
time effort
communication and skill transfer
work
waste
Defining Moment - Priority setting during the sprint
55
Issue Pressure to complete user
stories by end of sprint;
➢ Team requests delay of
test automation work as
mandated by Definition
of Done (DoD)
Transition
needed
Re-evaluation of what delivery of „Product Increment“
(per DoD) means
Key
take away
Do not compromise agreed quality standards for
misrepresenting the actual progress, learn from over-
committment etc.

11/18/2017
27
Some War Stories
Aim for Engineering Excellence
20%
40%
40%
An example
Engineering Excellence
Maintenance & Support
Feature Development
15%
20%
65%
Long-term Goal
 Are 20% of capacity investment into engineering
excellence sufficient to improve the quality long-
term under the current circumstances ?
 Or do we need increased early investments for long-
term benefits?

11/18/2017
28
Evaluate Investment Priorities vs. Efficiency
15%
20%
65%
Long-Term Target
Investment Distribution
Engineering Excellence
Maintenance & Support
Feature Development
1 2 3 4 5 6
StoryPointscompleted
Business Cycles
Resulting Velocity
dependent on the ramp-up investment
With significant ramp-up
investment into EE
WITHOUT significant ramp-
up investment into EE
Trend with investment
Trend WITHOUT investment
 Without investment into
engineering excellence,
even healthy effort
distributions become less
and less efficient.
 Reason: Even simple
features take increasingly
more time due to
accumulated inefficiencies
and complexities
e.g. as result of short
term “workarounds”
 Right balance depends on
level of technical debt
Technical Debt is killing you!
Or: at least your ability to innovate
• Make Technical debt – transparent
• Analyze impacts, options, rationalize with business owners, jointly
define actions
• Define dedicated
business epics &
user stories
• Define Engineering
excellence agenda
Engineering
Excellence

11/18/2017
29
Engineering Excellence Goals
Provide systems to measure quality, progress, improvements
• "Engineering Excellence Scorecard"
• Lagging indicators
• Field defects
• Revenues
• Real time indicators
• Open defects
• Incoming vs. Closed defects
• Test execution status
• Performance, scaleability test trends
• Early indicators
• Architecture health
• “Technical Debt Index“
• e.g. code complexity, missing TA, UTs, etc.
• “CI Readiness Index”
• by product and team
• “SDL Readiness Index”
• by product and team
Key Engineering Improvements
➢Disciplined approach in requirement management
➢Transparency in overall projects progress through consistent use
of tools
➢Fast feedback cycle with working software as often as possible
➢Estimates provided by the team members who will execute
implementation
➢Team empowerment, leading to increasing motivation
➢Continuous improvement mindset

11/18/2017
30
Some War Stories
Doing Agile vs. Being Agile
Kanban boards, daily scrums, sprints Agile mindset, intent-based Management
• „Scrum, BUT …“
• „Cargo Cult Agile“
• ~20% Benefit
▪ Some ability to adapt to changing
priorities
▪ Improved visibility, communication
▪ Increased productivity
▪ Early tests, better transparency of
realistic quality status, improved quality
▪ Reduced risk
• „Joy at work“ „#1 workplace“
• „delighted customers“
• ~200%+ Benefit
• Customer delight
• Joy at work, Employee Engagement
• Innovation, creativity
• Leadership at all levels
• Continuous learning
63
Practices ≠ Mindset

11/18/2017
31
Doing Agile ≠ Being Agile
• Don’t ‘Do’ Agile. Be Agile!
–Alan Kelly
• Stop ‘Doing Agile’. Start ‘Being Agile’!
–Jim Highsmith
64
How to get to a state of being agile?
• Good agile practices that are necessary, but
not sufficient.
• Early indicator for being agile:
Truly empowered product owner(s)
 Long, thorny journey; will hurt, needs coaching
Doing Agile
Executing the practices as closely as possible to “as
prescribed” description, and trying to “inspect and
adapt” to remove impediments to achieving the
“as prescribed” execution.
Being Agile
Internalizing the mindset, values, and principles
then applying the right practices and tailoring
them to different situations as they arise.
65

11/18/2017
32
Transparency
Quality
Predictability
Optimizing
Through-Put
Speed of
Innovation
Vision of Engineering Maturity Progression
& Scaling of Agile Step-by-step
Status quo
of Organization
Mindset:
• Continuous improvement
• zero defect culture
• challenge the status quo
• fault detection seen as
opportunity for improvement
1. Only single-team Scrum
2. One Business Cycle per product
 scaled Scrum on value stream
3. Combine related BCs
 better align value streams
Target of
Organization
introducing scaled
Scrum to improve:
• Transparency
• High quality
• Predictability
• Through-put
• Engineering
practices
How did scaling agile helps us?
• Alignment of business
priorities and engineering
backlog on quarterly basis
• Agility for entire value stream
of all products
• Agile interaction between
multiple teams
• An early integrated product
68

11/18/2017
33
Common Lean & Agile Myths &
Misconceptions
• Myth 1: Agile means “no planning.”
• Myth 2: With Agile, there won’t be any project documentation.
• Myth 3: Agile only works with small projects.
• Myth 4: Agile requires that stakeholders and developers work in a single location.
• Myth 5: With Agile, the final product remains unknown until development is complete.
• Myth 6: Agile processes are less disciplined and structured than those of waterfall.
• Myth 7: Agile is incompatible with development requirements for secure software.
• Myth 8: Lean is only for small startup companies
(hence the book title “Lean Startup”)
69
http://www.halfarsedagilemanifesto.org/

11/18/2017
34
Agile Myths & Misconceptions
71
Thank you!

Wolfgang hilpert scaling agile war stories - scrum germany 2017-11-17

More Related Content

Wolfgang hilpert scaling agile war stories - scrum germany 2017-11-17