Open source Robotic Process Automation tools let IT teams explore RPA without starting from scratch or committing to a commercial vendor quite yet.
Vanguard CIO: Is what you're doing "true" agile?
Can your infrastructure and business keep up with your developers? Here's how we enabled teams to go from ideas to working software much faster
Recently, I went out after work with a friend who wanted to pick my brain about agile. He had just landed a new job and his new organization was adopting agile principles. Excited for him, I began asking all kinds of questions. How frequently do they deploy software? Were they building microservices? Were they looking at public cloud?
I watched his excitement drain a bit as he explained that they deploy relatively infrequently and had not discussed “breaking down the monolith” or cloud. It’s hard to say you are doing “true agile” when your deployment methods make it difficult to continuously deliver software. I reassured him that I understood, and that not long ago we were in the same boat. We were doing sprints and scrum, but we were not quickly delivering minimum viable products.
[ Are you hiring DevOps engineers? That could be a mistake. Read The great "DevOps engineer" title debate. ]
Looking back, the Vanguard leadership team took a trip to visit several startups that were potential disrupters in their industries. They all had one thing in common – they were extremely nimble and could go from an idea to working software incredibly fast. To promote this culture at Vanguard and enable the delivery of what we call “Business Value at Startup Speed,” or BV @ SS, we developed a pyramid to illustrate our journey.
To me, this pyramid is a lot like Maslow’s hierarchy of needs. Foundationally you need food and shelter in order to reach the top of the pyramid, which is self-actualization.
In IT, infrastructure is foundational to everything we do. Without an agile infrastructure, it doesn’t matter how fast developers can write code. For us, this meant we needed to adopt public cloud and automate existing manual processes around provisioning infrastructure. This created an environment in which our engineers could self-provision, completing tasks in minutes that previously took weeks.
Next, we had to fundamentally evolve how we developed, tested, and moved software from development to production. Following DevSecOps principles, we transformed our application architecture and created a continuous delivery pipeline, which minimized the time and manual steps between when code is committed and when a feature is available to our clients.
Finally, at the top of the pyramid is enabling an agile business. This is not something IT could achieve alone. By adopting lean development practices, we are creating a culture where blended business and IT teams are empowered to collectively test and learn through fast experimentation. We have multiple teams working in this new way, such as our Client Experience teams that are deploying experiments as frequently as daily.
Business value at startup speed
I remember bringing a manager of one of these teams to a quarterly meeting with our former chairman. The team had been tasked with reducing calls generated from a page on our Institutional site. Within about a week, the team had created a hypothesis and developed an experiment. During the meeting, we asked the former chairman to “push the button” to deploy the experiment. He was reluctant at first, being familiar with the effort and historical risks associated with traditional monolithic deployments, but after we shared more about our recent transformation, he agreed.
Within minutes, the experiment was live in production for a subset of users. Even more incredible than the speed of deployment was everything that went on behind the scenes. It passed all the IT controls – including running a full functional regression suite, automated security test cases, and automatically creating a change record, all of which were historically manual and time-consuming processes.
Later, the data showed us that the experiment was a success! Not only had it reduced call volume from the page, but it also surfaced additional opportunities for further reduction.
The journey to get here was tough, and we continue to learn more each day. My advice to everyone is to make sure you don’t get too far ahead of yourselves. Start at the foundation – do you have nimble enough infrastructure and software development practices to enable an agile business?
[ What do great agile leaders do differently? Read How to be a stronger DevOps leader: 9 tips. ]