RAILOPT AGILE WAY Mihai Cazan / May 2020 AGENDA 1. Objective 2. RoT Agile Today 3. RoT Agile Scaled 4. Processes Overview 5. High-Level Planning 6. Release Planning 7. Iteration Planning 8. Backlog Refinement 9. Estimations 10.Iteration Review 11.Iteration Retrospective 12.References OBJECTIVE • Scale the current RoT Agile processes for a better fit to the current context of life-time extension ROT AGILE TODAY Current context • • • • • Small Agile delivery team mostly in Maintenance mode till Q3/Q4 2019 Work organized based on Kanban method for maximum flexibility Maintenance plays and will play an important role in the future Increased volume of new development in the last months Many more feature developments and architectural changes forecasted for the next years Challenges • Ensure cadence, flow and more predictability in delivery in the future • Keeping the flexibility in solving unexpected Production problems Solution • Adopt a scaled Agile SCRUM method for new Development • Continue using Kanban method for Maintenance issues ROT AGILE SCALED Hybrid Model • SCRUM for new feature development and architectural changes • Kanban for unexpected Production maintenance issues Hot Fix KANBAN Maintenance stream Hot Fix Hot Fix Hot Fix Highly flexible and continuous flow (iteration free) Rotate regularly I1 I3 I2 I4 IN SCRUM Development stream v0 1 v0 2 v0 3 Major Release 3.9.NN ROT AGILE SCALED Benefits • Uses Kanban method to preserve maximum flexibility in delivering priority Hot Fixes for Production • Uses SCRUM method to provide cadence and predictability in delivering value for Business • Better commitment and focus from all stakeholders • Fosters team collaboration and knowledge sharing • Continuous improvement through reviews and retrospectives • Sense of accomplishment after each successful iteration Drawbacks • Sprint velocity not so accurate in some cases • May look ‘underachieved’ due to many issues (over estimated capacity) on Maintenance stream during a specific Sprint • May look ‘overachieved’ due to very few issues (below estimated capacity) on Maintenance stream during a specific Sprint ROT AGILE SCALED JIRA Implementation Solution1 (*) • Use 2 parallel Sprints on the same project ROTW Solution2 • Use 2 separate Kanban and SCRUM boards for the same ROTW project Capacity Allocation Maintenance • 30% 20 30 Development • 50% Other (onboarding, setup) • 20% 50 Maintenance Development Other ROT AGILE SCALED Distributed SCRUM Team BLS Team iQuest Team Mihai Cazan Scrum Master Product Owner Marco Zbinden ??? Alfred Stettler ??? Scrum Master Marc Luginbuehl ??? BA(s) Alina Pocol Stefano Marcone Ciprian Zalog Lorand Kis Sorin Ristache Mihai Cazan Delivery Team Architect SME Stefan Schenk Glauser Jürg PROCESS OVERVIEW to deliver Plan Iteration Planning High-Level Planning … Release Iteration Iterate Release Plan Release Plan … Future Releases Priority Iterate Release Planning Value PROCESS OVERVIEW High-Level Planning XS S L M XL Pre-Release Iteration Inside Iteration 3 Inside Iteration 2 Inside Iteration 1 Release Planning Large Story XXL Stor y Stor y Stor y Story Story Story Stor y I1 I2 I3 I4 Story Iteration planning Story Focused development Priority Epic Risk Story Feature Story Q1 Q4 Feedback 3 3.9.13 3.9.14 Legend Whole team or available members Testers Development team Iteration Release Future Releases Priority Product Owner (value management team) HIGH-LEVEL PLANNING Goal • Create a roadmap for the next releases based on the updated business context vision When • Twice per year in Spring and Autumn, before each Release Planning Participants • PO, key Stakeholders, key members Delivery Team Activities Story • Identify features and user stories • Identify risk response actions • Prioritize the identified backlog items Epic Priority Create product backlog Risk Story Feature Story HIGH-LEVEL PLANNING Create high-level estimates • Group the backlog items in relative (‘affinity’) T-Shirt sizes XS S M L XL XXL Create product roadmap • Plan what to deliver in each release based on projected capacity Release 3.9.13 Release 3.9.14 Release 3.9.15 Q1 2020 Q4 2020 Release 3.9.13 Release 3.9.14 ….. RELEASE PLANNING Goal • Determine which stories will be done in which iterations in the upcoming release When • Twice per year, in Spring and Autumn, before a new release starts, 4 to 8 hours max. Participants • All Stakeholders Activities Slicing stories • Assess the prioritized backlog and break down the stories that are too large to be completed in one iteration Iteration RELEASE PLANNING Activities Story estimation using planning poker 3 Build a release plan • • • • • Select user stories for the upcoming release Estimate velocity for the first iteration Group user stories in iterations Determined how many iterations will be needed Determine a potential release date Release Plan I1 I2 I3 I4 I5 I6 Release date ITERATION PLANNING Goal • Discuss, clarify and plan the work for the upcoming iteration When • Every 4 weeks on Tue, on the 1-st day of a new iteration, timeboxed to 4 hours max. Participants • Delivery Team, PO, possibly other required SME & Stakeholders Guidelines • Iteration planning is organized by the team and is for the team • A team should avoid committing to work that exceeds its historical velocity Input • Goal for the next iteration • Freshly refined (through Backlog Refinement) product backlog ITERATION PLANNING Activities Part1 - Scope • Discuss and understand the iteration goal • Calculate team capacity for the iteration • Select the user stories ready for iteration (DoR) based on the iteration goal and team’s capacity • Define the acceptance criteria for the stories • Provide/refine estimates to the user stories (in story points) • Stop the planning when team runs out of capacity Part2 - Plan • Break down the user stories into necessary tasks • Identify dependencies between stories BACKLOG REFINEMENT Goal • Prepare the candidate stories for the next iteration • Ensure stories are prioritized, detailed and estimated at the appropriate level to avoid ‘scope creep’ When • Continuously during iterations Participants • PO, some/all Delivery Team Guidelines Focus on ‘want to do’ items, not a commitment If something is not there it will not be done PO can add, remove and reprioritize stories Team can slice stories and update estimates Release Future Releases Priority • • • • Iteration BACKLOG REFINEMENT Input • Product backlog containing all the stories Activities • • • • • • Removing user stories that no longer appear relevant Creating new user stories in response to newly discovered needs Re-assessing the relative priority of stories Assigning estimates to stories which need one Correcting estimates considering newly discovered information Splitting user stories which are high priority but too coarse grained to fit in an upcoming iteration Output • Freshly refined & prioritized product backlog • Items on top ready for next iteration planning (DoR) ESTIMATIONS • Progressive elaboration of estimations Knowledge evolution High-Level Planning XS S M L XL Release Planning Iteration Planning XXL 3 3 ITERATION REVIEW Goal • Inspect the product increment When • Every 4 weeks, at the end of each iteration, max. 4 hours for 1-month iteration Participants • PO, Scrum Master, Delivery Team, other Stakeholders if needed Activities • • • • Team demos the product increment to the PO PO decides if the increment is acceptable (“Done”) Any missing points are highlighted and discussed PO and Team make additional changes to the backlog and decide what to work on next ITERATION RETROSPECTIVE Goal • Inspect and adapt When • Every 4 weeks, after current Iteration Review but before next Iteration Planning, 2 to 4 hours Participants • Delivery Team Guidelines • Consider PO’s feedback from the Iteration review • Focus on People, Product, Processes areas Activities • Gather lessons learned • Look for improvement opportunities • Decide what changes to implement in the next iteration REFERENCES • Scaled Agile Framework https://www.scaledagile.com • Agile Alliance https://www.agilealliance.org • SCRUM Guides https://www.scrumguides.org
