It's not something you see every day in IT: A team member was walking down the hall and got a "giant hug" from an end-user who was thrilled with the new software being used in the call center.
Greg Newton, vice president of technology at Asurion, said that moment happened because of a fundamental change in how the company develops software. "Satisfaction went way up, and we saw the waste in what we build go way down," he explained. His internal users "wound up feeling we weren't some kind of nameless, faceless IT team. Because of the way we worked with them and got feedback, we saw the relationship change as well."
Newton will talk more about his team's new development techniques at the Interop ITX conference on Friday, May 4. His seminar is titled, "Rapid Product Innovation with Lean Techniques and DevOps."
Of course, the notion of "rapid" is "somewhat relative to what you're doing now," Newton explained. "We transitioned not from waterfall, but from Scrum – a more traditional form of agile." With their old development method, they could release a new software version every two or three weeks, compared to five or more now.
Whatever you're starting with, there are good odds "you were wrong about what you analyzed, or things changed, and ultimately a lot of what you built just wasn't right," Newton said. So now the focus is on "how fast can we go from an idea to experimentation and learning" – making quick changes that align with specific metrics that the business cares about.
For example, with e-commerce, how quickly a customer goes from browsing to completing a purchase might be one measure of success. "And, if we change something that leads to increased conversion stats," that is more important than doing the "ultimate design" that takes too long and may not yield what you want anyway.
The goal now is to develop "the smallest version that provides the intended value and allows measurement. If we're wrong, we've got only a few days invested, and because it's small it's easier to make pivots."
To get here, Asurion invested in cloud technology and in DevOps to automate everything that could be automated, from build to deployment to test. "It's a combination of things that, when put together, help us move fast," Newton said. In testing, for instance, instead of doing full functional and regression testing for every change, most of that is now kicked off without human intervention.
"There is a lot of up-front investment" to do this, Newton acknowledged, but now "we can deploy to 10% of our users to see if something works the way we want, or we can deploy 10 times each day without having to take systems offline." The approach reduces both cost and risk, he said.
Part of the transition involved convincing other business leaders to make the investments required, Newton said. Ultimately, it's about how fast you can innovate.
This development model has become possible thanks to the maturity of major cloud platforms, and how easy and inexpensive it's become to provision needed infrastructure and services. A second major development has been infrastructure as code, which essentially automates the cloud provisioning process.
"With a cloud service, you still need a human to sit at the admin console and create servers and configure the load balancer," Newton explained. "There's still a human in the loop, and that can be prone to error." So now there are tools to define what his team wants – a cluster of 10 servers, for instance – and those tools, in turn, communicate with a cloud service's API. "You just kick off the process and it goes through and does it all way faster than a human can do it."
There are some differences in how teams are organized, and how priorities are agreed upon, he said. With a traditional model, "you fight the priority battles" for every release. Now, because key performance indicators (KPIs) are at the center of the process, "you fight the vast majority of those battles up front; you agree on what's really important to the business, then create teams and focus on those KPIs."
One challenge, he said, is that things can become a bit messy. If you have multiple teams focusing on different aspects of an ecommerce website, for instance, and each of these teams is experimenting at the same time, it's possible for the whole to feel chaotic from a design perspective.
"It's like the Frankenstein monster – it can start to get a little rough," Newton explained. The company does rely on "objective measures of usability" as a safeguard to mitigate these problems, "but it's not all pretty."