Guerilla Agile: Taking a Project from Worst to First Kori S. Mendonsa, CBAP, CSPO, CBPMP Principal Business Analyst Agenda About Why Agile? Learning to Change Learning to Adapt Learning to Prioritize Learning to Succeed Wrap Up Guerilla Agile 2 1
About Me Principal Business Analyst Custom Applications US Tower Division B.S., Music Education Master of Science in Information Systems Alphabet Soup CBAP 2009 CBPMP 2012 CSPO - 2014 About Me First Requirements Document? An RFP for a computerized ticket, group and school group management system Multiple Industries Financial services, insurance, HR/Payroll, wireless infrastructure Secretary, IIBA Greater Boston Chapter June 2011 3 About American Tower Corporation American Tower (NYSE: AMT) is a leading independent owner, operator and developer of broadcast and wireless communications sites. Located in 12 countries Over 69,000 sites globally (as of June 2014) Headquarters located in Boston, Massachusetts About ATC United States Sites (1) 28,000+ Wireless and Broadcast Towers 21,000+ Rooftop Rights ~ 300 Distributed Antenna System (DAS) Networks 4 2
Project Background Each site requires multiple leases Leases for carrier (tenant) equipment generates income from billings A lease with a landlord generates expenses from payments About the Project Most errors in lease terms and details create errors in billings and payments (financial adjustments) Change requests to correct errors was managed through email and spreadsheets Multiple departments could define corrections Each department had their own approval process An average of 900 change requests were processed each month Each lease has between 500 and 1,500 data elements 5 As Is Process 80 people in 15 different roles from 4 departments submitted an average of 900 change requests per month 6 3
From Waterfall to Agile Why Agile? 7 Original Project Scope Why Agile? Lease Maintenance Risk statement from Project Charter: There are several changes that can happen on a lease. Scope needs to be clearly defined. 8 4
Original Waterfall Project Schedule 18 month software development schedule preceded by seven months of analysis Why Agile? ID Task Name 1 Functional Requirements and To Be Process 2 Technical Design 3 Coding 4 Quality Control 5 User Acceptance Q1 12 Q2 12 Q3 12 Q4 12 Q1 13 Q2 13 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Functional requirements documentation extended because To Be process was still not defined in April of 2012 Projected release date was July 2013 9 The Team 1 Developer 1 Custom BA Constraint Table Why Agile? ¼ time PM ½ time QA ¼ Oracle BA (source for lease data) One constraint is fixed One constraint is flexible For the other two constraints, you accept the impact of decisions about fixed and flexible constraints 10 5
From Waterfall to Agile Learning to Change 11 Let s Try Agile Learning to Change We became big fans of Dilbert. 12 6
Communication the Stand Up The status board evolved as the project progressed and our team room was (frequently) relocated. Learning to Change It took us months to achieve a 15 minute stand up. The Yellow Card concept helped. Once we started using Rally, we continued to use the stickies and the visual status board 13 Breaking it down to stories May 2012-200+ page FRD August 2012 Goal-Based Iteration Documents Learning to Change January 2013 Stories! (but still documents) April 2013 - Stories Rally! 14 7
Learning to Sketch it s GEFN! Learning to Change 15 What s a Point? Is it a day? A week? An hour? Learning to Change None of the above! From an iteration planning session. The large stickies are the stories. The small yellow stickies are tasks written up by each team member. 16 8
Sprint Review Code reviews at the end of each sprint were held for a very large audience of stakeholders Learning to Change A formal deck was created for each review which included information on the features to be demonstrated 17 Driving New Behaviors Learning to Change 18 9
Are we ready? A minimum set of criteria which needed to be identified for a story to be ready was agreed to by the team Learning to Change Orange stickies identified analysis (ready) work. Green stickies were for development. 19 From Waterfall to Agile Learning to Adapt 20 10
But Sprint is a Customer! Learning to Adapt Scrum typically uses the word sprint to mean the repeatable period of work executed by the team. At ATC, Sprint is a customer. 21 Peace with the Release Train Standard Waterfall No business access, IT QA testing only Limited, controlled access for business Standard production access Learning to Adapt QC Code installs handled by developers Continuous releases during iterations Access established for business, informed of each code release Agile-ish UAT Code installs handled by release management team Two or three installs for UAT testing Primarily focused for formal UAT testing; available for what if prod testing. Production Code installs require approvals Handled by release management One install per release Standard production access 22 11
Project Plans and the PMO Learning to Adapt Project plans remained in place because of resource allocations Plans changed from showing tasks & milestones to iterations and releases Release dates scheduled based on pre-defined and themed iterations 23 From Waterfall to Agile Learning to Prioritize 24 12
Minimum Viable Product the Pilot Learning to Prioritize 25 Breaking down Everything Release 1.0 Tenant Pilot fixed scope small number of users Release 2.0 Expand Tenant User Base Escalations Billing & Payment Credits & Debits Reporting Release 3.0 Expand Land User Base Revenue Share Management Reporting Learning to Prioritize 26 13
Release 2 Planning Learning to Prioritize 27 Release 3 Finding the Value Learning to Prioritize Can you guess which stories the Product Owner took off the priority list? 28 14
From Worst to First Learning to Succeed 29 The New Process Request Review Approve Change 30 15
User Acceptance Testing Learning to Succeed 31 Voice of the Customer Learning to Succeed Voice of the Customer from the project close out deck 32 16
Agile-ish Continues Learning to Succeed Team rooms and status boards are being used by many of the newly created standing teams. 33 From Waterfall to Agile Wrap Up 34 17
A BA s Retrospective Worked Well Sketching solution ideas Collaborating with team members to identify solutions Using stories to define and break down work Business hands-on with code during each iteration Visual task board Team room (even though it moved a lot) Try It GEFN Good Enough For Now Minimum viable product Production Pilots for complex projects Not so Good Training by reading articles Team applying Agile & Scrum principles when the rest of IT still managing and measuring based on Waterfall SDLC Can it! Working in isolation! Beginning workflow requirements definition without a To Be process Wrap Up 35 18