3 Pieces of Advice for Making the Transition from Waterfall to Agile
When Jim Smith became the CIO of Maine in January of 2012, it was a traditional waterfall shop. But things look much different now.
“If you look at the industry at large, whether it’s on the federal level or the state level, there’s a lot of disappointments with projects – projects that either didn’t come in on time or didn’t come in under budget,” Smith told Government Technology at the NASCIO Midyear Conference in Virginia, adding that the waterfall method means spending two or three years developing a project.
“Well, the world changes in two or three years,” he said, “so we had a number of dissatisfied customers at the end.”
And the state’s agile journey began.
“I came in and I said, ‘We’re probably right for something like agile, where you can do things quickly, do sprints, and you can give the group something quicker to test,'” Smith said, noting that not everything immediately moved to the agile approach.
In fact, it began with training. Most of Associate CIO Paul Sandlin’s staff, which runs all the applications, was, and is, trained in agile – but training the agencies in agile is also a big piece.
“It’s a cultural shift, because people are used to that two or three years of analysis and design,” Smith said. “And now you’re saying, ‘No, you’re part of a team, you’re part of a scrum, and it’s a three-week duration.’ So as you start, it’s very, very difficult.”
But transitioning is doable, and Smith and Sandlin offered some advice for getting started.
1. Start Small
It’s imperative that agencies start small, because “you’re going to make some mistakes,” Smith said, and also noted the cultural change everyone will endure.
“For me it was sort of a drink of water and sort of gulp a little bit, because you think about scrum, you think of self-governing teams,” he added. “Well, I’m the CIO and people tell me, ‘You know the team will govern itself,’ and you kind of scratch your head, but at some point, you take a leap of faith because you have to make a change.”
2. Think of the Many, Not Just the Few
Sandlin said that while many of his IT staff members were ready and starting to try agile approaches on their own, they didn’t really have the support. But being ready is imperative, and one way a team will show its preparedness is by thinking the problem through “in such a way that they can be representative of all the interests of the agency as opposed to their own individualized interests,” he said.
3. Lean on Available Expertise
Sandlin also noted that there’s a kind of tyranny that exists with the product owner.
“They work it well so that they understand their domain, which is the business space as opposed to the technology space,” he said, adding that they also lean on expertise available within the team for some of the decisions, “because there are good reasons why we do certain things certain ways.”
Learn more about how CenturyLink can help you create the best IT strategy for your organization.
Jessica Mulholland has been a writer and editor for more than 10 years. She was previously the editor of Emergency Management magazine, and she loves that she can incorporate her passion for photography into her work as a part of the Government Technology editorial team.
(c)2017 Government Technology
Distributed by Tribune Content Agency, LLC.
This article is written by Jessica Mulholland from Government Technology and was legally licensed via the Tribune Content Agency through the NewsCred publisher network. Please direct all licensing questions to firstname.lastname@example.org.
This blog is provided for informational purposes only and may require additional research and substantiation by the end user. In addition, the information is provided “as is” without any warranty or condition of any kind, either express or implied. Use of this information is at the end user’s own risk. CenturyLink does not warrant that the information will meet the end user’s requirements or that the implementation or usage of this information will result in the desired outcome of the end user.