Welcome! Scaled Agile Reston, VA Rally Software Eliassen Group 2012
Agenda 7:30-8:00: Breakfast + Registration 8:00-9:00: Meet local Agilists 9:00-9:15: Opening Remarks 9:15-10:00: Rafaa Abdalla Chief Transformation Engineer at Department of Homeland Security 10:00-10:30: Phillip Manketo - Eliassen Agile in a Regulated Environment 10:45-11:45: Customer Panel 11:45-12:00: Close and Raffle Rally Software Eliassen Group 2012
What are we advocating? Steer business strategy to navigate fiercely-competitive markets. Run the development lifecycle to deliver value faster Expand team collaboration like we are all in the same room Rally Software Eliassen Group 2012
Why Automation Metrics Forecasting (How much by when?) Velocity (productivity) Tracking progress (Are we on track?) Health status/risk Quality (defect counts) Performance feedback (What s working) Innovation (What should we build?) Support for geographically distributed teams Collaboration/communications alignment Reinforce the process Rally Software Eliassen Group 2012
V0.81 Rally Software 2012
Validated by Top Independent Analysts "Rally's leadership rests with its breadth and depth of capabilities for Agile teams, combined with a strong and focused corporate strategy." -- Forrester Wave : Application Life-Cycle Management, Q4 2012.# The Forrester Wave: Agile Development Tools, Q2 2010 Rally Software Eliassen Group 2012
Why Rally Ease of use reduces: cost of collection & friction for collection least cost to maintain 10 years singularly focused on Agile/Lean Thought leader (Agile fellows, authors) training, coaching, tuning, transformation services Support for Scrum/Kanban in single product 168,000 users in 115 countries + 40% compound annual growth Analyst acknowledgments 24 Major awards Support for teams/programs/portfolio Gold certified SAFe - partner Rally Software 2012
Additional Resources: Agile Business Webinar Series Weekly Webinar Series to get your team going with Agile Rally Software Eliassen Group 2012
Agile Conference June 3 - June 5, 2013 RallyON 2013: Leading an Agile Organization Industry experts and visionaries Peer networking & presentations See what s next in Rally s product suite Participate in Agile training courses And bring back actionable information for you, your teams and your organization www.rallydev.com/rallyon Schedule of Events RallyON Hackathon Fri Sat, 5/31-6/1 National Day of Civic Hacking Sat Sun, 6/1-6/2 RallyON Mon Wed, 6/3-6/4
About Eliassen Group and our Agile Practice Vital Stats: Revenue: 2012 $175 Million ($13.2MM Agile Practice) 2011 $155 Million ($7.5MM Agile Practice) 1,100+ Billing Consultants o 2012-95 Agile Consultants o 2011-67 Agile Consultants 181 internal employees ~30 Account Executives Overall 4 Agile Specific Account Executives (Agile Engagement Managers) Company reach 9 US offices: Wakefield (Boston), MA (HQ) New York, NY Philadelphia, PA New London, CT Bethesda, MD Baltimore, MD Cincinnati, OH Columbus, OH Dallas, TX (2013) Serving 35 states
Advisory Agile Adop*on / Transforma*on Agile Health Checks Agile Tool Selec*on & Implementa*on Coaching Oversight, direc*on, & planning For execu*ves, teams, & individuals Training Agile whole team Scrum Master Training Product Owner Kanban Business/Execu*ve On Demand Support Scrum Masters Product Owners BA s Developers Test Engineers Accelerating Business Value Delivery
Rafaa Abdalla Chief Transformation Engineer at US Citizenship and Immigration Services of Department of Homeland Security Rally Software 2012
14
Why did we start this journey? What were the goals of the journey? How did we do it? What have we learned so far? Where do we go from here? 15 15
Why did we start this journey? Our charter q Transform core immigration benefit-processing capabilities for USCIS into an innovative, state-of-the-art, electronic and customercentric solution to support the agency s mission Our challenges q Complex system architecture q Cumbersome software engineering lifecycle q Long lead time to deliver business value q Rework q Inability to adapt quickly to legislative changes 16 16
What were the goals of the journey? Improve time-to-mission-value Reduce Project risk Reduce cost Improve visibility Better adopt to changing needs 17 17
How did we do it? CIO initiated and championed effort to change: q Pushed for new system architecture Loosely coupled Open source q Cloud infrastructure q Re-aligned and empowered USCIS teams q Restructured contract vehicles q And.. 18
How did we do it? (cont d) q Moved from Waterfall to Agile! Waterfall vs. Agile Selected initial best Agile practices to use: Continuous Integration/Continuous Delivery Continuous Business Involvement Automated testing Use of Agile methodology (Scrum, Kanban, etc.) to best meet project needs Engaged Agile coaches to help along the way 19
Agile methodology - SCRUM 20
What have we learned so far? Organizational Change Agent is key ingredient for success q For USCIS, CIO is the Change Agent who personifies the Agile mindset and principles Lay out a long-term roadmap Keep iterations and cycle times short Invest in building effective Agile teams Provide appropriate visibility and transparency Maximize efficiency and coordination among teams 21 21
Where do we go from here? Continue to adopt key agile practices Value Driven Development Collaboration Planning / Adapting Testing Integration Continuous Delivery Onsite Customer Product Roadmapping Test Driven Development Continuous Integration to Production (DevOps) Kanban Retrospectives Estimation / Velocity Automated Acceptance Testing Continuous Integration to Test/Staging Timeboxed Iterations (<4 weeks) Iteration Reviews Release Planning Unit Testing Automated Builds Frequent Releases (Quarterly) Product Owner User Stories Continuous Testing Frequent Check-in of Code Immediate Areas of Focus 22 22
Where do we go from here? (cont d) Continue to scale Agile Identify Project Conduct Initial Assessment Identify Methodology Provide Coaching Transition and Support Projects identified through portfolio management process Determine project needs, constraints, criteria for success, etc. Determine Agile methodology (Scrum, Kanban, etc.) based on project needs, constraints, criteria for success, etc. Observe key project activities to identify issues and provide feedback Assist where needed Work with project team and key stakeholders to enable Agile adoption (and ultimately Agile mastery) 23 23
In Summary. 24
Phillip Manketo Senior Agile Consultant at Eliassen Group Rally Software 2012
Agile in a Regulated Environment January 14, 2013 Confidential Presentation
Challenges To Scaling Agile in a Regulatory Environment Ingrained Risk Adverse Mindset Resistant to Change Strategy for establishing a beachhead from which to scale Managing Multiple Stakeholders (Compliance, Legal, Audit) in addition to the Product Owner Interdependent Legacy Applications Antiquated Infrastructure Highly Bureaucratic Release Management Processes and Procedures Selecting the right Agile Methodology Established Software Development Lifecycle
About Me SENIOR AGILE CONSULTANT, Eliassen Group Credentials: Accredited Kanban Practitioner Certified Scrum Professional (pending) Certified Scrum Master PMIWDC Member MBA, University of Miami, Fl. Accomplished agile practitioner with a proven track record leveraging agile practices to consistently deliver exceptional results on behalf of Fortune 500 clients, start-ups and Federal Government entities. Industry expertise: Financial Services, Internet, New Media, Cable & Telecommunications, Federal Government Agile Community: AgileDC 2013 Organizing Board Member, a role held for the last three years.
Traditional Waterfall Methodology Initiate & Plan Requirements Analysis & Design Build SIT CAT Ø Each phase has a baseline set of artifacts which can be audited at the end of each phase by internal compliance organizations
Common Objections To Scaling Agile Methodology Agile does not follow the approved SDLC, we therefore have to write an entirely new methodology before we can scale an Agile implementation in order to satisfy Audit. Agile baseline requirements / deliverables are different than traditional baseline requirements / deliverables. You are going to need a dedicated core team member who is just responsible for managing / versioning the baseline artifacts for each Sprint. How can the Team deliver an increment of work that has any value to the customer, as well as complete an end-to-end SIT and an end-to-end CAT every two-weeks?
Traditional Development Methodology Requirements Analysis & Design Build SIT CAT Initiate & Plan Sprint 1 - n Design Governance Release Mgmt Requirements Save Documenta4on 2 Week Sprints Sprint CAT Build Sprint SIT Agile Development Methodology
Traditional Development Methodology Requirements Analysis & Design Build SIT CAT Initiate & Plan Sprint 1 - n Design Governance Release Mgmt Requirements Save Documenta4on 2 Week Sprints Sprint CAT Build Sprint SIT Agile Development Methodology
Clarification re Sprint SIT vs. Release SIT The purpose of System Integration Testing is to expose design problems with the interfaces among program components before implementation. For each Sprint, the project Team will conduct System Integration Testing (SIT) to ensure that the functionality developed for that Sprint functions as designed. In addition, at the end of all of the Sprints for that Release there is a Release SIT to ensure that any design problems for the entire release are identified. During each Sprint Review, an end-to-end integration test is not required. However, the Team must ensure end-to-end system integration testing is performed for the Release SIT. SIT Tests, SIT results, and SIT approvals are required for each development Sprint and for the final Release. Baseline artifacts must be retained for the Release SIT.
Traditional Development Methodology Requirements Analysis & Design Build SIT CAT Initiate & Plan Sprint 1 - n Design Governance Release Mgmt Requirements Save Documenta4on 2 Week Sprints Sprint CAT Build Sprint SIT Agile Development Methodology
Clarification re Sprint CAT vs. Release CAT Customer Acceptance Testing ensures that the technology solution satisfies the key system requirements for the business customer including functionality, user experience, and performance. At the conclusion of every Sprint, the project Team will conduct a Sprint Demo with the Product Owner (Customer) to ensure that the functionality for the Sprint satisfies key system requirements. This Sprint Demo serves as the Sprint CAT. Customer acceptance of functionality during the Sprint Demo satisfies the Sprint CAT requirement. An end-to-end integration test is not required during each Sprint Demo and/or Review. At the end of the Project, the Team must ensure that end-to-end testing is performed for the Release CAT to ensure that the entire technology solution satisfies the functionality, user experience, and performance requirements of the customer. Baseline artifacts must be retained for the Release CAT.
Methodologies Overview Traditional and Agile development methodologies / frameworks can co-exist with minimal re-work Agile baseline deliverables can be mapped to traditional SDLC baseline deliverables without creating additional and unnecessary documentation requirements SIT and CAT can be accomplished for each Sprint, as well as for the Release as a whole, while delivering value with each increment of work iteratively.
Quick Break! Rally Software 2012
Customer Panel Rafaa Abdalla, Chief Transformation Engineer Robert S. Sfeir, Principal Agile Development Practice Lead Todd Beckett, Scrum Master James Drake, Agile Methodology Lead Rally Software Eliassen Group 2012
Raffle! Rally Software 2012
Thank You! Rally Software Eliassen Group 2012