1 / 34

Scaling Agile War Stories -

".. and yet it moves!"

WolfgangHilpert
Download Presentation

Scaling Agile War Stories -

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 11/18/2017 „War Stories“ Track 10:15 – 11:00 Uhr Agile War Stories “… and yet it moves" Wolfgang Hilpert (Axoom GmbH) 2017 with contributions from Nicolas Dürr & Volker Sameske © Copyright 2017 Wolfgang Hilpert Speaker Background – Wolfgang Hilpert www.linkedin.com/in/whilpert • 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 © Copyright 2017 Wolfgang Hilpert 1

  2. 11/18/2017 Scrum Teams and Lab Locations Budapest (HU) Karlsruhe (DE) Ahmedabad (IN) Vancouver (CA) Bangalore (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 Plan Planning Development Reality Hardening © Copyright 2017 Wolfgang Hilpert 2

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

  4. 11/18/2017 8 Buy-in for Agile Transformation on all levels • Leadership provides the frame for the transition • Teams own the execution Executive Level Agile Support Management Level Agile Development Development Level © Copyright 2017 Wolfgang Hilpert 9 Buy-in for Agile Transformation on all levels Phase 1 Phase 2 • 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 Executive Level Agile Support Management Level Agile Development Development Level © Copyright 2017 Wolfgang Hilpert 4

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

  6. 11/18/2017 Boundary Conditions • Don‘t disrupt agile transformation • Transparency • Quality -> Burn up chart of accomplished product increment -> early tests, significantly reduce defects previous vs. next rel. -> 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 Scope • Predictability Quality = f ( mix of S / R / T ) Time Resource © Copyright 2017 Wolfgang Hilpert 13 Agile Transformation Hard to achieve, easy to lose! Hard to achieve, easy to lose! © Copyright 2017 Wolfgang Hilpert 6

  7. 11/18/2017 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 Steve Denning Compare five-perspectives-on-scaling-agile blog post 15 © Copyright 2017 Wolfgang Hilpert 7

  8. 11/18/2017 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 Source: IBM developerworks https://www.ibm.com/developerworks/community/blogs/c914709e-8097- 4537-92ef- 8982fc416138/entry/comparing_approaches_to_scaling_agile?lang=en RUP Rational Unified Process Nexus Scaling framework minimizing cross-team dependencies Ken Schwaber © 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 © Copyright 2017 Wolfgang Hilpert 8

  9. 11/18/2017 Nexus Framework Further sources: www.think-pi.de/Nexus https://www.scrum.org/resources/scaling-scrum https://www.scrum.org/resources/nexus-guide https://jaxenter.de/nexus-scrum-framework-skalierung-48588 https://www.agilest.org/scaled-agile/nexus-framework/ © Copyright 2017 Wolfgang Hilpert 20 Quarterly Business Cycle Approach Business Cycle 3 months Scaled lean & agile approach: Business Backlog Business Increment Business Owner • 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 Retrospective 6 Sprints per Business Cycle Next BC BC Prev. BC Planning Review Planning 6 Team Sprint Sprints per Team 2 weeks Product Increment Product Owner © Copyright 2017 Wolfgang Hilpert 9

  10. 11/18/2017 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 t. Program Plan Reflects Feature Delivery, Dependencies and Milestones Planned User Stories of one Feature team with incoming dependencies from other teams tracked in JIRA © Copyright 2017 Wolfgang Hilpert 10

  11. 11/18/2017 Scaled Agile Engineering – Federated Approach Scope Time Budget Customer Expectations What Engineering Scrum ToT-C Scrum ToT-B Cross functions Scrum ToT-A Continuous Testing Decoupling How Product Line Architecture Cost of Development (Usability, user eXperience, user documentaion) UX Reuse (joint development & project model) PMO Standards (Process Management, Transparency, Compliance, Engineering Excellence) QM & EE Quality Attributes (validate system integrity) Security Process and Tools (Tools, Test autom. FW, CI, HW lab, Certification) Developer Productivity Guidance Best practices/methods Expert Community of Practice Core Team / Center of Excellence © Copyright 2017 Wolfgang Hilpert Setting Standards 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“ © Copyright 2017 Wolfgang Hilpert 11

  12. 11/18/2017 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 good sprint Team velocity • to measure productivity improvements • for better plans and projections Example of a bad sprint (visible already after the first few days) © Copyright 2017 Wolfgang Hilpert 12

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

  14. 11/18/2017 How we did it: make it a team sport ... © Copyright 2017 Wolfgang Hilpert 30 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 © Copyright 2017 Wolfgang Hilpert 14

  15. 11/18/2017 31 Scrum hurts! Really? Do not blame people, help teams to overcome their existing issues! Organization and leaders promote this by „letting them invest time & money“ 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 © Copyright 2017 Wolfgang Hilpert 15

  16. 11/18/2017 33 Product Roadmaps – Handle with Care! Reminder: Agile Approach  Defer Commitment ➢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 ➢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 © Copyright 2017 Wolfgang Hilpert 16

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

  18. 11/18/2017 37 Planning Horizons and Planning Model Product Strategy Product Roadmap Product Backlog Sprint Goal Vision Life cycle stage Timeframes 3-5 years 12 months 3 months 1-2 weeks After several pivots When new user data is available Re-planning Cadence quarterly quarterly source: http://www.romanpichler.com/blog/choosing-the-right-planning-horizons-for-your-product © 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-Orientedproduct roadmap designed for creating products with • Lean Startup or • Scrum TBD!  source: Roman Pichler http://www.romanpichler.com/tools/product-roadmap/ 38 © Copyright 2017 Wolfgang Hilpert 18

  19. 11/18/2017 Proposed Quarterly Business Cycle Planning and Rolling Annual Roadmap Projection Quarter Q1 Q2 Q3 Q4 immediate next Plan for engineering capacity of up to ... 80% 50%-60% 35%-45% 20%-35% Per Executive directive - balance between: •Foundation •Differentiators •Game changers 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 © 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/> © Copyright 2017 Wolfgang Hilpert 19

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

  21. 11/18/2017 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 • 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 • • • • PM PO • • • • • • • • • • • • • • • Vision / Roadmap Release Planning Personas Needs definition Feature definition Positioning & Value definition • • • • Compare: https://280group.com/wp-content/media/Product-Owner-vs.-Product-Manager-Role-Visualization.png © Copyright 2017 Wolfgang Hilpert 21

  22. 11/18/2017 46 Planning Horizons and Planning Model Product Strategy Product Roadmap Product Backlog Sprint Goal Vision 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 • • Mutual trust is critical for success Both roles should act as a team Trust • Look for appropriate tools that support both Best practice: Schedule & attend regular sync-up calls (if not co-located) • No hiding – neither the good, nor the bad Vision, strategy and roadmap should be well- known to both roles • Tools Transparency • 47 © Copyright 2017 Wolfgang Hilpert 22

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

  24. 11/18/2017 50 Traditional vs. Scrum Roles 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 © Copyright 2017 Wolfgang Hilpert 24

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

  26. 11/18/2017 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 observed scenario communication and skill transfer optimal scenario work waste © Copyright 2017 Wolfgang Hilpert time effort Defining Moment - Priority setting during the sprint 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. 55 © Copyright 2017 Wolfgang Hilpert 26

  27. 11/18/2017 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  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? An example Engineering Excellence Maintenance & Support 20% Feature Development 40% Long-term Goal 15% 40% 20% 65% © Copyright 2017 Wolfgang Hilpert 27

  28. 11/18/2017 Evaluate Investment Priorities vs. Efficiency Long-Term Target Investment Distribution Resulting Velocity dependent on the ramp-up 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 Story Points completed With significant ramp-up investment into EE 15% WITHOUT significant ramp- up investment into EE 20% Trend with investment 65% Trend WITHOUT investment Engineering Excellence 1 2 3 4 5 6 Maintenance & Support Business Cycles Feature Development © 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 © Copyright 2017 Wolfgang Hilpert 28

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

  30. 11/18/2017 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 63 Doing Agile Kanban boards, daily scrums, sprints vs. Being Agile 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 Practices ≠ Mindset © Copyright 2017 Wolfgang Hilpert 30

  31. 11/18/2017 64 Doing Agile ≠ ≠ Being Agile 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. • Don’t ‘Do’ Agile. Be Agile! –Alan Kelly • Stop ‘Doing Agile’. Start ‘Being Agile’! –Jim Highsmith 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 © Copyright 2017 Wolfgang Hilpert 65 © Copyright 2017 Wolfgang Hilpert 31

  32. 11/18/2017 Vision of Engineering Maturity Progression & Scaling of Agile Step-by-step 1. 2. Only single-team Scrum One Business Cycle per product  scaled Scrum on value stream Combine related BCs  better align value streams Speed of Innovation 3. Target of Organization Optimizing Through-Put Predictability introducing scaled Scrum to improve: • Transparency • High quality • Predictability • Through-put • Engineering practices Quality Mindset: • Continuous improvement • zero defect culture • challenge the status quo • fault detection seen as opportunity for improvement Transparency Status quo of Organization © Copyright 2017 Wolfgang Hilpert 68 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 © Copyright 2017 Wolfgang Hilpert 32

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

  34. 11/18/2017 71 Agile Myths & Misconceptions © Copyright 2017 Wolfgang Hilpert Thank Thank you you! ! © Copyright 2017 Wolfgang Hilpert 34

More Related