One could argue that California is diving into the deep end in its attempt to use agile development instead of traditional “waterfall” project principles that are much more common in the public sector. Executives leading the Child Welfare Services — New System (CWS-NS) project are eager to work iteratively on small modules that can be put into the hands of state and county workers in a matter of months instead of the several years it takes for a “big bang” release. Project managers hope the approach will be less risky and more responsive to the changing needs of customers.
But the state of California must overcome some cultural barriers in using agile development, because IT has been conditioned for many years to work within the waterfall approach. Peter Kelly, deputy director of the state’s Child Welfare Services Division, said he’s been advocating for agile as long as he’s been working for the state. “There is a different way, dare I say a better way, to deliver value to our customers,” Kelly said. “What’s really important is that we have early and frequent delivery of business value. And we are going to become agile and nimble,” Kelly said with certainty.
[Read Part 1 of this story here.]
Kelly said the state needs to improve its service delivery capability and wants to see constant iteration through two week-long sprints. Kelly, too, said the state needs to build long-term skills for agile in the government, and that CWS-NS could be the beginning of a transition to “dev opps” and out of monolithic procurements. He wants Child
Welfare Services to constantly evolve its technology in the business areas customers need most. There should be a “human-centered” design focus that addresses and fixes the pain points. The goal, Kelly said, is to give something to customers they can use as early as possible, and everyone involved will share the risk. “We’ll share a process together that allows us to buy and receive something that is valuable at each and every step along the way,” Kelly said.
Dan Hon, content director for Code for America, said the request for proposal the state originally developed for CWS-NS — before its move to agile — was trying to implement agile, but couldn’t. “In certain respects it would talk about wanting iterative development; the state ideally wanted iterative development and agile delivery. And I suspect that would be the case for most RFPs in state government that go out of this size,” Hon said.
Ryan Martens, founder and CTO of Rally, an agile development software provider who is a subject matter expert on agile and used it for more than a dozen years with federal and state clients, said there’s growing momentum and enthusiasm for agile in the public sector, and sometimes what it takes most is the willingness to jump in and do it.
Martens said if California does currently lack expertise, it’s not necessarily a deal breaker and can be overcome. He said moving to agile for CWS-NS is a “huge step forward” for California. “I have customers that are measurably 16 times better than they were before. That is a journey, not a destination. That’s something you move your way along to become an expert at, and you get incrementally better,” Martens said.
The integration phase usually is the hardest part of the process for a big, complex project like CWS-NS, so Martens said under the agile methodology the integration should be done first. Develop little components at the beginning, he said, and then make sure the system can run end to end. Then put more meat on the bones. California may not like what it sees after the first six months — this a normal outcome of agile, he said — but the state won’t be three years down the road, with more money spent, up against a big release deadline that isn’t flexible in case a big project component isn’t yet functional.
A big misconception about agile, Martens said, is that it’s a by-the-seat-of-your-pants, “cowboy coding” process where anything goes. The reality is California and other governments need to go faster with a safety net — an infrastructure that automates releases but supports a testing environment, as well as mechanisms to stop when a module isn’t working. “You can add the agility and be reckless, no question; you can add the discipline and slow down to a level where you’ll never, ever ship anything,” Martens said. Project discipline must be built up alongside agility simultaneously, he said.
For a California team that is more accustomed to waterfall-based procurement and development, Martens said there’s no harm in building more time for training into the project schedule if it’s needed or slowing down the iteration cycle somewhat until the organization is fully accustomed to agile. Sometimes you have to walk before you sprint. It’s still faster than a big procurement, which could otherwise take years, and if done right, Martens said it would still be much cheaper than a waterfall procurement that takes years and isn’t guaranteed to succeed.
“The great thing about agile is you are working with feedback, and the feedback can dampen really bad things or it can amplify really good things,” Martens said. “If you find a text-based interface to the child welfare problem is absolutely the right thing to change retention and overall usage, great, let’s spend more time on that first. Maybe
we can bolt that on to the existing system without having to change it.”
