> StAART - Student Administration Agile Release Train @ RMIT Agile Australia 18 June 2015
Transcript
1. > StAART - Student Administration Agile Release Train @
RMIT Agile Australia 18 June 2015
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. 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. 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. 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. 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
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. 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. 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. What does the team say.
12. Release Planning
13. Release Planning The Program Board illustrates when
features are planned for technical deployment and key dependencies
between StAART features and/or external teams.
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
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. 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. 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