11/18/2017
1
2017Wolfgang Hilpert (Axoom GmbH)
Und sie bewegtsich doch!
w i t h c o nt r i b u t i o n s f r o m N i c o l a s D ü r r & Vo l ke r S a m e s ke
„War Stories“ Track
10:15 – 11:00 Uhr
© Copyright 2017 Wolfgang Hilpert
© 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
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
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
11/18/2017
4
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
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 collaborationbetween teams
• Align all teamson agile approach
9
Phase 1 Phase 2
Agile Development
Agile Support
Development Level
Management Level
Executive Level
11/18/2017
5
© Copyright 2017 Wolfgang Hilpert
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 EscalationsBacklog > 400
Engineering
Product MgmtScrum POSupport
Engineering
Product MgmtSupport
„Scrumban“ w/ support Swim lane
© Copyright 2017 Wolfgang Hilpert
Foster new Experiences …and change will happen
11/18/2017
6
© Copyright 2017 Wolfgang Hilpert
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 ofS / R / T )
Resource Time
Scope
© Copyright 2017 Wolfgang Hilpert
Agile TransformationHard to achieve, easy to lose!
13
11/18/2017
7
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
Common Approaches for Scaling AgileApproach Author
Scrum First-generation agile methodology (other: XP, Crystal)
Ken Schwaber & Jeff Sutherlad
SAFe2012: 1.02013: 2.02014: 3.02015: 4.02017: 4.5
Scaled Agile Frameworkmost well-known scaling framework; highly structured and prescriptive method; go-to option for large, software-intensive projects with highly interdependent teams
Dean Leffin-well
DADdeveloped 2009-2012 (DAD 1.x), updated 2015 (DA 2.0)
Disciplined Agile Deliveryprocess decision framework,providing an end-to-end approach for agile software deliver within enterprise-class organizations
Scott Ambler & MarkLines
LeSSapplied with clients since 2005
Large Scale Scrumminimal 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 developerworkshttps://www.ibm.com/developerworks/community/blogs/c914709e-8097-4537-92ef-8982fc416138/entry/comparing_approaches_to_scaling_agile?lang=en
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
Quarterly Business Cycle Approach
20
ProductOwner
BCPlanning
Review
RetrospectivePrev.BC
NextBC
Planning
6Sprints
per Team
Team Sprint2 weeks
6 Sprints per Business Cycle
Business Cycle3 months
BusinessOwner
BusinessBacklog
BusinessIncrement
ProductIncrement
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
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
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
(Process Management, 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
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
Scrum hurts! Really?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.
© Copyright 2017 Wolfgang Hilpert
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
CurrentStatus
11/18/2017
14
© Copyright 2017 Wolfgang Hilpert
How we did it: make it a team sport ...
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
Scrum hurts! Really?
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
© Copyright 2017 Wolfgang Hilpert
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
11/18/2017
16
Product Roadmaps
33
– Handle with Care!
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
© Copyright 2017 Wolfgang Hilpert
Scrum Principles
36
Factor ofuncertainty
Time
*) “Work expands to fill the time available for it’s completion”Parkinson’s Law
*)
11/18/2017
18
© Copyright 2017 Wolfgang Hilpert
Planning Horizons and Planning Model
37
VisionProduct Strategy
Product Roadmap
Product Backlog
Sprint Goal
3-5 yearsLife cycle
stage12 months 3 months 1-2 weeksTimeframes
After several pivots
quarterly quarterlyWhen new user data is
available
source: http://www.romanpichler.com/blog/choosing-the-right-planning-horizons-for-your-product
Re-planning Cadence
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
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 Managerresponsibility
Prioritized business backlog with business epics
Business epics Business epics Business epics
(Scrum) ProductOwners 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
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
Some Observed Dysfunctions of PM / PO InteractionPM 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
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
Planning Horizons and Planning Model
46
VisionProduct 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
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
Traditional vs. Scrum Roles
50
Source:
pm.stackexchange.com
© Copyright 2017 Wolfgang Hilpert
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
11/18/2017
25
© Copyright 2017 Wolfgang Hilpert
Diversity
52
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
Aim for Full Feature TeamsObserved 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
optimalscenario
observedscenario
time effort
communication and skill transfer
work
waste
© Copyright 2017 Wolfgang Hilpert
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)
Transitionneeded
Re-evaluation of what delivery of „Product Increment“ (per DoD) means
Keytake away
Do not compromise agreed quality standards for misrepresenting the actual progress, learn from over-committment etc.
11/18/2017
27
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
Aim for Engineering Excellence
20%
40%
40%
An exampleEngineering 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
© Copyright 2017 Wolfgang Hilpert
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
Sto
ry P
oin
ts c
om
ple
ted
Business Cycles
Resulting Velocitydependent on the ramp-up investment
With significant ramp-upinvestment 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
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
Engineering Excellence GoalsProvide 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
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
Doing Agile vs. Being AgileKanban 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
© Copyright 2017 Wolfgang Hilpert
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 AgileExecuting 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 AgileInternalizing the mindset, values, and principlesthen applying the right practices and tailoring them to different situations as they arise.
© Copyright 2017 Wolfgang Hilpert
65
11/18/2017
32
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
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
© Copyright 2017 Wolfgang Hilpert
http://www.halfarsedagilemanifesto.org/
11/18/2017
34
© Copyright 2017 Wolfgang Hilpert
Agile Myths & Misconceptions
71
© Copyright 2017 Wolfgang Hilpert
Thank you!