The Use of Scrum (and Scrum Tune-ups) Presented by: Misha Kononov, ORIS Lead Dev Chris Lose, ORIS Lead Dev Laura Young, ORIS Lead Business

Size: px

Start display at page:

Download "The Use of Scrum (and Scrum Tune-ups) Presented by: Misha Kononov, ORIS Lead Dev Chris Lose, ORIS Lead Dev Laura Young, ORIS Lead Business"

Sandra Owens
6 years ago
Views:

1 The Use of Scrum (and Scrum Tune-ups) Presented by: Misha Kononov, ORIS Lead Dev Chris Lose, ORIS Lead Dev Laura Young, ORIS Lead Business

2 Who is ORIS and what do we do?

5 Financial Compliance SIMS Budgets SIMS IAF SIMS Reports My Research Portal PURE UMetrics Non-Financial Compliance CATS IACUC CATS IRB CATS Safety COINS Occupational Health PRAMS System Status HERMIA Unmanned Aircrafts (on deck!) Dive Safety (on deck!) Other Research Systems Ecosystem Integrations with IBIS Cayuse Grants.gov CATS COINS CITI STAR StudyFinder ClinicalTrials.gov CORES

6 18 Staff Admin 1 Director + 1 Coordinator Devs 2 Leads + 5 Devs BA s 1 Lead + 5 BAs DBA 1 Sys Admin 1 PM 1 (for CORES only) Support 0 Testers 0 IT Trainer 1 *Two of the Leads serve in an Assistant Director capacity to help lead the office * IT Trainer is not part of ORIS, but works with ORIS

7 ORIS BA s and their many hats Perform typical BA duties (requirements, elicitation, testing) Serves at times as quasi PM/BRM/Support with roles ranging from pre-project to operations support Serves as Product Owner for at least one module

8 ORIS Scrum Teams = 2 (split to more as needed) Scrum Schedule = Same Sprint Length = 2 weeks Ceremonies = All 4 (+ release planning + backlog grooming) Certifications = all staff have at least CSPO Ongoing Training = we invest in annual tune-up

10 Tune-up Topics

11 Issue: Poor expectation management Teams overloaded trying to complete all requests Lack of clarity on what is next and why Impression that nothing was getting done

12 Fix: Increased stakeholder involvement Prioritization To include stakeholder Expect engagement Provide deadlines Stakeholders at Ceremonies Daily Check-in Sprint Planning Sprint Review Sprint Retro Release Planning Backlog Grooming Better at saying No Yes, but We need resources

13 Issue: Story(ies) carrying to next sprint(s) One story was owned by multiple people Resulted in lack of accountability Inability to easily check logged time

14 Fix: Break down stories into subtasks

15 Issue: Working as individuals vs. team Torch handoff (vs. in-your-face collaboration) was strong Some roles occasionally overloaded without help, even though capacity was available on the team Some tasks too dev heavy without focus on impact to functional consequences (e.g., training, help documentation, etc.)

16 Fix: Reset expectations on roles and DOD UAT doesn t need to be completed only by BAs or tester Get team to work on helping each other before committing new tasks With the exceptions (coding), most tasks can be handled by any role Hold each other accountable in this Helps to get the sprint work completed faster

17 Issue: Help documents take too much time

18 Fix: Stop striving for perfect Video demo s as you re showing stakeholder s Treat the help documents like mockups, quick and easy is usually adequate as the help is often only needed at the outset

19 Issue: Teams impact each others capacity Team members work across teams Needs of one team affects capacity of the other Little communication between teams

20 Fix: Implement Scrum of scrum/align sprint schedule In SoS, Focus on cross team impact Use Daily check-in model (what did we do last week, what are we doing this week, what is blocking us or the other team)

21 Issue: No dedicated scrum master

22 Fix: Rotate role, share between teams This is possible with a mature scrum team Need to empower rotating scrum master on removing impediments Serves as good professional development for team members Helps with cross-training to ensure acceptance and engagement of scrum

23 Tune-up Results

24 The tune-up helped! Velocity became more predictable Teams started experiencing more successes Increased Stakeholder satisfaction Improved burndown charts

25 Team 1 Year 1

26 Trends SP Completed Team 1 Year 2

27 Trends SP Completed Support Tasks Completed Linear (SP Completed) Team 1 Year 2

34 Focus on Retro s is key One team uses Rose Pruyne s demo of James Shore s mapping retrospective One team uses a more traditional +/-/ Regardless of format one task is the result Focus on teams being able to self-organize

35 Thoughts?

Advantages of Agile model:

Advantages of Agile model: Agile methodology Agile : We divide the application components (parts) and work on them one at a time. When one is ready we deploy it to production (live environment). Agile is very collaborative and interactive.