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

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

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

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

4. 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 collaboration between teams • Align all teams on agile approach 9 Phase 1 Phase 2 Agile Development Agile Support Development Level Management Level Executive Level

5. 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 Escalations Backlog > 400 Engineering Product Mgmt Scrum POSupport Engineering Product MgmtSupport „Scrumban“ w/ support Swim lane © Copyright 2017 Wolfgang Hilpert Foster new Experiences … and change will happen

6. 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 of S / R / T ) Resource Time Scope © Copyright 2017 Wolfgang Hilpert Agile Transformation Hard to achieve, easy to lose! 13

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

8. 11/18/2017 8 © Copyright 2017 Wolfgang Hilpert 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 © 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

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

10. 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. 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 (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 © 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“

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

13. 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 Current Status

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

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

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

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

18. 11/18/2017 18 © Copyright 2017 Wolfgang Hilpert 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 © 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/

19. 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 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 © 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/>

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

21. 11/18/2017 21 © Copyright 2017 Wolfgang Hilpert 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 © 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

22. 11/18/2017 22 © Copyright 2017 Wolfgang Hilpert 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 © 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)

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

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

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

26. 11/18/2017 26 © Copyright 2017 Wolfgang Hilpert 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 © 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) 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.

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

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

29. 11/18/2017 29 © Copyright 2017 Wolfgang Hilpert 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 © 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

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

31. 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 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. © Copyright 2017 Wolfgang Hilpert 65

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

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

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

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

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

Recommended

More Related Content

What's hot

What's hot(20)

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

Similar to Wolfgang hilpert scaling agile war stories - scrum germany 2017-11-17(20)

Recently uploaded

Recently uploaded(20)

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