Succeeding with Agile against the odds at Australia's Central Bank
•
0 likes•52 views
If you were asked to name the sort of organisation at which Agile transformation is most difficult, what would you pick? Government? Banks perhaps? How about an organisation that is both? Is it even possible for a Government Bank to transition an in-flight program to a thriving Agile capability? In this session we describe how the Reserve Bank of Australia has demonstrated that it is possible to be successful with Agile in an organisational environment in which such a way of working is very foreign. This is the story of transitioning to Scrum and Behaviour Driven Development some months into the bank's largest ever program of work focused on redevelopment of the Banking Departments core banking systems. We outline how we got from test-last waterfall to full Scrum within 3 months, to full-team BDD in 4 months and to a strong collaboration and cultivation culture in 5 months. We describe the key conditions for such an effort to succeed and what we learned along the way.
Recommended
Recommended
More Related Content
Similar to Succeeding with Agile against the odds at Australia's Central Bank
Similar to Succeeding with Agile against the odds at Australia's Central Bank (20)
More from Rowan Bunning
More from Rowan Bunning (19)
Recently uploaded
Recently uploaded (20)
Succeeding with Agile against the odds at Australia's Central Bank
- 1. 21 October 2014 Regional Scrum Gathering Australia 2014 Succeeding with Scrum at the Australian Central Bank
- 2. Background • ROBAS program: Large scale in-house renovation of banking applications and processes • Multi-year program • Transitioned to Scrum while in-flight • Currently running 4 Scrum teams • 2 ScrumMasters F/T • 4 Product Owners seconded F/T, co-located with teams
- 3. Why Agile – Senior leadership perspective • Positive feedback on Scrum from other organisations • Direct experience with the benefits of Scrum • Strong support and measured risk appetite • Prepared to hire expertise to assist with the transformation • Smaller releases to reduce risk in a large program
- 4. Why Agile? – Risk reduction % Risk remaining Time 100 90 80 70 60 50 40 30 20 10 0 Waterfall Scrum Incremental Delivery
- 5. Why Agile – Issues prior to transformation • Strong focus on quality. However, limited experience with large and complex projects • No single backlog, limited ability to track progress meaningfully • High risk of disjointed teams, working in silos • Difficult to keep staff engaged and varied levels of staff engagement • Concern that testing at the end would result in an accumulation of testing debt • No clear definition of ‘Done’ • Scaling up could cause more issues
- 6. Concerns – Within the program team • Why change? – the Bank has a good track record • Will the program timeline be impacted? • Concerns about the structure and role changes • Will enough training and support be provided? • How will the role of the managers change? • We know what works here, how can someone external advise us? • Also, a belief that we already do Agile.
- 7. Concerns – From senior leadership • Too much change at once – big project, new methodology • How will the structure change – do we have to have the unusual job titles? • Will staff need to be re-deployed? • How will staff react or respond to the changes? • What are the benefits, risks, pros and cons? • What skills, experience and capacity is needed to transition to Scrum? • What is Plan B?
- 8. Transformation approach • Obtained buy-in from senior leadership • Solicited input from staff on transformation goals • It is complex – hired trained staff and a coach • Involved staff in selecting their agile coach
- 9. Transformation approach • Identified resistance triggers and planned for them • Planned at a high level; inspect and adapt • Kept a low profile initially – really important, given the concern about too much change • Introduced basic concepts first; deferred Certification as program was in-flight
- 10. Status – Before the Agile transformation • Control-based team culture • Team structure & reporting based on application components • Activity/ Task-based planning, execution and monitoring • A notion that the team was already following Agile
- 11. Nokia Test Score
- 12. Product Owner Team ScrumMaster Roles Product Increment Product Backlog Sprint Backlog Release Burndown Sprint Burndown Done Artefacts Backlog Refinement Sprint Planning Daily Scrum Sprint Review Sprint Retrospective Development Activities ? ? ? Too big, lacking ownership Unfamiliar with role Unfamiliar with role ? X X ? Not being used X X X - - - X Not implemented ? Implementation attempted but not effective Not testing? Too big, status focused ?
- 13. Impact on structure and roles • Moved away from component based structure • Structured around core Scrum roles & Feature teams • Emphasised staff retention during re-organisation • Targeted staff with a positive attitude, open-mind and willingness to give it a go • Communicated 1:1 & then broadly, minimising the duration between the two
- 14. Transformation timeline – Planning
- 15. Transformation timeline – Execution
- 16. People Oriented Organisation Oriented Actuality Oriented Possibility Oriented Control culture Competence culture Cultivation culture Collaboration culture (Personal) (Impersonal) Empower / enable people “We succeed by growing people who fulfill our vision” People driven Express yourself Be willing to change, develop, grow Humanistic, growth and development oriented Freedom to make mistakes “We succeed by working together” Team builder, coach Collegial, democratic Collaborate. Be a team player. Generalist Camaraderie Standard setting Task driven, rational / analytical Matrix adhocracy Be an expert Specialist Competitive, intense pace “We succeed by being the best” Authoritarian Policy and procedure oriented Compliance, adhere to role function Serious, restrained “We succeed by getting and keeping control” Order, certainty Reference: The Reengineering Alternative: A Plan for Making Your Current Culture Work, William E. Scheider (April 1994). Organisational culture types
- 17. 0 5 10 15 20 25 30 35 40 45 50 Control culture Collaboration culture Competence culture Cultivation culture ROBAS Team Culture Before Transformation
- 18. 0 5 10 15 20 25 30 35 40 45 50 Control culture Collaboration culture Competence culture Cultivation culture ROBAS Team Culture Comparison – 5 months later Before After
- 19. Cultural change experienced • Shifted from control to collaboration culture • Empowerment enabled greater engagement • Increased safety to speak up in smaller team environment • Shift from task allocation to self-organising teams
- 20. Clearing the Testing debt 15 3 5 43 46 18 7 2 7 1 1 6 3 17 43 47 12 6 8 3 0 5 10 15 20 25 30 35 40 45 50 Jan-13 Feb-13 Mar-13 Apr-13 May-13 Jun-13 Jul-13 Aug-13 Sep-13 Oct-13 Defects Created Defects Resolved
- 21. Quality improvements • Quality plan • UAT defects reduced to 3~5 per Release • No post-implementation issues in last Release • Getting to tested, fixed ‘Done’ • Specification by example, test driven benefits
- 22. The Three Amigos BA Programmer Tester Illustration: dgtrekker @ deviantArt.com
- 23. Backlog Refinement process Item 1.1 Start of Sprint N-2 Splitting Acceptance Criteria and Example Collation Scenario writing Unrefined Ready Feature: Scenario: Given When Then Scenario: Given When Then Team Refinement Workshop Further analysis to answer questions Start of Sprint N 5 [Story Title] [Story Narrative] Acceptance Criteria Scenario: [one liner] Scenario: [one liner] [Acceptance criteria] [Examples] Is this Ready? Too big? Pre-Sprint In Sprint Epic Item 1 Broad in scope Very little detail Item 1.2 [Acceptance criteria] [Examples] 13 20
- 24. Specification by Example – documentation, collaboration and automation advantages System Documentation Requirements Specification Test cases
- 25. Process Improvements • Three Amigos for cross-functional collaboration • Backlog Refinement with visual management • Cross-functional specification and validation (BDD) • Separation of Unit, Scenario, Acceptance tests • Product Box envisioning • Impact Mapping • Story Mapping
- 26. Scaling patterns • From 2 to 4 Scrum teams working on two products in parallel (‘Grow and Split’) • Multi-team Release Planning, One Product Backlog • Staggered Daily Scrums; Scrum of Scrums • Combined Sprint Review with all teams • Shared Architects and Infrastructure staff • Side-by-side room Sprint planning with cross-team sharing (‘Big Room planning’) • Card walls side-by-side, Teams side-by-side
- 27. Scaling – Side by side walls
- 28. Scaling – Mirrored seating Product Owner pair
- 29. Velocity improvements 0 50 100 150 200 Release 2 - Two teams Release 3a - Two teams Release 3b & 4a - Three smaller teams Release 4a & 5 - Four teams Story Points Story Points 150 100 50 0 200
- 30. Delivery capacity and patterns • Have delivered a release every 4-6 months • Two releases implemented as per original schedule • Large change requests and the transformation effort absorbed with no changes to original schedule • One major release forecast to be completed 3-4 months ahead of the original schedule • Investment in Test automation framework ~ 3 months at less than $100K
- 31. Key Insights • Lived in harmony with the rest of the ecosystem • Sought expertise from outside • Kept a low profile at the start – suited our context • Continued to improve after initial adoption benefits • Smaller teams were more productive than larger teams • Active leadership and daily hands-on engagement • Kept it ‘safe’ for most people • Scrum helped transform team culture • Yes, public or quasi-public sector can adopt Scrum!
- 32. Questions?
Editor's Notes
- Introduction: Bipan Arora, senior program manager at the Reserve Bank. Share our experience in introducing Scrum to the Reserve Bank. Positive (otherwise we probably wouldn’t be here talking about it!!). To assist with the transformation, engaged an external coach – Rowan Bunning. Rowan will be co-presenting today’s talk.
- One of the functions of the Reserve Bank, apart from the well known monetary policy and banking policy-related functions, is to meet the transaction banking needs of government. The Bank is running a large scale in-house renovation of banking applications and processes to improve our offering. The program has been running for 2 years, with few more years to go. We transitioned to Scrum around 6-8 months into the program. As things stand today, we are running 4 Scrum teams with One Product Owner per team and 2 Scrum Masters, each looking after two teams. Now, let’s look at why our leadership team considered using an Agile methodology for this program?
- Personal experience with Scrum before joining the Bank and could see how Scrum could benefit the type of program we are running. Sponsor had some good feedback on Agile from other organisations. SLT Prepared to take some calculated risks to trial Scrum and to hire expertise in order to do so. Strong support from my program director, sponsor and the relevant assistant governor. Above all, the SLT had the foresight to see the value of an incremental approach in reducing risk to the program. Rowan will elaborate more on why this was so important…
- Rowan You might wonder why the RBA cares for an Agile Scrum approach when it doesn’t have the commercial drivers of a highly competitive marketplace A: Risk reduction At the heart of that is Scrum’s Iterative, Incremental approach 10 years in Canberra Big Projects almost invariably ran well over time or budget and worse, delivered something unusable See in banking platform redevelopments Big bang Waterfall 2 years in, 3 years in, 4 years in – delivered no software, only documentation Deliver early, deliver often, listen to your customers Taking one customer of line of business at a time Internal users, one govt agency, international banking etc. No risk exposure with customer already operational on new platform Risk exposure to the next one greatly reduced by already proven ability to deliver to product and constant inspect & adapt Sprint review Little risk of failing to get a release out to production as you’ve already done that
- Limited experience in our area on large and complex projects. Reporting lines structured around application components; two separate project teams, working from separate backlogs. Risk that the project teams would operate in silos and could become disjointed over time. A belief that we already following Agile methodology, although only some basic aspects of Scrum were being used. For example, not testing within Sprints. Risk of accumulating a testing debt. Lack of a clear definition of “Done” further enhanced the risk of unfinished work. Program team was in its growth phase, concern that as we scale up, these issues and risks could be amplified.
- While there were some risks if we didn’t try a different approach; equally there were risks involved if we did. Main concerns stemmed from the program being already in-flight. Why change what’s not broken. Transformation effort is not factored into the original timeline and how it might impact the original program schedule. Concern around how the roles and responsibilities would change and how it might impact the staff, especially the managers, once the Scrum teams are formed. Aspects of Agile were already being used and some team members felt that we were already using the more useful and relevant aspects of Agile.
- How we would manage the scale of change, applied to a big project while in-flight. Calculated risks were taken but not without addressing some of these concerns and questions. There are a few questions to expect from senior management before they would permit a transformation to Agile. I think the impact on people was at the heart of such concerns.
- Obtain buy-in from staff by involving them in formulating the transformation goals and objects. Without having staff who were experienced in Agile was like playing with fire, hired a coach (Rowan) an experienced SM and development team members. Existing staff trained and supported them through hands-on training with Rowan for 2-3 days a week on average. Unique aspect of our approach was to involve key staff in selecting their agile coach from a couple of shortlisted candidates through an interview-style process. Recognised that, our staff are the ones that will deal with the agile coach the most during this transformation and it is important for them to have a say in choosing their preferred coach.
- Once transformation commenced, identified areas that could place the transformation at risk. On a daily basis, worked closely with Rowan and the rest of the team to clear the hurdles and challenges during the transformation. Planned at a high level, and focussed on one thing at a time, making steady progress. If something didn’t go to plan, through regular and open lines of communication, able to inspect and adapt. Broadcasting to the rest of the organisation, initially kept a low profile given there was a concern about the scale of change. Communicated more broadly once the transformation effort took hold. Didn’t take the usual path of sending everyone for certification. Introduce some basic Scrum concepts first and delayed the certifications till there was sufficient hands-on experience. Received mixed feedback on this approach. Some felt that it would have been beneficial to know the big picture first and others felt that it was better this way as it allowed them to absorb Scrum incrementally. Difficult to argue with an incremental approach, when presenting at a Scrum conference, isn’t it!!
- Rowan’s slide
- Rowan’s When I walked in… First coaching activity was to conduct an assessment Reflect back to program staff where they were up to in terms of Scrum and Agile fluency Benchmark for monitoring progress The answer was, you’ve barely started Certainly nothing coherent or effective Certainly not a functioning Scrum implementation Agile Specification score here probably generous as what were called ‘User Stories’ were generally technical tasks rather than chunks of value
- Rowan’s The new structure had just been put in so the PO and SM were new to Scrum and needed guidance Only things vaguely recognisable as something Scrum-like Stand-up meeting… with over 20 people! More a status report to a manager. DoD existed but was not being used.
- Before we hired a coach, moved to Scrum aligned roles of PO and Scrum Master. Re-organised existing staff rather than redeploy – to instil a sense of job security.
- About raising awareness and desire for change Planning the engagement approach Emphasise the importance of involving staff to define transformation objectives, involvement in the RFI and coach-selection process
- Rowan to talk about: The importance of Team formation and release planning at the start. FIT and JBehave assessment Decision was made to pursue JBehave A technical coach was also hired to asses with BDD using JBehave Longevity of BDD style
- Rowan
- Rowan No surprise at all. Emphasise that this was the culture within the team and not necessarily reflective of the Bank’s culture. The overall culture was a type of ‘Control’ culture Agile values and principles are representative of ‘Collaboration’ and ‘Cultivation’ cultures.
- Surprised me
- Rowan
- Realised the importance of testing within Sprints. For a couple of months, we focussed on clearing the testing debt. Ever since we cleared the debt, and then started testing within sprints, have never seen as high a defect rate as what we witnessed in the April-May period. This raised the level of awareness within the team, provided fast feedback and helped improved productivity and quality.
- A unique quality plan was crafted that includes how Scope, Product quality, Process quality, Quality of the Technology and Handover is being maintained. The plan also outlines Financial and Governance aspects. Used the controls embedded within the Scrum process such as Release burndown, Sprint burndown, Retrospectives, etc as the backbone for the quality plan. Low UAT defects per release, no post-implementation issues in the last release. Rowan will talk more about the three amigos and the benefits of specification by example in the next slides.
- Rowan
- Rowan
- Rowan Reduce duplication of effort
- Rowan
- Rowan
- Bipan Investment in magnetic boards
- Inter and Intra-team communication
- Program team has grown therefore the overall velocity has increased. What is more noteworthy is that despite smaller teams now, average velocity per team has increased by around 20-25% since we started using Scrum.
- Once a product is fully developed for a customer or for a group of customers Releasing incrementally to customers
- Finance, Risk, Audit committees, PMO – Eco-system Rowan – Anything to add Invite Cathy – Long term RBA employee, transitioned to a SM role, key member of the team that helped us transform. Any questions for the three of us?