While agile development methodologies and practices have long been part of common practice in private tech and product companies, many U.S. government agencies are still getting their feet wet with fully embracing the concept and finding ways to make it work within their complex contracting arrangements with private vendors.
Under Mobomo’s contract working with the U.S. Geological Survey (USGS) under our contract with the U.S. Department of Interior (DOI), we’ve been fortunate to work for a client who not only understands agile development, but requires it for the development of the USGS.gov agency website, and the underlying AWS cloud-hosted, Drupal-based content management system (CMS), called Palladium.
We’ve been fortunate to work for U.S. Geological Survey (USGS), a client who not only understands agile development, but requires it for the development process. Having a willing client partnership is key to making our scrum processes successful. It’s an evolving path forward as we work with USGS to continue to improve on our roles of scrum master and development team as well as coach the USGS Web Re-engineering team in their role as product owners. But, the process is working! Not only is it working but we’re able to show how the scrum process is helping us to get closer to continuous development/continuous integration (CD/CI), allow us to deliver new features on a regular and frequent basis, and is saving the government money and time.
Our Path to Agile at USGS: Transparency and Building Trust
When we first started this project, the only real semblance of agile processes was the Jira ticketing system. It served as a backlog, but there was no process in place to identify which tickets would be included in an upcoming release and no definition of what a sprint and release process looked like within the project scope. It was difficult to comprehend, there was a huge rush to get the first version of the CMS and the new rebrand of USGS.gov up and running - but it was also a bit unmanageable given the system that was in place.
First, we worked out a sprint cycle which has evolved from a sprint every two weeks to a schedule where we have two, two-week sprints that overlap. This allows for ongoing development during code freezes and more QA time. The schedule flows like this:
| Monday | Tuesday | Wednesday | Thursday | Friday |
| Sprint A: Product Owner Planning | Spring A: Team Planning
Sprint A development begins |
|||
| Sprint A: Development/Test | Sprint A: Development/Test | Sprint A: Development/Test | Sprint A: Development/Test | Sprint A: Development/Test |
| Sprint A: Development/Test | Sprint A: Development/Test | Sprint A: Development/Test | Sprint A: Development/Test
Code Freeze |
Sprint A: Deploy to Stage/Test on Stage Sprint B: Team planningSprint B development begins |
| Sprint A: Test on Stage
Send failed tickets back for rework Dev on failed tickets |
Sprint A: Test on Stage/Test on Stage with Client
Send failed tickets back for rework Dev on failed tickets Deploy fixed tickets to Stage |
Sprint A: Dev on failed tickets/Test fixed tickets | Sprint A: Dev on failed tickets/Test fixed tickets
Sprint A: Deploy to Production/Test on Production |
Sprint A: Client confirms on Prod |
The next step was to improve our communication requirements with our product owners. We were all onboard with using Jira as our ticketing system, reviewing tickets from the backlog to move them into sprints, and then pushing releases based on the completed tickets. But, too often, we found that tickets had to be re-opened after the release. The problem boiled down to communication. We needed a consistent format for how bugs and features were being communicated to us, so that we were fixing the right problems and building features based on user needs.
To solve this, we created templates for how a bug would be entered as a ticket in Jira. A sample format of questions would be as follows:
What is the URL?
How is it behaving now?
Steps to reproduce this issue.
How should it behave?
This was a huge improvement! But, we were still not where we wanted be on our releases. Next, we tackled how QA fits into our process, we revised our workflow to make QA an integral part of the process from the time a ticket is self-assigned by one of our developers, and we built out our Jira workflow to represent this new process.
Do you use agile scrum development? If you do, tell us what you think about our process!
[contact-form-7 id="12689" destination-link="https://mobomo.s3.amazonaws.com/uploads/2016/11/mobomo_brandbook_.pdf"]