By Dick Stark
The needle has hardly moved since the COBOL days. Projects are taking longer, have less success, over-run to a greater extent. Meanwhile citizens are ill served. What is needed is not making things more agile, but simplifying the whole ponderous, error prone process where a majority of stakeholders consistently favor more process complexity, slower speed in the name of quality, and never penalize the wizards who preside over this domain.
–Reader comment in response to Steve Kelman’s FCW article, “What’s happening in agile,” March 15, 2016.
Is agile Government an oxymoron? The above reader certainly thinks so. Although I don’t have specific data that shows the Government is any worse than the private sector, several failed or poor projects come to mind: Lockheed’s botched $170M 2001 FBI modernization project, and CGI’s removal from its $678M 2013 Obamacare website contract. The failed FBI project is often cited as a case study for agile development over the traditional waterfall approach. It’s more difficult, however, to pinpoint blame with the CGI project. Most reports examine CGI’s difficult task of integrating its back-end development efforts with another vendor’s front-end software interface. Without a good way of testing software end-to-end, software debugging is more challenging and time consuming. With tight project release deadlines looming, inadequate software testing resulted in software that was released too early.
According to Steve Kelman’s recent article, the Government is making significant progress in in agile software development processes. Kelman specifically referenced the work of Mark Schwartz, CIO at US Citizen and Immigration services (USCIS), one of the leaders in the government’s move towards agile. Specifically, Schwartz is a proponent of continuous delivery as a way to shorten the software development life cycle by automating the delivery process (think Atlassian toolset) and making software releases smaller and more frequent (think Amazon). Smaller faster releases enable users to quickly test, and the developers to quickly fix any issues. The larger and more complex the release, the more likely that multiple and more complex defects will be discovered.
Schwartz says that his plan for USCIS is to go 100% agile “cold turkey.” This means that all his new IT projects will offer continuous releases. This requires automation and effective control processes to roll-back to a previous version if necessary.
Think of the implications for our work with large ITSM deployment projects. For example, rather than have a Phase 1 delivery stretching over six to nine months and promising integrated incident, problem, change, and asset management, why not do incident in three weeks, followed by change management three weeks after that? Of course, some of these modules are closely integrated meaning that care must be taken to separate each release.
In a new DOD agile ITSM Remedy project just underway, RightStar is using Agile / Scrum tools to meet the tight timeframes imposed by the customer. In addition to compiling an expert deployment team, RightStar is utilizing excellent DevOps practices for success such as collaboration, project transparency, better workflow, and improved communication. The overriding objective: meet the customer’s tight timeframes and show that both rapid Remedy deployments and agile government development projects are definitely NOT oxymoron’s.