Agile Requirements Engineering + LESSONS LEARNED

Transcription

1 Agile Requirements Engineering + LESSONS LEARNED

2 Global Blue TAX-FREE Shopping Merchants Customs Refund Counter Back-Office Issue Tax- Free Form Approve Tax-Free Form Pay Refund Amount Processing Invoicing Settlement Operational in more than 40 countries, merchants, 250 Refund Points More than 20 Millionen Tax-Free Transactions per year

3 Karin Schöfegger Product Manager (Global Blue) Product Lead (Global Blue) Business Analyst (IBM& Global Blue) R&D Scientist (TU Graz, Graz/Tallinn) MSc Technical Mathematics

4 Transition to Agile Our way to Stop treating your Sprints like a short waterfall

5 Agile Manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

6 Agile Manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Misinterpretation of the Agile Manifestos: Agile does not mean no documentation and no planning!

7 Agile Requirements Engineering CustomerNeeds Documentation of Requirements Traditional, strict Waterfall Elicitatedbefore Implementation, often one-time activity (i.eone BRS). Lenghty,detailed complete documents. Sign-Off. Agil Directcontinuous communication As little as possible, as much as required. Focuson shared understanding. Planning & Timeline Fixed Budget & Timeline Near-termroadmapping. Due diligence of the impact of changes. Priorisation N/A(possibly once). Value of a user story influences its prioritization in backklog Validierung der Requirements N/A, near impossible before roll-out Continuous feedback Change Requests Sign-Offmeetings, large effort Changes welcome, continuous adapation/extension of features.

8 Agile Requirements Engineering Product Backlog = the Heart of Agile Requirements Backlog Grooming = the Heartbeat of Agile Requirements Engineering Principles: Visible to everyone in the company (restrictions only for vendors) Single source of truth with possible different views depending on stakeholders Emergent -it is a living artefact and never complete Prioritized - Items in the backlog are prioritized and estimated Detailed appropriately -higher priority items in the backlog (developed first) are described in more detail than lower priority ones

9 Backlog Management A case study IDEA LOG PRODUCT BACKLOG SPRINT BACKLOG

10 Backlog Management A case study IDEA LOG PRODUCT BACKLOG SPRINT BACKLOG The lifecycle of a requirements is based on a maturing process that is visible to everyone!

11 Backlog Management A case study IDEA LOG PRODUCT BACKLOG SPRINT BACKLOG Items in Backlog are detailed Just-In-Time Minimum Viable Product simplest solution possible ( no jack of all trades feature/product ) Priorisisationof User Stories from an Epic / a Features Req.Engineeringista continousteam activity! PO ensures that the scrum team understands not only the WHAT but also the WHY Scrum-Team is active participant in the requirements engineering process

12 Lessons Learned The difference between reality and theory is larger in reality than in theory.

13 AgilesRequirements Engineering Corner-Stones Mindset Change, not methodology change Required in overall organization, not only IT doing agile vs. being agile Empowerment IT is not a service-provider, but active partner with business, customer and market knowledge Product Owner needs to be empowered to make decisions and is accountable. Not a technical role, complex skillset. Legal/ Security Senior Mgmt Sales Product Owner Marketing Project Mgmt

14 VomAnalystenzumProduct Owner Elicitating and documenting requirements CEO of the product Lessons Learned: Passive vs. active role in the definition of your product Leadership Skills have to be mastered and trained Strategic & business thinking is essential for the success of a PO Differentiation between Just-in-time -Req.Eng. vs. detailed system analysis quite difficult Mindset Change to a self-organized team requires time and a lot of reflection and coaching

15 Shades of Agile Theory often describes ideal process based on an ideal setting For one team, one location, one company, common language, new product Different setting require Shades of Agile : Software development with vendors Software development on-site/off-site Same/different timezones Company / employee culture (i.e. US vs. Indian) Key Stakeholder (Government Service vs. Mobile App for Millenials)

16 Shades of Agile Case Study: Vendor, Off-Site Requirements Process changed: Mock-Ups for Communication Massively increased telephone bills Adapted Agile Req. Eng. Process, Team Setup Efforts for requirements documentation & test case creation -50% Confidence in Estimation increased Preventing bugs instead of finding them (-75%) Team Velocity increased by 55% using SCRUM, velocity stabilized within 4 sprints

17 Cross-Team Initiatives Usually one product is not isolated manage the work in various dev teams No mature, established standard Organizational Structure Product Portfolio & Dependencies The Requirements Engineering usually not limited to my teamonly Integration Requirements Architectural standards Data consistency Security Corporate Identity Common User Experience Business Process related Requirements

18 Cross-Team Initiatives

19 Cross-Team Initiatives Usually one product is not isolated but done by various dev teams No mature, established standard, dependent on Organizational Structure, Product Portfolio & Dependencies The Requirements Engineering usually not limited to my team only Integration Requirements (Architectural standards, Data consistency, Security, Corporate Identity, Common User Experience) Business Process related Requirements

20 Cross-Team Initiatives More traditional approach for High-Level Business Requirements (Sing-Off by Mgmt) In complex environments there is still a strong need for E2E roles! Initiative owner or Project Manager aligns priorities across SCRUM teams

21 Thank you! Karin Schöfegger