Modern technology has dramatically increased the pace of software application development. Within hours a single person can now conceive, create and distribute an app to millions of people. Thanks to the global internet, access and updating of these apps occurs automatically and constantly. Products can be prototyped, measured, improved and updated many times a day. A result of this rapid iteration is the increasing evolution rate and validation of product capabilities that minimizes time to market.
Often referred to as â€œagile developmentâ€ or lean, this process is a fundamental shift in how businesses achieve market adoption and customer satisfaction. By contrast, waterfall development historically meant long and disconnected cycles of requirements, design, development, testing and delivery that stretch interminably and often discover late in the process new opportunities or missing requirements. The cost of development and delivery time using waterfall processes can mean projects become â€œtoo big to failâ€ yet also fail to meet critical business and customer objectives.
Despite the general acceptance of this new agile methodology by businesses, government has not effectively adopted such strategies. There are many valid reasons why government organizations must be more deliberate in their technology solutions - legal requirements, inclusionary capabilities, and formal policies may all direct software development. However too often these processes lead to numerous examples of â€œfailed IT projectsâ€ or high risk programsmeasuring millions or even billions of dollars in wasted resources.
There is a tremendous opportunity for government to learn and adopt these iterative, evolutionary short-cycles in order to serve constituents more cost-effectively and efficiently.
The United Kingdom and United States, by example, have created new digital services focused on creating an environment that is accepting and functional using agile development when possible. They are helping evolve government policy, culture, and IT practices to make it appropriate and effective to prototype and develop software solutions in short, iterative cycles. Along with 18F, they are informing and affecting programs within government as well as vendors that support government.
The USDS Playbook is a practical guide to building successful and modern technology projects. This playbook was as a set of requirements in a recent request, 18F Agile BPA, challenged organizations to concretely demonstrate their ability to apply open and user-centered agile development towards government solutions.
Within three weeks, over 80 companies submitted rapidly developed prototype applications that used a new Open FDA programming interface. 16 companies were recognizedfor â€œ[delivering] amazing, working software in response to our RFQ.â€
GIS for Innovation
We were pleased to participate and be recognized as one of the top submissions to the RFQ. Our Esri OpenFDA Prototype is a prototype, but compelling demonstration of how an integrated platform enables quick and iterative delivery. Our concept was informative and explorable understanding of food and drug recalls that may impact a local community such as a school nutrition specialist, or a healthcare official tracking larger scale health issues.
Working entirely through Github as our collaboration hub, we designated primary user personas based on our experience in the health industry and connected with real people that could provide meaningful feedback. Then our designer created low-fidelity user interface wireframes that we tested in quick 10-minute interviews with our persona users. During daily standup meeting we reviewed the previous day progress, feedback from in-situ user testing, and new or modified development priorities for the day.
Using geography, we were also able to use the US Census demographics data to provide context. In this example, we analyzed the food and drug recalls by state, including the the overall affected population.
Prototypes to Production
Throughout the three week exercise, by performing daily check-ins we were able to measure our progress against the regular cadence. New information meant we could improve our overall project without threatening long delays or building unnecessary code.
This experience demonstrates a very fast process to validate and demonstrate concepts. While this project stopped, it is indicative of the process we employ across the entire ArcGIS product platform. Many teams work in weekly sprint cycles and monthly or quarterly software releases that culiminate in our yearly big releases. Itâ€™s a model for organizations of all sizes, from small startup, to multinational enterprise and government, to effectively respond to changing requirements and user needs.
If you want to know more about how ArcGIS can be used to support open and collaborative government projects, connect directly with Lauren Lipovic at at 703-506-9515 or talk with your local ArcGIS representative.