“Agile” has been a highly successful approach to software development since the start of the 21st century, though its conceptual roots can be traced back to 1957. Are Agile's principles of adaptive planning, evolutionary development, early delivery, and continual improvement applicable beyond IT to an organization as a whole? Ola Chowning believes so, & she should know. As head of ISG's Enterprise Agility practice, Ola is calling on organizations to innovate technologically in order to increase their business responsiveness. By leveraging emerging technologies like DevOps, cloud, and automation, she helps businesses greatly improve the speed at which they respond to market changes. The key first step Ola advocates taking towards increasing that velocity though is surprisingly not technical at all.
Below is a transcript of the interview.
Welcome everyone, to Intelligent Automation Radio. Our guest today is Ola Chowning from Information Services Group, better known as ISG. ISG is a global technology research and advisory firm, and Ola leads ISG's enterprise agility practice in the Americas. She is an IT transformational thought leader with over 25 years of leadership experience within various industries helping enterprises make transformation change, and is fluent in enterprise agility, DevOps, cloud, and automation. Ola, welcome to Intelligent Automation Radio.
Thanks for having me, Guy.
Ola, I started my career as a technical person before transitioning into more of a business role, and where you claim fluency in a variety of technology concepts, I simply like to say that my ability to translate between English and geek speak makes me bilingual. Maybe one day Rosetta Stone will come out with a training program for technobabble.
Ola, you advocate for something called enterprise agility, which calls on organizations to innovate technologically in order to increase their business responsiveness. As a first step, enterprise agility requires adopting a culture of learning, but some IT staffers view innovations like artificial intelligence and machine learning, automation and other technologies, as threats rather than opportunities to learn new things. How do you recommend IT executives overcome that kind of resistance within their organization in order to push forward and become more agile?
Well, like any change that we see happen with an organization, organizational change is really twofold. There's a top-down approach that you need to take which basically says making people comfortable that they have the ability to change, and that you want them to change, and why the change is good for them. From a leadership perspective, a lot of it's about displaying the willingness to change, showing the employees in the organization that change is a good thing and you indeed expect it to happen. Showing them what good looks like is also a very good idea.
As an employee, I think, particularly in technology, we should be relatively comfortable with change. Technology has been expanding exponentially for many, many years, and even for those of us who are new to the industry, we have to stay up on what's happening from a technological perspective. We should be relatively understanding about how change can help us in our careers, can help us make our jobs more interesting, as well as more successful from a company viewpoint as well. How we look at the business, how we're helping the business, we should be looking to continually change.
Having said that, we have a tendency to make it a long-term goal. We have a tendency to say, "Let's go take a class." And we'll go learn something new as if it's a big expansive thing that I can just go take a class and learn. What we're seeing happen with the technology changes, particularly in areas like automation, is that it's the application of the technology. That's really what I need to learn. Technology itself, especially for a technologist, is relatively easy to understand and relatively easy to learn. It's how I apply them that really is the learning that needs to be done.
That is going to be very specific to the business and the business value that you're trying to achieve, which means that I need to quickly learn, in a very iterative fashion, how what I'm doing is actually affecting value, is it affecting it in a good way, is it affecting it in a bad way, and be able to continue on those good paths, and maybe relinquish the ones that aren't so good.
Continuous learning is the key. It's not about just going off and taking some classes or learning a new tool. It's about the application of it to affect a business value that I'm trying to affect.
What you said brings to mind an old cliché that in IT the only constant is change, so it's a very good point you make, that if you're going to be in this field, you need to be prepared to change. Please tell our audience about the operational model for enterprise agility. How should IT executives organize their teams for change to best facilitate agile success?
I think the main concept behind enterprise agility is that not everything you do within your organization needs the same level of agility. I have business functions that are relatively common. They are common business processes. They have relatively similar functions that I need to perform between companies. What I do within HR is very similar to what the company across the street does within HR. There are areas within my business that, while they need technology, and I'm not suggesting that they don't, the level of agility they need, the level of constant learning, the level of constant change, constant improvement, rapid market response, is really only necessary in those areas that typically are business facing, consumer facing, or business enabling.
What I need to do within enterprise agility is recognize the fact that I don't need to have the same level of agility as everywhere. Where I do need to have the level of agility, though, I need to be able to truly practice the principles of agility. The principles of agility would tell you I need to be in a highly collaborative atmosphere. I need to be able to make decisions in a very rapid way. That's what drives velocity, and the ability to respond to the market at the speed that the business needs.
What drives that velocity is having smaller teams that are enabled to make those decisions, that are focused on a very, let's call it a smaller scope of business value. Instead of trying to manage or look across the constraints broadly across many, many areas of business function or business value, I'm looking to draw my attention in a smaller group of team members, a smaller amount of capabilities, across a smaller scope so that I can use that smaller team in a highly functional way.
What do I mean by that? What I mean is that in a smaller team I have the ability to, against a very small scope within a business function, I can turn my attention on the whole team over to operations when I need to, or I can turn the attention of my whole team over to development if that's what I need to do. My ability to swarm to what's necessary and priority is much easier to do when I have a small team that's focused on a single set of objectives.
What has a tendency to happen over time within IT in the past, in our legacy environments, is we're trying to manage to a long list of priorities that are conflicting against a constraint of a large group of people who are all trying to be used against those same priorities. The real theory, and it's really not even theory anymore, it's been proven many times, is that the smaller you get from a teaming perspective, and the more focused you have them on a smaller group of business objectives, the more likely you're going to get the velocity that you need in order to respond to those objectives and be very, very efficient.
These smaller, more focused, more efficient teams capable of greater velocity, are these what you've previously talked about as empowered teams?
Correct. Empowerment is an important part of this discussion, and it's actually probably the most difficult to achieve from a cultural perspective than most legacy organizations. Empowered teams means that the team itself, and they're usually relatively small ... We see teams most often under 20. We're talking 10, 8, 15 people, and they need to have the decision rights and the authority to do what they need to do in order to meet the objectives. There's not a command-and-control, a hierarchical structure. We don't want them to be delayed to make the decision that they need to make in the moment. We're expecting them to have the accountability with the business, by the way, with the business as part of the team, to make the decision on what is their highest priority today. What is their highest priority in this moment, so that they can go and achieve what they need to achieve against that particular priority, and not have the delay of what are typically hierarchical structures.
Now, the culture change comes in in that most of us work in enterprises that are much more hierarchical in how they distribute decision authority. Indeed, IT has been a very control-oriented organization for many years. Part of that is we're responsible for the security of the environment, and for the applicability of the environment from a business perspective. We are the stewards of data. We're the stewards of information. That has a very control-oriented atmosphere.
Part of what we need to do within these smaller teams is ensure that we have the right guard rail so that those teams know what they're accountable for. You can't just have complete anarchy within the team, but what you can do is put in place, as an example, things within your automation criteria that make it impossible for them to take certain decisions without prerequisites being fulfilled. I need to find different ways to ensure that I have the appropriate governance that I need around my environments while still allowing these teams to be highly empowered and very functional in and of themselves, so they don't have the delay of hierarchical command-and-control.
That's the culture change. The culture change is leadership's not used to that. Employees aren't used to that, and a lot of this is about making people comfortable that it will work. We see it work not only just in small organizations, I've seen it work in very large enterprises, but it is a big shift in culture.
Ola, can you please talk a little bit about how automation impacts enterprise agility with the cultural change and the empowered teams that you've just described?
Absolutely. One of the precepts that we see happen within high velocity, particularly those teams that are around IT products that have components, I'll call them full-stack components, application, infrastructure, all usually moving towards some user interface. That sort of solution, that sort of IT product, today in most organizations that are looking for high velocity in a differentiated product set are using automation. They're automating their deployment pipeline. They are scripting what they need to achieve during testing. They are not moving code through a person and taking action. They're moving code into production, as an example, turning features on and off, even setting up infrastructure through code. Because it's happening through code, it's happening in a very automated fashion. I'm no longer having to touch things to get them done. I'm sending instructions, if you will.
As we see the world as code, which is what's starting to happen, effectively we're seeing the ability to automate those things that, in the past, have been pretty manual. If you think about things like our ability to change security protocols within parameters in an environment, through firewalls and those sorts of things, or even stand up a server and have the appropriate storage, and the appropriate operating model there. In highly optimized environments, and particularly in the cloud, what we see are orchestration capabilities that'll automate. I simply send an instruction and it happens. I now have the environment I need. I now have the storage I need and have the operating system that I need, and I can now move the code in and out.
That automation, of course, drives velocity, but that automation also should include those control or governance aspects that need to be there, the security that needs to be there, the auditability that needs to be there, the monitoring capabilities that need to be there. It's sort of an old adage that says I can also go out and write code that does a very bad thing, or I can write code that does a very good thing. It's very similar in these new environments. I can use automation to do very good things, or I can use automation and maybe don't have all the things related to it that I need, but automation is what helps drive us to the velocity that we need.
Even within small empowered teams, if I need to take action, I need that action to happen very quickly, and automation is what's helping us drive that velocity in performing the actions that I need in order to respond to the market.
If you are an IT staffer in an organization adopting the enterprise agility mindset, what new skills or new perspectives should you acquire to best succeed in this paradigm?
That's a great question, Guy. The one thing that most IT folks will have a pretty good sense of is just understanding technology at a conceptual level. But what happens in these smaller teams is that I need more than conceptual. I need to have some hands-on knowledge of how to do not just my usual specialized skill, maybe I'm a tester today, but I have a very specialized skill in testing, but in these smaller teams I need people who have multiple skills. I need them to become much more generalists. I need that tester to start to learn how to also perform functions that are more along the lines of developing, or customer service, or monitoring and operating, responding to events. I need them to be far broader in their knowledge and their capabilities.
That rapid learning is something that most of us have somewhere in our tool chest, and we need to really brush it off and be prepared to learn a lot of new things, and be open to taking on different roles within these smaller empowered teams.
Having said that, the one thing that is really critical in today's environment, and particularly in these very rapid, small DevOps teams, is my ability to script. As we see everything as code, and I can direct infrastructure via scripting and via code, and I can direct even down to network bandwidth via code, I need to be able to code. I need to know how to script. Scripting languages, I think, are going to become a really hot commodity. I think they already are, and understanding how to use automation tools would probably be another one, and really any automation tools, because once you understand how automation tools work, going from tool to tool is a relatively simple step.
What one piece of advice would you give CIOs, CTO's, other IT C-Suite executives that are considering whether or not to dive into enterprise agility?
I would give them a couple of suggestions. One is that we have a tendency within IT to think of long transformation programs. We think in a very waterfall manner. It's just how we've been doing it for years. We think of a transformation as a long pole in the tent, and at the end of it there's going to be some big bang, and everything's going to be in place. Where we see companies being most successful is when they take a far more agile approach to transforming their organization. That usually starts with teams that are already probably leaning this direction, if not in this space. They're usually more in the digitized channels within an organization, so if you have, as an example, e-commerce, you're usually going to have some sort of pilot team, or front runners, or even new capabilities that you need.
If you start with those smaller groups of teams, such as in a pilot, what has a tendency to happen is you get practice. You understand how it works within your organization, and for the rest of your organization, they get a really good picture of what good looks like so they can actually see it working. They actually, it's not some theory. They can actually see it in practice. So, starting small, eventually expanding.
By the way, that expansion, in our experience, happens far more rapidly than you think it does. First of all, the business starts to see those pilot teams be successful, and they want the same success, and the same velocity, and internally, in your IT organization, your technologists see that success, and see that velocity, and they want to play a part in that too. You start to see a real expansion happen, not only from the top down, from the business, but also from the bottom up within your IT organization as well.
All right. Looks like that's all the time we have for on this episode of Intelligent Automation Radio. Ola, thank you very much for joining us today. I've really enjoyed our conversation, and thank you again for being our guest.
Thank you so much. Have a great day.
Ola Chowning, from Information Services Group, who leads ISG's enterprise agility practice in the Americas. Thank you for listening everyone, and remember, don't hesitate. Automate.
About the author
Ola is an IT transformational thought leader with over 25 years of leadership experience within various industries helping enterprises make transformation change. She is a seasoned professional with expertise in emerging delivery models that contemplate the rapidly changing technology landscape. She has advised corporations in the opportunities related to emerging technologies, and is fluent in Enterprise Agility, DevOps, cloud, and automation. Ola leads ISG's Enterprise Agility practice in the Americas.