Texas.gov is upgrading the state’s systems faster than people are used to and they’re doing it using agile software development -- a method that brings cross-functional teams together throughout the life of a project, to collaborate and course-correct along the way. The approach results in a finished project that can look quite different from what was first envisioned, given the evolution of technology and customer needs. There are various agile methodologies, each of which contain different components, such as self-assembling groups and co-location of teams.
Agile development is a deviation from the waterfall approach to software development, a linear methodology that has long been the standard in government and elsewhere. In waterfall, each phase of a project is completed before developers move on -- the approach is less flexible, and more focused on hitting milestones and budget targets than delivering optimal value. Waterfall is widely criticized for sometimes leading to projects that are out of date before they are even finished.
In August 2012, the Texas Department of Public Safety (DPS) and Texas.gov completed an eight-month project to create a new vehicle inspection service. The endeavor was finished faster and more cheaply than previous implementations, and the state has continued adding functionality for additional services and departments, all using agile development. Eventually, the DPS will host a central portal for services offered by business units and departments across the state.
DPS and the team from Texas.gov created a tool that allows vehicle inspectors to complete the process online, and now includes other functionality, such as inspector certificate renewal. The new vehicle inspection service replaces an expiring vendor contract, said Erin Hutchins, director of portal operations at Texas.gov. The old system took the vendor 18 months to develop. They were looking for a way to do things more efficiently, Hutchins said, and that’s why they looked at agile software development.
“We’ve done projects of varying size, scope and scale with all sorts of different project methods over time,” she said. “Most of the time we had done things using waterfall [development methodology]. What we figured out was that by the time we got through a requirements process for something of this size … we have actually 15 minutes to build the application. You then go through user acceptance testing where you may or may not have actually met the needs of the business unit and the Department of Public Safety and then you have no time to actually respond.”
Using an agile methodology allowed the teams from the DPS and Texas.gov to work together more cooperatively and stay on track as they worked, Hutchins said. Three teams of 10 employees met every two weeks to discuss what they had developed and make adjustments to keep the project on course, she added, rather than waiting until the end, hoping that everything turned out right.
The reduced development cycle made people more accountable, and gave everyone an increased sense of engagement and reward, she said. Everyone, including the customer, could all see the work being done along the way -- if they were off course, the team could make a small adjustment and it wasn’t a big deal. Hutchins explained that she had been part of large projects before that didn’t assess the completed work until months or years had passed. Sometimes the work wasn’t done correctly and a lot of time was lost.
Using a different methodology can be a big change for people, said Peter Eichorn, director of technology for Texas.gov. For that reason, he said, before they started the project they led a boot camp for both developers and managers so everyone understood how agile development works. A lot of people say they’re interested in agile development, Eichorn said, but it takes commitment – you have to stick to the process the whole way through.
In many ways, an agile methodology fits how software development works much better than traditional methodologies, according to Eichorn. Often, so much is learned during the development process by everyone involved, that it’s hard to develop an end-product that looks exactly like what was initially planned. People come up with new ideas and make realizations as projects go on, so it can be constricting to be on a rigid development cycle. The perceived lack of structure can be scary for some people, he said, but that’s why they met every two weeks. “You don’t miss by inches after a year -- you miss by a lot,” he said. “Here, you miss by an inch, you just adjust it and it takes a lot of the drama out of it.”
The team did face many of the challenges found in all software projects, regardless of methodology, he said, like difficulty knowing when the project is “good enough” and developers can stop trying to take on the feature backlog.
One of the best things about using agile development, Eichorn said, was seeing workers from the two departments working side by side, solving problems together. The change in culture manifested itself in the quality of their work.
Since finishing the initial development period, the team has continued adding functionality migrating data from the old system. Their plan is to continue adding functionality for more services and eventually more departments. “The concept is to get to a place where all those services now live in one database, that they leverage an online product framework that allows for simple configuration and new services over time without tons of maintenance and specific development for every one of those online services,” Hutchins said.
Texas.gov has used agile development for internal projects in the past, Hutchins said, but this is the first time they’ve teamed up with another agency on an agile project. Bringing developers and the business side together, though, is one of the things agile is good at, said Sean Kenefick, research director for Gartner.
One of the pitfalls of using agile, Kenefick said, is that people sometimes start skipping important parts of the methodology and the work suffers. “Agile has gained ground over the past few years,” he said. “People are seeing it as an alternative to waterfall. The problem that folks are having is that they are limiting agile to just the development phase. They don’t necessarily include the requirements aspect to it.”
Like going to the gym, results from agile development depend on personal discipline. “The goal of agile is providing a higher quality and more useful product to the end user. As a byproduct, you sometimes get it faster,” Kenefick said. “The important goal is that you are providing the user and the business with what they really need.”
(By Colin Wood)