Agile Technology Contracting in Federal Government by Traci Walker
•Download as PPTX, PDF•
0 likes•779 views
Focusing on implementing Agile Software Development to show how to navigate the flexibilities that exist in the Federal Acquisitions Regulations
Recommended
Recommended
More Related Content
Similar to Agile Technology Contracting in Federal Government by Traci Walker
Similar to Agile Technology Contracting in Federal Government by Traci Walker (18)
Recently uploaded
Recently uploaded (20)
Agile Technology Contracting in Federal Government by Traci Walker
- 2. AGILE CONTRACTS IN GOVERNMENT Traci Walker, USDS
- 3. We need to bridge the gap between the government and digital solutions Photo credit: https://www.flickr.com/photos/blmoregon/11442393906/
- 4. “GALLOPING GERTIE” Tacoma Narrows Bridge
- 5. Digital transformation needs a safer path
- 6. Focuses on implementing Agile software development to show how to navigate the flexibilities that already exist in the Federal Acquisition Regulations www.playbook.cio.gov/techfar TECHFAR HANDBOOK
- 7. DURABLE BUT FLEXIBLE SAFETY AND LOWERING RISKS NOT OVER-ENGINEERED HOW TO BUILD THE RIGHT CONTRACT FOR AGILE DEVELOPMENT
- 8. SEPARATE TECHNICAL FEATURES FROM CONTRACTUAL REQUIREMENTS REPEATED PROCESS FOR THE DELIVERY OF WORKING PRODUCT APPLY THE RULES OF AGILE IN THE RULES OF THE CONTRACT DURABLE BUT FLEXIBLE
- 9. CORRECTLY APPLY CONTRACT TYPES THINK SMALL HAVE AN EXIT STRATEGY SAFETY AND LOWERING RISKS
- 10. NOT OVER-ENGINEERED Waterfall Contracting Agile Contracting Individual Labor Categories Agile Teams Labor Rates or FFP completed system New Unit of Measure: FFP Per Iteration One Final End Solution Repeated process for functional product Full Solution Released (IOC/FOC) Release Management / Minimum Viable Products Maintenance becomes Steady State New development / bugs / enhancements prioritized equally as User Stories New/Changed Features = Modifications for New Cost/Schedule New features = longer schedule to completion or reprioritization of effort underway Formal Past Performance Performance Retrospectives Project Management Product Owner Full scoped out requirements “Just in Time” Requirements in User Stories
- 11. SBA CASE STUDY: CERTIFY.SBA.GOV Started 2015 March 2016: WOSB Certification Launched December: First Service Launched August: Team arrives November: Environment Ready June: Contract formalized
- 12. CHALLENGE YOURSELF The right contract is one that bridges agency mission to desired outcomes with the right balance between government regulation and flexibility in delivering digital solutions
Editor's Notes
- Voice Over: We are trying to transform the way the government builds solutions for its citizens. USDS is committed to making great products and hiring great people - but we cannot do it alone. For the majority of the systems that have to be updated or built we must contract out that work – and the procurement process can be one of the biggest roadblocks. I do not think of contracting for agile software development as a service contract though, I view it as a mechanism for transporting user needs into digital outcomes. Real tangible product, code and data is what we are purchasing – not hours of development or comprehensive test and project plans If we are able to flip the lens on how we view procurement and think of it in the same way we think of the digital service outcomes we want – the complexity falls away and we are able to navigate the process of applying regulation and laws that were not written for a tech world.
- VOICE OVER: In order to carry on the theme of a mechanism for transportation, I like to think of the contracts as the bridge between our current state and where we want to go - or the outcome we want to achieve – and we as contracting professionals must know how to design the correct “contract” bridge for the situation We sometimes think that by planning everything in advance we will have a better solution - but that does not work for technology. We document all of the requirements that the system must do and sometimes take 2-3 years for this process in an attempt to lesson the risk or to try to cover every contingency. Take the Tacoma Narrows Bridge for example- many years were spent engineering and building it- and it built as the third longest suspension bridge however it was only built as a two lane road- which proved to be its downfall, literally, as the high winds eventually caused it to wobble and collapse - thus earning the name Galloping Gertie – even when we try to control everything - we can still have failed outcomes. This is where agile methodologies come into play. But Traci – if we don’t write it all down and plan for it – how can we make sure we’re getting what we asked for? Plans are important but theory can easily fall apart when it becomes a reality in end users hands.
- VOICE OVER: To avoid costly structured contracts – the counter proposal is to throw together something quick and cheaply in an effort just to get coding – This bridge certainly gets people from one side of the canyon to the other- but I think only the bravest of us want to cross it- the seasoned experts are charging that way- or my co-workers the US Digital Service. BUT, for the majority of the rest of the work that needs to undergo digital transformation – we need a safer path. We are still the government and there are restrictions and risk that we must account for in our contracts - and accountability to the taxpayers to uphold competition, get best value solutions, and spend our investments wisely.
- My Story: I have been an IT CO for 15 years, most recently working at the White House on the procurements for the OCIO’s office. About 4 years ago I was administering a contract for website development services that was done on a Cost Plus Award Fee basis. We were set to release a big new website page that was intended to bring millions of citizens to the website – however the day it launched – it didn’t work. I’m sure we have heard this story before! At this point – the way the contract was written – we had two options- we could terminate the contract or we had to pay more to get it up and working. Termination was not an option that we could really take because we needed the site working – so we continued to pay the company to fix the site. The problem with Cost Type contracts in this case is that we were paying for Best Effort – not working product. Following this, my product manager came to me and said – Traci I’m going to give you an impossible situation- I want to transition this contract to agile software development methods and I want to do it on a Firm Fixed Price basis so we can have warranties on our delivered products. “OK – I don’t know what Agile is” “Well, I can’t tell you what all of my requirements are, I can’t tell you exactly when I need it delivered, and I cannot tell you how much its going to cost - but I want it FFP” “and I thought to myself – Challenge Accepted!!!”
- Separate technical features from contractual requirements Repeated process for the delivery of working product Apply the rules of agile into the rules of the contract One of the challenges I hear often to creating contracts for agile is that we don’t know what we are buying, that there are no requirements, and that tech is always changing and too full of flaws so it is hard to have accountability. Don’t write into the contract all of the things the system must do - because that is where we will have to modify it when that changes or we forgot something - new technology comes out - etc. Agile methodology has rules already - user stories are the requirements, projects are managed through product roadmaps and prioritization, iterations are the timebox, product that is production ready is the deliverable and the definion of done is the acceptance critiera - the solutions that we contract for is how that process is going to be repeated, how quality of code is maintained
- Understanding the contract type that is necessary is important - firm fixed price is the lowest risk to the government and requires a stated deliverable- as i previously mentioned- that can ben the iteration when you use time & material you’re buying best effort and are not guaranteed working product as the outcome Think Small: Modular contracting, a method promoted in the FAR, aligns perfectly with agile software development –it is keeping the period of performance small-six to twelve months- , the contract is less complex and therefore easier to compete quickly, less investment in the solicitation process for both government and industry, and you see what is working or not without a large investment. Allows for testing the probability of success on a small scale in government contracts it can be harder to get out - so making sure that we code in the open, that the documentation is kept up as part of the agile process, and minimizing proprietary solutions can help ensure that if we need to change directions - we are not held hostage to the acquisition process.
- The Small Business Administration started working with the US Digital Service in March 2015 to focus on improving the process for Small Business Certification Programs –FY15 saw $91 billion awarded to small businesses. Streamlining the certification process will facilitate access to federal contract opportunities Of the 25% of federal dollars that went to small businesses, a successful digital service implementation will increase access to the market share for socio-economic categories We assisted them with a digital service acquisition focusing on agile software development methodologies. The acquisition was conducted in 3 in a half months utilizing a phased approach to acquisition: The solicitation was designed in such a way to focus on the stated objectives, initial priorities and it asked for companies to provide HOW they would utilized Agile Software Development methods to meet those objectives. Phase 1 was an opt in for all of the Government Wide Contract holders Phase 2 was for a technical concept and past performance – we wanted to reduce the burden for these small business in the competition period by not requiring lengthy technical proposals from those companies who were not going to provide a high value solution Phase 3 – formal Performance Work Statement and Oral Proposals from only the top contenders. By November they had their modern technology stack built and by December, the first product- Am I eligible – was launched publicly – From the end of March when the need was identified to December it took only 9 months to get product out the door -
- The federal government spends $80 billion a year on IT but does not receive $80 B worth of value – Contracting for Agile development means finding the companies who make it their bread and butter and giving them the trust and flexibility to succeed in delivering the objectives that meet the mission of the government agency – Agile allows for more money to be spent on actual product and not on contract overhead – which ultimately stretches limited budgets and gets solutions into the hands of those who need it