How to put the Digital Playbook into action
Connecting state and local government leaders
The administration’s U.S. Digital Services Playbook outlines 13 “plays,” or high-level practices for effective applications. Here’s how government IT managers can move those plays into the field.
Software engineering is my passion – not just the technologies but the art of building software the right way. As an advocate for agile development and open source, it is gratifying to see the White House embrace both in its U.S. Digital Services Playbook. It outlines 13 “plays,” high-level practices for effective applications. The Playbook is a great start but is rather abstract, so I will build on some of the plays to provide more specific guidance for government IT managers.
Understand what people need. Resistance to change compels stakeholders to ask for every feature they can think of at the beginning of waterfall projects because it is hard to get anything in later. Most of these features aren’t critical but consume limited budget and schedule. Agile development solves this problem by giving the Product Owner (PO) the responsibility to prioritize stories (more on this role later). If the project ceases tomorrow, you have still generated value.
I would add something to this guidance. At the end of every agile iteration (a sprint in Scrum), there is a demo of the working features to stakeholders. In my Scrum course, I recommend the PO give the demo. Aside from helping to keep the PO engaged during the sprint, this approach emphasizes to stakeholders that the software has been built with them in mind. They also recognize immediately if there is a disconnect with the PO regarding what they need from the software.
Make it simple and intuitive. Here we find a welcome focus on accessibility. With so many wounded veterans, elderly and disabled in desperate need of government services, accessibility should be among the top priorities of government IT managers. For accessibility testing to become a reality, this play needs to dovetail with another: “Automate testing and deployments,” which I advocated in a previous column.
Make accessibility testing part of your automation. While automating accessibility tests may not be as easy as automating functional tests, it can be done. Tools like pa11y can work with a continuous integration tool like Jenkins. If things must be manual, use something easy like Wave and make sure testing gets done.
Simplicity isn’t just key for users; it’s key for developers. In my column on security, I recommend keeping code and architectures simple. Otherwise you sacrifice the core agile value of responding to change.
Assign one leader and hold that person accountable. This one confuses me. The leader of a Scrum team is the ScrumMaster, but the checklist instead emphasizes the PO, the individual empowered by stakeholders to represent their interests to the rest of the team.
Don’t get me wrong. The PO wields enormous influence. The PO drives planning and sets priorities, advises developers on the business value of features and defines acceptance criteria. Agile development demands working software at the end of every sprint. It’s all-or-nothing; the PO decides if the feature is production-quality or not.
One common reason for agile project failure is the absence of an active PO. Too often the PO is legitimately too busy or just fails to show up to the planning meetings or daily standups. As mentioned earlier, having the PO perform demos will fix that.
While the PO is critical, the ScrumMaster is the leader. More importantly, all members of an agile team are accountable for its work. These basic tenets appear to contradict the Playbook.
Choose a modern technology stack. This conveys a commitment to modernization and open source. Amidst tightening budgets, most agencies struggle to address the actual mission – let alone suffer the cost of upgrades and training on new technologies.
Or managers simply feel if it ain’t broke...
Legacy implies the technology works, but I prefer not to see Windows XP anywhere in the federal government outside the Smithsonian. Relying too heavily on legacy technologies ultimately leads to higher costs. Agencies are also less likely to attract the best talent.
The Playbook is right to recommend modern technologies to decrease costs and increase productivity. Here are some suggestions.
Databases (Details in my previous column.)
- PostgreSQL, MySQL, MariaDB (relational)
- MongoDB (document)
- Neo4J (graph)
Web development
- Rails (Ruby)
- Grails (Groovy)
- Play Framework (Java or Scala)
- Django (Python)
- AngularJS, EmberJS (JavaScript)
API development
- Dropwizard (Java or Scala)
- Spring Boot (Java or Groovy)
- RESTEasy (Java)
- spray (Scala)
- Sinatra (Ruby)
- Flask (Python)
- Node.js (JavaScript)
Analytics and visualization
- R
- NumPy, SciPy, pandas, Statsmodels, NLTK, scikit-learn, Glue (Python)
- Apache Spark (Java, Scala, or Python)
- Apache Storm (Java et al.)
- Weka, Apache Mahout (Java)
- Apache Solr (Java et al.)
- D3.js, Processing.js, Crossfilter (JavaScript)
Virtualization
Cloud
A commitment to open-source also applies to software project automation. Tools like Gradle and Apache Maven complement continuous integration and testing tools to build quality into software.
NEXT STORY: Philly taps Big Ideas for small IT contracting