rmit safe case study: the art of accelerating agility

24
> StAART - Student Administration Agile Release Train @ RMIT Agile Australia 18 June 2015

Upload: catherine-haugh

Post on 17-Aug-2015

89 views

Category:

Technology


0 download

TRANSCRIPT

  1. 1. > StAART - Student Administration Agile Release Train @ RMIT Agile Australia 18 June 2015
  2. 2. The story goes something like ... We started like this: And have come to this: Then introduced this: Project Manager Project Team Project Manager Project Team Project A Project Control Group Project Sponsor(s) Portfolio Manager Project Manager Project Team Project B Project C
  3. 3. A global university RMIT Partner RMIT Campus 82 000 7500 500 43 large projects underway 159,000 service calls in 2014 ITS @ RMIT College of Business has more enrolments than 27% of Australian universities - 24,284 Australias largest university. Dual-sector, providing higher education and vocational education programs. Singapore Institute of Management is largest offshore location with 9000 students.
  4. 4. What was the problem we were trying to solve? Imagine if you could increase productivity, eliminate waste, release value faster and increase staff engagement... @rwbrown: #Agile Irony: People who used to wait a year for the wrong thing now can't wait four weeks for the right one.
  5. 5. A possible solution. We use a delivery framework called "Scaled Agile Framework" (SAFe). SAFe is designed for organisations that have teams delivering work across multiple, interlinked projects. Kanban Lean Scrum Kaizen Servant leadership Teams are at the heart of SAFe This image is known as The Big Picture. It describes the structure of a SAFe working environment, from the grassroots level of squads doing technical delivery (Team level) up to the management of major projects across the organisation (Portfolio level).
  6. 6. What is a release train? A long-lived, self-organizing team-of-agile-teams, that delivers solutions With a purpose ... The release train aligns a group of teams to a common vision and is organised around an enterprise value stream. Iteration Manager TesterFunctional Analysts Business Analyst Chapter Lead Squads on the train Developers
  7. 7. StAART Release Timeline & Rituals PI Rituals Week prior PSI Planning Days Inspect & Adapt Workshop After... 12 week cycle Program Increment - PI 1st Iteration 2nd Iteration 3rd Iteration 5th Iteration 6th Iteration 2 wks 12 wks 4th Iteration Innovation Planning (IP) Cadence Synchronisation Capacity Conversation Velocity Fast feedback Iteration Rituals Squad Standups Scrum of Scrums Standup Everyday...Day 1 Iteration Showcase Squad Retros Last day... 2 week cycle Iteration Kickoff Squad Iteration Planning Sessions
  8. 8. How did StAART evolve? Student Admin Portfolio Horizon 1 label PSI 1.0 - StAART where we are - Stand up Release Train based on current portfolio structure - Review roles and team structure for PSI 2.0+ PI 2.0 + - Integrate Operational activities - Review demand management - Review team structures for future PIs PI 15.2 + - Incorporate other project work requests - Review team structures/capacity for future PSIs Target State 2014-15 25 Sept 2014 25 Jun 2014 StAART (incl. GE, GG, SIDM) Student Admin Value stream StAART (incl. GE, GG, SIDM) + 2 x Operational teams Other project work requests Student Admin Value stream StAART (incl. GE, GG, SIDM) 2 x Operational teams April/May 2014 Get Ready - Leading SAFe training - ART planning - Scrum XP training - Projects in flight
  9. 9. Project/ PortfolioTeam and the Program Project ManagerRTE Developers, Testers, FA, IM BAs (Epic owners, Change Manager Developers, Testers, FA, IM Developers, Testers, FA, IM Business Product Manager Feature Owners How we evolved working together. Project Manager Portfolio Manager/RTE Developers, Testers, FA, IM Developers, Testers, FA, IM Product Manager Team Portfolio/Program Change Manager Plus epic owners (BAs) and feature owners (business) Developers, Testers, FA, IM PI 1.0 PI 2.0+ Feature Owners Epic Owners (Bas) Change Manager
  10. 10. How work comes to the train. V Portfolio Kanban Other ITS teams Program Backlog for all Student Admin demand Break/ Fix items FEATURE FEATURE FEATURE EPIC VSM ITS Lifecycle mgmt Work requests Program Kanban Priority & Rank Prioritise & Rank StAART Student Administration Agile Release Train Feature Backlog Feature Definition PI Planning Team Backlog Program Kanban Team Kanban Prioritise & Rank BAU Backlog Architecture Program Kanban Portfolio Kanban 50% capacity 50% capacity Other projects Architecture Current projects FEATURE FEATURE FEATURE EPIC Program Kanban Project Backlog Prioritise & Rank Priority & Rank Capacity Backlog Capacity Prioritisation
  11. 11. What does the team say.
  12. 12. Release Planning
  13. 13. Release Planning The Program Board illustrates when features are planned for technical deployment and key dependencies between StAART features and/or external teams.
  14. 14. Iteration Kick-offs
  15. 15. Showcase
  16. 16. Inspect and Adapt
  17. 17. Relentless improvement
  18. 18. Whats changed? Conversation Continuous collaboration Visibility Transparency Shared understanding More talk! Merryn Jackson, StAART Product Manager
  19. 19. Brave new world aligning StAART & BSP A jam-packed 30 mins! we went to the gemba we talked face-to-face we shared our practices (including our bulldogs ball - how good are the doggies!) we started to get a shared understanding of our work
  20. 20. Preparing our backlog *NEW* StAART Market *IMPROVED* Feature Backlog Planning
  21. 21. Were think were getting better. A maturing team, more experienced and with higher expectations of what this system should deliver. Working with product owners that really own the product. Having the trust of our business. More access to business and quicker decisions from them More business involvement from the real business people
  22. 22. Our Business partners agree. NPS 0 10% 90% -90 62.5% 12.5% 13 25% Before May 2014 April 2015 We recently carried out an NPS survey of our stakeholders. At the same time, we wanted to look back to try and get a sense of what a baseline might have been before StAART commenced. We had 15 respondents for the current release NPS. We had 10 respondents for the pre-StAART rating. All responses were anonymous. What can we do to improve: More software demos at showcase Clarity re product owner participation/role in release train events More focus on release train squads supporting implementation of software Increased capacity for business stakeholders to be involved with release train teams/activities More involvement of staff in schools where appropriate More focussed analysis for feature definition More transparent solution design More consistent practice across squads
  23. 23. Thank you from the StAART team High performance isnt, ultimately, about running faster, throwing harder, or leaping farther. Its about something much simpler: getting better at getting better. from Better All the Time, by James Surowieke, in The New Yorker, November 10, 2014
  24. 24. Catherine Haugh Release Train Engineer [email protected] @reflectadapt Contact us