Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (14)
Similar to Road to agile: federal government case study
Similar to Road to agile: federal government case study (20)
Recently uploaded
Recently uploaded (20)
Road to agile: federal government case study
- 1. Road to Agile: A Federal Government Case Study Steven Kennedy, US Dept of the Treasury and David Marsh, Bodega Consulting March 21st , 2014
- 2. 2 • Welcome PMI Members from the: Agile Community of Practice • Use Chat Pod for all your QUESTIONS • Earning PDUs • Automatic PDUs for attending live webinar • Slides and Recordings available after 24 hours • Join the Discussion • GovCOP Discussion Board • Twitter @govcop • LinkedIn Group (“PMI Government Community of Practice”) • Volunteer with us (winnie.liem@vcleader.pmi.org) Welcome to the Government Community of Practice! 2
- 3. 3 Our Presenters: David and Steven Steven Kennedy is the Program Manager at the U.S. Dept of the Treasury where he leads the project management staff office for Debt Management Services of the Treasury's Bureau of the Fiscal Service. Steven introduced the use of agile development and cloud computing deliver better code faster at a lower cost. Presentation Title David Marsh has been coaching Agile teams for years (even before Agile became a buzz word), enabling many organizations (govt and non govt) to realize the benefits of agile software delivery by guiding teams on the journey from waterfall development to agility. David’s approach is very hands on where he applies the techniques he coaches first-hand to deliver quality software solutions.
- 4. 4 Waypoints • Brief Introduction to the Business: the Treasury Offset Program • Why Agile? • Typical Barriers to Adopting Agile Delivery Methods – And How We Engineered an Environment to Overcome Them • How the Project Evolved – Acceptance Test Driven Development – Continuous Integration / Automated Deployments • The Results
- 5. 5 The Treasury Offset Program (TOP) • TOP is a centralized offset process that intercepts Federal (and some State) payments of payees who owe delinquent debts to other Federal (and some State) agencies • Debt Collection Improvement Act (1996) • Collects > $7B annually • Fees pay for the system (no appropriated funds)
- 6. 6 Why Agile? The “Before” Situation Disparate and geo-distributed orgs maintaining a legacy system patched together from a proof of concept (COBOL, RISC, DB2). System •Offsets payments to collect debt Problems •Lack of capacity during peak times •Incapable of timely change 1 4 2 3 Organization(s) 1. Business/Prod Support 2. PMO/BAs/Prod Support 3. Development 4. QA
- 7. 7 Why Agile? The Attempts to Evolve the TOP System • Prototype evolved over 15 years through patches and copying of COBOL programs • Web client developed in Java • Several attempts made over the years to redesign: all failed • 2010: Goal of increasing TOP collections by: – Increases in payment streams – Increasing in debt volume – Matching effectiveness – Considered: • Move from Unix to Mainframe • Re-write as-is functionality in Java
- 8. 8 Agile Software Development • Highest priority is to satisfy the customer through early and frequent delivery of valuable software • What it means: – Started with 3 week iterations; now using continuous flow – Stakeholder review and feedback welcomed/acted upon – Focus on one thing at a time, until it is done – Defer requirements definition (learn from the past) – Cross-functional teams composed of both business and technical people – Adaptive planning and a people-centric approach
- 9. 9 Typical Barriers to Agile • Organizational Silos • Siloed Job Titles • Geographic Distribution • Lack of Executive Support • Culture – need for certainty – command and control hierarchy • Traditional Governance Model • Lack of Business-IT Collaboration and Trust • Traditional IT Practices & Infrastructure Timeliness
- 10. 10 Enabling Collaboration Team rooms, video-conference and smart boards Flattened the organization and remove barriers
- 11. 11 A Collaborative, Cross-Functional Team • Team is organized without silos: product owners, developers and quality assurance all sitting side by side during the project’s development. • Turning to a teammate and asking a question that gets immediately answered and validated by working on something together results quickly and accurately in a value-added feature. • Benefits – High-quality software delivered as advertised and faster – Greater transparency for stakeholders – No backlog of defects or bugs – Simplicity due to evidence-based decisions – Evolving cross-functional team – Better environment for innovation and learning
- 12. 12 Using the Cloud • Amazon Web Services GovCloud: – New servers/environments in minutes • Instead of months – Rapid prototyping of new architectures • Experimentation – Pay only for used capacity • Spun up servers on demand for testing – Quickly scale capacity up and down • Don’t have to be right the first time • SaaS – Google Docs, Rally • PaaS – Amazon Web Services (AWS) RDS • IaaS – AWS EC2 and EBS
- 13. 13 The Cloud
- 14. 14 Risk-Driven Backlog Prioritization Early focus on solving the tough problems.
- 15. 15 The Backlog and Kanban Board
- 16. 16 Evolution: Acceptance Test Driven Development (ATDD) The Traditional Approach: – BAs specify requirements in use cases/user stories – Developers interpret and code • Hard to tell when they are “done” • Usually lots of goldplating – Testers interpret and write test cases – Everyone deals with the aftermath of test execution! ATDD • Requirements are written as executable test scenarios: – Created during requirements elaboration and before any code is written – Written collaboratively with developers, product owners and tester – Documented as readable files, in business language, and can be shared with stakeholders – Examples of how the system should behave under specific conditions – When executed successfully, we know the desired feature has been correctly built • Application code is written to execute the tests: – Scenarios become part of the code base, so the requirements are always up to date – Code is written to execute the tests and assert & verify expected results – These tests drive code development (keeping it simple)
- 17. 17 Acceptance Test Example (Cucumber)
- 18. 18 Acceptance Test Example (Cucumber)
- 19. 19 Evolution: Continuous Integration and Automated Deployment • Every time code is checked in: – All the deployable artifacts are built to ensure no breaks – Approx. 7,000 unit, integration are customer automated tests are executed • Nightly – Generate quality metrics via tools like Sonar & CAST – Execute and validate conversion process – Execute performance test and ensure it is within threshold • On-Demand via a button click – Deploy to the cloud acceptance servers (6 minutes) – Deploy to Treasury data center (10 minutes) • Server configuration is managed side-by-side with code and can follow the same configuration management process.
- 20. 20 Continuous Integration – Jenkins
- 21. 21 Code Quality – Sonar
- 22. 22 Code Quality - CAST
- 23. 23 Results: No Known Defects • Quality is built into the feature, not added later. • Product Owners / Devs / QA work closely together to define acceptance criteria before development begins, and communicate at least daily as feature is built. • If a problem is discovered, it is immediately fixed by the developers and tested before the story is accepted. • There is no need to log or prioritize a defect.
- 24. 24 Results: Value Collaboration, High Code Quality, Continuous Integration, Automated Test Suites and Automated Deployment enable rapid releases to production.
- 25. 25 Results: Business Goals Achieved New system has been running in parallel with old during tax season (peak). The process is working!!! • Achieved business objectives. – Can now offset: • $3T in FedWire payments • Grants • Purchase cards ($30B in 100M transactions) to come – Flexibility to change business rules • Able to make policy and legislative changes quickly • Allows for What If scenarios – More Data • Identify why payments that matched debts were not offset
- 26. 26 QUESTIONS? Email: Contact Us, Questions about Webinar or GovCOP: Steven Kennedy skennedy@nobleseat.com David Marsh dmarsh@bodegaconsulting.com Winnie Liem: winnie.liem@vcleader.pmi.org WEBSITE: http://government.vc.pmi.org/Public/Home.aspx TWITTER: Twitter @govcop and Tweet #govcop LINKEDIN GROUP: PMI Government Community of Practice Note: 1 PDU will be automatically entered for those attending the live presentation 26
Editor's Notes
- Steven continued: One of his teams is developing a financial application that collects $6 billion a year for the U.S. Treasury. Primary areas of focus include Agile development, automated test driven development, measureable software code quality, and collaboration. Prior to joining Treasury, Kennedy was an engineer and PM for the installation of DOD’s first telephony firewall system for the U.S. Air Force. Steven holds a master’s of business administration from Samford University and a bachelor’s in management and finance from Christian Brothers University. He is also a Stanford Certified Project Manager. David cont’d: He has experienced both successful and failed agile transformations, and applies the lessons from both to each new engagement (which, as you might guess, have their own unique lessons to learn). He is currently employed on a public-private partnership initiative at home in Toronto in a senior business analyst role, using agile modeling practices to elicit requirements more effectively.
- Dave Steven – Adopt Agile Principles; the changes in processes and IT support those principles. Principles are foundational will guide selection to processes and IT infrastructure. Practices do not make you Agile. We will use the Agile Principles to drive our decisions. Obtain agreement up front with all stakeholders. List 12 Principles: 1. 2. 3.
- Steven
- Dave Steven – Less than optimal collaboration. Old way throw it over the wall months and months later – rinse and repeat. Today it is as if the work is created in the same room. Collaborative even though we are distributed. No walls your job my job.
- Steven Probably worth pointing out that the goal is to have a system that can be updated quickly. As the system has evolved it appears that folks do not know what the requirements were. In Cucumber you can trace the code to the business rule and reason the system is doing what it is doing.
- Dave Steven – We have a system that works: Why do we want to replace it? Changes happen weekly instead of monthly or every 6 months. Respond more rapidly to fixes, legislation changes Is a 3 week iteration; have software touch and feel and use; may not be in production. Production ready software in order to show value. Not just a piece but a working piece. Demonstrate that something gets done. In contrast continuous flow is delivering each feature instead of a group of features to production. The focus is on velocity (how fast) of moving features into production. We use Kanban to manage our work in process limits for the various work states in software development. We are approaching software like an assembly line. If certain areas are slow we can fix it and move on.
- Dave
- Dave
- Steven – The video conference is on 100% percent of the time it is not a scheduled meeting. It is like you are in the same room. If you don’t have folks from San Fran talking about the weather in Philly there is a problem. That is the intimacy of the interactions.
- Dave then Steven Cloud helps with developers testing a small concept; no pre-approval or lengthy wait times. Minutes. Continuous Integration system to test Siteminder. ISS pulls software from Nexus. HTTPS connection. Whitelisted IP. User name and password.
- Steven – These are testing servers. List of all servers AWS. Most of them test environments. Chef and Cast are seen below. Jenkins slaves are the check-in code auto run all the tests. Switching to Bamboo
- Dave Waterfall line looks very optimistic. It should look a lot worse. A lot higher. By running in parallel and releasing frequently we reduce the risk over time rather than waiting.
- Steven – columns represent different states. Kanban limit work in process. If it gets out of control everything slows down. The red columns indicate overload in WIP limits. What has been finished and what has not been finished.
- Dave, then Steven ATDD what is the big deal? It lets business owners and developers talk about what it means for a feature to be done. Lets business owners and developers collaborate on the acceptance criteria for a feature. This encourages simplest solution. No unecessary features or gold plating. Cucumber is a tool that allows the features to be described as business language with a direct connection to the code. It lets you execute the specifications. Specifications are in plain english. English specifications are executable. You have a way of stating them. This avoids ambiguity. Library of english statements to code statements. Run the program to run the specifications. All specifications are regression tested. The alternative is to make a change give it to testing and let them test it and provide feedback. Breakdown comes with Requirements to Design to Develop to Test and that cycles in pre prod until it works. With cucumber and continuous integration this all happens in one cycle without breaking anything else. You cannot release a small piece of functionality. Too expensive create massive risk for a 6 month release.
- Steven: This is what a cucumber scenario looks like. It is really easy for a business owner and developer to collaborate on the features or requirements. This is better than Java code. Startup culture maybe the role is the same.
- Steven – run the scenario for each line in the table results are shown. You don’t have to write a new scenario for each entry. Reusable. Extensible – I just thought of another scenario lets just add a line rather than start from scratch.
- Steven – We are using the cloud but working with a traditional data center. They do not have to be completely separate. We are able to do our initial testing in cloud not expensive to make a mistake. We deploy business owner does not like it we have not deployed into production. Rapid turn around in cloud. To change and redeploy in ISS. When we are actually deploying something we deploy in pre-production allows us to fix issues and pull it back to the beginning. This ensures the change works as we expect.
- Steven – Automatically run tests that we want. Whenever a developer checks in a changes these tests run. So what? This decreases the time from the time error goes into source code until the time we find out. 2 hours vs 2 months. Has this been failing a lot or passing a lot. That is cool.
- Steven Not only do we use this information to look for things that can be improved, we are also going to use it as part of the CM process. If a build doesn’t meet certain thresholds, it fails and isn’t allowed to continue through the build pipeline. Educational tools, Provides individual feedback as well.
- Steven – 5 Star – Along with Sonar we measure our code quality overall trends. Not a hockey stick. The goal is to keep scores above average as the code base increases. Trending tool. Code quality matters. Code quality is the biggest driver of sustainment cost. 80-90% of the total cost of a system is the changes over the lifecycle not the initial cost. Accruing technical debt is the cost of fixing application quality problems. Complexity = slower system breaks more things with enhancements.
- Dave Steven – When the tests are written first it cuts down on defects. The tester gets the developed code and it works or it does not. Rapid feedback loop. Get it right move on. Developer by pure chance get it right, tester logs in bug report, some things get fixed some do not. We don’t knowlingly have technical debt or bugs. Most bugs we have is from not understanding the legacy system.
- Steven – Ability to release code daily with enhancements if needed. If a mistake is made you can rollback easily. Dramatically lower sustainment costs from platform as well as people. Value comes from deploying code into production, automate all the things that are expensive in the legacy process. If automated can release small bits. More secure, more auditable, lower risk. 100 lines vs 10,000 lines easily see problem and fix and get feedback.
- Steven There have been a few cases where the new system running in parallel was able to process files correctly while legacy had problems with them.
- TJ