Try our prototype:
http://agile-ca.civicactions.com/
Webinar on our learnings "How CivicActions Earned a Spot on the California Agile Government Pool" (2017-02-21)
https://www.youtube.com/watch?v=Qf5bs_bKoRY
Watch a screencast of the user experience here:
Government Technology article on our process "3 Tips for Joining California's Agile Government Vendor Pool" (2017-02-22)
[http://www.govtech.com/civic/3-Tips-for-Joining-Californias-Agile-Government-Vendor-Pool.html] (http://www.govtech.com/civic/3-Tips-for-Joining-Californias-Agile-Government-Vendor-Pool.html)
CHHS Foster Hub - The CivicActions Submission to CHHS RFI #75001 Agile Development Pre-Qualified (ADPQ) Vendor Pool
We created a multi-disciplinary team and immediately decided to iterate through six sprints in the scrum methodology, carefully compressed from the normal two-week cycle down to a ligtning-fast two days per sprint. A Product Owner was assigned as the overall voice of the users. We successfully made a connection with Foster Club, a group that put us in contact with real foster parents and case workers, who generously assisted us each step of our iterative developent.
Using Slack, we maintained a closely cooperative team that could react on a daily and hourly basis, as our understanding of user needs evolved through interaction with our actual users, and as guided by our Agile Coach. We maintained a disciplined process, holding formal demos and retrospectives with each sprint, and a complete story board manipulated with Waffle overlaying our GitHub Issues and Stories.
As we have done before, we closely followed the USDS checklist.
Knowing very little about the subject of foster children but having found real users, we wrote open-ended scripts. We began our four user interviews of one case worker and three foster parents. From these interviews we built an empathy map and personae. We then organized an informal design studio and began mocking up sketches and wirefames that we could show to users to get feedback. In parallel to the creation of the wireframes we deployed a website upon which we drove to a functional prototype so that our users could test our app on their actual mobile devices.
We demonstrated wireframes to users in Sprint 3.
The users taught us things not anticipated by the RFI. For example, visitation status changes and finding safe and convenient places for dropoff seems to be even more important than finding official Residential Facilities (from the state's data). Nonetheless we implemented the map of official residential facilities and made future plans to provide a visitation negotiation system. We created a "spike" solution to test our ability to render a map before integrating it into our main code.
As our understanding grew we kept our story map up to date.
We designed our profile based on specific feedback about what is important to both biological parents and foster parents. For example, we learned that a very important profile feature is "preferred time of contact", so we added that to our profiles of parents and case workers. Our users told us it was better to leave this an informal text message than to use a time-based field.
We learned that marking inbox messages "urgent" was very important, so we render urgent messages in red, and that seeing read/unread status of messages helped clarify the status of caseworker communication, so we implemented this as well. We also learned that classifying messages as being related to visitation or medical incidents is extremely important, so we wrote user stories to capture that and placed them into our constantly-evolving backlog, but were not able to complete them.
We got a big surprise when the State clarified that the primary user was the biological parent, not the foster parent! So, following the Agile Manifesto, we immediately embraced change by asking our users to tell us what they believed biological parents would want (visitation arrangement, contact info). Our prototype now has roles for biological parents, foster parents, and case workers.
At present, our prototype displays messages site-wide to all logged-in demo users. Our intent for the tool, again informed by user research, is that it would become a platform where users would log in, select whichever parent or caseworker associated with their account they wish to communicate with, and send and receive messages directly, privately, with that person.
On June 1st our CEO reached out to other firms seeking to be part of the RFI by inviting them to work with us, reuse our work-in-progress software, and even to share in our most valuable resource, our access to actual foster parents. This reiterates our "fiercely open" way of doing business.
By Sprint 5 we had a functional prototype demoed to both a foster parent and a case worker. A foster parent provided user testing of our deployed prototype and extensive feedback during Sprint 6.
In sum, our team spent over four hours discussing this product with potential users, both in our initial interviews and in our sprint demos.
Building on experience, we began in the very first Sprint to implement a automatic deployment system with fully automated testing and fully automated deployment of the candidate build. This used "infrastructure as code" instantiating a new server instance for each deploy, then using Docker and Bowline to orchestrate containers. We have a Slack command that anyone can use to initiate a Jenkins build.
The actual technology is a backbone of Drupal 8 styled with Bootstrap, although a user is unlikely to be aware of that, since we significantly simplified the user interface, and installed it in such a way that it appears to be an iOS or Android app. In actuality it is a mobile-friendly website.
The facilities information is presented on an integrated mobile-friendly map using GeoJSON, MapBox, Leaflet, an open-source mapping system, together with an interactive, responsive table using the Datables library. The API provided by the state is accessed via jQuery.
We follow the USDS Playbook closely. As documentation of this, we us the explicit checklist published by the USDS with specific evidence and answers for each relevant checklist item:
The RFI calls out items (a-q) below as requiring explicit reference. We have not duplicated the headings, but only our evidence for having completed each of the required items.
a. A Product Owner was given overall responsibility (Robert L. Read).
b. Our team consisted of seven persons in the following roles: Product Owner, Agile Coach, Technical Architect, Back End Web Designer, Front End Web Designer, Interaction Designer/User Researcher/Usability Tester, and Delivery Manager. Engineers also doubled as DevOps engineers. More information about the roles we designated, and the personnel we assigned to these roles, can be found in our project roles file.
c. We interviewed four actual users, designed wireframes and empathy maps with them, demoed to them, and performed usability testing with one of them.
d. We used the following Human Centered Design techniques:
e. We leveraged Bootstrap as an open-source style and made a few header and footer design choices. We outlined our reasoning for this choice here. We chose to include the CHHS logo and favicon so that the prototype would include branding as established by the California Health and Human Services organization.
f. A foster parent test user performed usability testing. We used ourselves as additional user testers.
g. Each of the the first 5 sprints involved user feedback that immediately influenced our design. Further, our own Retrospectives captured our learnings from each sprint and our plans to modify future sprints in light of these learnings.
h. Using fully responsive open-source technology, we tested with both mobile phones and desktop environments.
i. We used the following core technologies:
Additionally we used Ubuntu (as the Docker Machine host operating system), Docker, Docker Compose, container operating systems (minimal Debian), Apache httpd, MariaDB, monitoring (uptime), testing (Selenium Builder, se-interpreter), deployment tools (Docker Machine, AWS CLI, CloudFlare CLI), automation (Jenkins, Bowline), PHP, PHP libraries (Symfony) and frontend frameworks (Bootstrap, jQuery, Mapbox, Datatables).
j. We deployed the prototype to Amazon Web Services (AWS), a FedRAMP compliant IaaS provider. Additionally, CloudFlare was used for CDN, SSL and DNS automation.
k. End-to-end tests for mobile and desktop viewports were developed using the open-source Selenium Builder testing framework. Tests were run in fully managed Docker based Google Chrome and Mozilla Firefox Selenium driven browsers, to test our profile and mapping functionality.
l. We used Jenkins to run the automated tests on each candidate deploy and notify us immediately on Slack if tests passed of failed. Tests were automated using the se-interpreter runner and run in Firefox and Chrome browsers.
m. We used an Infrastructure as Code (IaC) methodology to manage all infrastructure and configuration. Upon triggering a deploy with a Slack command, Jenkins runs a deploy script that creates a new "candidate" AWS EC2 server instance with Docker Machine, brings up Docker containers to host the site, installs the site software, runs the test suite and (if the tests pass) switches DNS to make the candidate live. The immediate prior live container is retained online in case it is needed for fail back. This entire process happens with no manual interaction and encapsulates all the configuration (deploy script, Docker Compose configuration and site configuration) in the project Git repository.
n. We set up continuous monitoring of application status and response time using open source uptime software. This produces summary/historical reports and charts, and will send e-mail alerts if an issue is detected.
o. We use Docker together with Docker Machine for Docker host management and Docker Compose for container orchestration and configuration management.
p. The devops-manual describes how to install and run the prototype on a local sandbox, deploy the application to AWS and configure a continuous delivery (integrated testing and deployment) automation job.
q. Our entire software stack is open source and provided free of charge. All licenses are documented in associated LICENSE.md.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent
