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

11/18/2017

1

2017Wolfgang Hilpert (Axoom GmbH)

Agile War Stories

“… and yet it moves"

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


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

http://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





➢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?




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


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


Foster new Experiences …and change will happen

https://www.atlassian.com/agile/agile-iron-triangle

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 ofS / R / T )

Resource Time

Scope


Agile TransformationHard to achieve, easy to lose!

13

11/18/2017

7











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

https://insights.sei.cmu.edu/sei_blog/2017/02/five-perspectives-on-scaling-agile.html

https://www.forbes.com/sites/stevedenning/2016/04/15/what-does-it-mean-to-scale-agile/#3d1ad69578b9

https://www.forbes.com/sites/stevedenning/2016/04/15/what-does-it-mean-to-scale-agile/#3d1ad69578b9

11/18/2017

8


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


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

https://www.ibm.com/developerworks/community/blogs/c914709e-8097-4537-92ef-8982fc416138/entry/comparing_approaches_to_scaling_agile?lang=en

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

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

https://www.agilest.org/scaled-agile/nexus-framework/

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

(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


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











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


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


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


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









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 ofuncertainty

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

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


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/

http://www.romanpichler.com/blog/choosing-the-right-planning-horizons-for-your-product

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


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

https://blog.aha.io/this-is-not-a-product-roadmap/

11/18/2017

20











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


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

https://280group.com/wp-content/media/Product-Owner-vs.-Product-Manager-Role-Visualization.png

11/18/2017

22


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


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









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


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











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


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


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

http://www.think-pi.de/Technical-debt

11/18/2017

29


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


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











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


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.


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/

http://blog.itil.org/2015/06/allgemein/10-agile-myths-misconceptions/

http://www.halfarsedagilemanifesto.org/

11/18/2017

34


Agile Myths & Misconceptions

71


Thank you!

http://blog.itil.org/2015/06/allgemein/10-agile-myths-misconceptions/

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

Presentations & Public Speaking