2. Would you mind briefly introducing yourself and your company to the audience?
Sure. Yes. I am Charlie Rudd, I am the CEO and one of the two owners of Solutions IQ. Solutions IQ is an Agile consulting company, we do business all over the United States. In addition we have a subsidiary in Bangalore, India. We do some Agile software development but first and foremost we do Agile consulting, especially Agile transformations, for the larger organizations.
We have been going to this conference as well as to other Agile related conferences for quite some time. This year, five of our employees are doing presentations. I am actually doing one with my brother, who is also my partner, John Rudd, which is about Solutions IQ, the company itself. We are using that as a case study over the last few years, how we have actually transformed the company into an Agile enterprise, as opposed to a kind of more traditional company that it was before. Then there is a variety of other topics that we are also doing.
Shane: Cool. So, let’s talk a little bit about that transformation, because one of the things that we are seeing – or, certainly, I am seeing a lot out there – it is this Agile transformation happening.
Yes,it is interesting. The reason that the words “Agile transformation” is used, I think, is a really interesting topic in and of itself and in other words, to put it in differently, is that if there is Agile change, from a status quo to a new state, which is an Agile state - is it a transformation or could it be done incrementally? I think that the reason why it is called an “Agile transformation” is because there is a qualitative change from where you start to where you end up. It is a transformation, it is a quantum leap and therefore it is a non-trivial organization change management problem or challenge, to say because at the root of it, if you are going to be successful, you really do need to change the culture and the culture is something that is deeply embedded in organizations. The larger they are, the more deeply embedded it is. You cannot simply approach it or attack it on the basis of a process improvement type of an initiative.
That is a good question. For me personally, one of the interesting things is that not only the organization needs to transform, but you, as a leader and a leadership style also has to transform. We talk a lot about empowerment – empowering teams, empowering other people, distributing responsibilities – and although there are a lot of discussion in the Agile industry about the fact that we should empower teams,but there is very little discussion about what that implies for the people that had the power that they gave to the other party.
This is not only an operational question in terms like “What is the role of leadership in an Agile organization? How does it change from the traditional?” but it is also a sort of an existential question for the managers – “Who am I? What do I do? How am I valuable?” And it is interesting – it is actually a pretty difficult problem in many respects, given the fact that a lot of managers who go through traditional business education such as an MBA, etc – they are trained to believe that it is their responsibility to have the answers, to provide leadership in specific terms to people, to make the important decisions, to have the accountability, responsibility to do that.
That is all tied up with the idea of being a competent manager. So, you take an Agile track where you’re trying to push those things out to other people – he starts to question “Well, if I do that, what is there left for me to do?” So, this is one microcosmic question for one party, one stakeholder in a larger organization about “Hey! Not only does my job change a little bit, it changes a whole lot”. In some cases it is completely transformed.
5. And you are doing that across the whole leadership team, across the whole organization?
Yes. The thing is that every organization has a different objective that they are trying to achieve. One thing we know is that everybody says that they want to do Agile now, which is a good thing, but there is tremendous variation across that theme about what they actually intend to do. In some cases, they are quite knowledgeable clients about what they want to do and actually, they are pretty savvy about the cultural change that is needs. In other cases, not so much. In reality, we kind of at this tipping point in the industry, where all of a sudden Agile is not so much the exception, but it is becoming more and more the rule. So, this is an opportunity for the industry but also a risk or challenge that Agile kind of gets watered down to the same old, same old. So, anyway, that is the basic problem. What we try to do with our clients is we try to come in from the very beginning and frame the problem in broad terms.
So, for example, we see that there are different constituencies within the organization that need to be provided services. What everybody knows is that you need to help teams transform, pick up the Agile practices and what have you, especially in development organizations. But there is also an engineering aspect to it, too. Looking at the code base, the legacy code base, how the build is taking place and moving towards from a tools perspective, from an engineering perspective, take what might be pretty bugging legacy code and then turn it into an Agile delivery system. This a non-trivial thing and it does not have so much behavior, it actually asks “What do you do with these assets? How do you change those?”
Then there is the question of leadership change, and this is one of the areas that has been ignored quite a bit. What we were talking about briefly is “How does my world change? What is my job afterwards?” And, anticipating those kinds of challenges and questions at the front rather than wait till they become obstacles, half-way down the road.
What we do is we make a difference between the constituency or stakeholder of leadership who have questions about how their behavior change versus the questions of the enterprise or the organization itself - how should the policies and programs and governance structures be modified, or at least to anticipate the inevitable collisions that take place. We call that work a track for management consulting. So what we try to do is we try to go in, we try to provide, we do an assessment beforehand. We do not limit our assessment to just what the practices are on the team, we look at the full organization and then provide our findings and then talk to the client and then figure out what they want to emphasize.
6. How did you do that – holding a mirror up to your own organization?
Well, that is an interesting question for us. The situation from our perspective – and we are much smaller than most of our clients – but in our case, the objective was to follow the market. Back in 2007 or so, we pretty much decided we are going to commit into the Agile space. We were doing a lot of other things at that time and said we were going to reconsolidate the business along those lines. So, our business objective was to bring Agile services to market more and more. At the same time, what that means is that we have a lot of Agile people, Agile consultants in our organization.
So, what we wanted to do was to create an environment that they would be happy in. And there is a point, we say around 2011 for us, we hit this tipping point where it kind of dawned on us that our job was not to balance the kind of desires and needs of staff while we are trying to bring services to market and more so, what we wanted to do was: “Hey, you know what our objective is? Let’s be an Agile company.
Let’s create an Agile platform that sustains this community and then the value will be generated from that community.” So it is kind of a different strategy and it really became, I think, our key focus of the last 4 or 5 years and it actually remains that way today. The reason why that actually becomes not just kind of a “nice to have” or it sounds cool, it is actually vital for our business and why that is the case is that, if you think about it, if you are a good Agile consultant, how hard is it for you to get a job? There is just not enough, the demand far outstrips the supply. So, from my perspective, when I look at my business, SolutionsIQ as a community, I say everyday our employees chose one more day to stay with us, not go somewhere else. Why are they going to do that? What do I need to do to make sure that that is where they want to stay? Pay is not really the number-onedeal.
I mean, sure, people need to get paid a fair rate, but what they really want to do is be in an Agile environment, they really want to collaborate with their colleagues, etc and they really want to commit to the community. So we are really big believers in the Dan Pink motivational model where you are talking about what knowledge workers want – not so much as money as the ability to become masters at their trade, the ability to have autonomy, independence and to be part of something they consider is more significant than what they can do by themselves. So, that is what we try to do. When we talk about becoming an Agile company, what we are really talking about is creating a community where knowledge workers can meet those objectives and why we feel pretty comfortable is that the more we can do that, the more attractive it will be for people to join us.
Shane: It sounds good. One of the things that you get the advantage of, I suppose, is going into other organizations and seeing, as you are able to see across organizations, themes and trends. So, what are some of the things that you are seeing out there at the moment.
Well, there is always a lot going on, so it’s always very interesting. There are things that we do see. One of them is this movement from what is actually not that old, a buzz word of DevOps, to continuous delivery, to continuous deployment – people use it a little bit differently, different terms. I think what is interesting there is that what we see is a trend from a tools-oriented, technically focused discussion to a broader value proposition which is more about, from an organizational perspective, what do we need to do to shorten the delivery time, to reduce the cost of delay, to shorten cycle times. What is nice about that is that it provides a framework for senior management and technical people to all get along on a single issue – shortened cycle time to delivery. Because after all, 80% of the financial value or more of Agile is all about shortening the delivery cycle time.
So, that is an interesting trend, I think. As I was mentioning before too, is that from an industry perspective, the middle management leadership, stakeholders in organizations have been dramatically underserved. They have just been either not paid attention to at all or just not giving very good advice and so, what needs to happen is – what actually always happens with Agile – if it takes, if it starts to work, is that the ripples of it start to broaden out into the organization. The reason for this is kind of a Lean concept or idea and it is always the case that software development or you add software development and testing or ultimately all that staging that you had to do for deployment but then also upstream where the requirements came from – there is this single value stream and the more it spans that value stream, the more value there is. If you are just attacking the middle part of the value stream, you could maybe do a few cool things, but most of the business value is left unexploited.
I think as you broaden out the value stream more stakeholders get involved and there are more ways that are to get them part of the Agile solution that you are trying to produce.
Let me give you one example – and this is more on the governance side of things: if you think about it and say “OK. We have this current HR system where we review employees on an individual basis and we stack rank them and they decide how to deploy the bonus pool on the basis of that”. So when you do that, what you are saying is that all the individuals are competing against each other for a finite pool. Now, if that is the actual framework that you are operating in, asa corporate governance perspective, it does not really foster the idea of sharing information and collaboration. At the same time, when you move to Agile you say: “You know what? The unit production is no longer the individual, but the team” and if you have a high performing Agile team, from a cultural perspective on that team, one of the things that you do is say things like “collective code ownership”, “that we swarm problems”, that “if the build is broken, we all immediately fix it”. Why am I talking about this? Because this is how we get that continuous delivery to happen, but that is a different set of incentives. Now, what you are saying is that actually collaborating, helping each other be successful is more important than finangling to demonstrate that you, as an individual, are superior to everybody else. So I belabored that a little bit, but I think that in a traditional organization you find example, after example, after example of things that people do not think of as like IT stuff that really start to interfere and impede the ability to deliver all the value that is potentially availablewith Agility.
Shane: Cool. So that is pushing the pipe line or pushing the value right across. What is happening outside of information technology? You talked about transition – how do you make that happen or help that happen.
In any organization, we sometimes use the term “Agile change management” and the reason we use that term and I think that is why “transformation” is a good word, too, because what it does is that by using a little bit different word, you start to set expectations a little bit differently than you have in the past. So, we are strong believers in organization change management and our kind of Agile at scale solution, the backbone of it, is obviously change management which we call Agile change management. Essentially, that is we pull from traditional organizational change management practices those things that work well in an Agile environment. So, for example, strong, active, visible executive sponsorship engaging with different stakeholders throughout the company and actually applying change models such as Prosky’ ADKARmodel, suchas the Satir model of Virginia Satir. These are like nice change frameworks that help set the context for what you are trying to do organizationally and those areas that talk about values and culture. On the other hand, what we do not do, is there is a whole lot of other tools in the traditionally organizational change management industry such as developing a detailed change plan, firing the gun, going full speed ahead and taking the position that “You know what? Now management can’t blink, because if we blink it will show weakness and uncertainty and we know that nobody wants this, so we just have to keep on going”. That is about as anti-Agile as you can get because there’s really no feedback mechanisms, to actually inform that program. So, we filter out what we think is good because there is a lot that you have to do and there is a lot of great things in the organizational change management industry that you want to apply. On the other hand, we want to model new Agile practices and principles because, as we said, it is really a cultural change so we actually have to demonstrate what that is and so, for example, we take the concept of backlogs and dynamic backlogs and make them visible to the stakeholders, we go through efforts to create channels for feedback for different stakeholders that people have - we air issues so that people see that, Yes, it is natural that people are going to have concerns so we talk about those things and then we have kind of a change group with the client, as they get informed by these things and they can change the program. So, those are the kinds of things we do. We try the Agile the model, the Agile practices and values in the change program and filler out those parts of the organizational change management that just do not work very well.
I think that another area that is also outside the technical realm, which is becoming a bigger and bigger deal, and this is a really good thing and that is this focus on the so-called Agile portfolio management and this, again, I think it is an area where there is a kind of a buzz turn that has developed and what we sometimes do is that we also refer to that as “active portfolio management”. The reason why we use that term is because it means that, in many cases for the first time, you can actively change your portfolio after the budget allocation is made. And, if you think about it, you just get an analogy like in a personal finance where there is the buy-and-hold strategy. The buy-and-hold strategy is that you make the investment decision and then you do not do anything. Whatever happens in the market, you just ignore it. That kind of is how the traditional approach works is that there is a fight for budget dollars, allocation takes place and that is essentially treated as a sunkcost. So, you might go on for one or two years whether it is a good idea or not – there just isn’t enough feedback or any kind of policies as to actually make changes, so that is why we like to use the term “active”.
Although the term “Agile portfolio management” has been used in the Agile industry for probably three or four years at least, for the most part, what is referred to is this supply side of Agile portfolio management, not the demand side. So, it is about setting up persistent teams, rather than reallocating resources to projects, those kinds of things. Those are important but with the trend that we are seeing right now is more and more interest and focus on how do we actually make the investments in the first place and how we can actually leverage this average capability. After all, if we set up these persistent teams and they are in a position where they can do really quick starts and then end at the point that there is no more value or there is a market change and they get redeployed to something else - well, they have to have an investment partner elsewhere in the business who is ready to move with them. Even more importantly, those are the people that should be making those decisions and so, I think that that people are starting to grasp this.
Another way to talk about it is kind of an Agile product management process. So, we talked about that value stream really extending further and further into the business itself in terms of literally where do the dollars go, how we allocate the budget. And things like this, for example, instead of saying that once you allocate the budget to a program or a product that can’t be changed, having a way that you can relook, perhaps on a quarterly basis and say “Now you have to prove again that this is a valid investment. If not, we are going to kill it because we have this other great idea over here” and really that has always been the vision for Agile, but there still is a gap between the capability in IT and the business to work in one value stream in a cyclical way together. But, we are pretty excited to see that that interest is starting to be piqued broader throughout the organization.
You don’t really convince larger organizations, you know, in my experience, because first of all it is a ridiculous over-simplification to think that, for example, there is one person that can actually make a decision and then that is what is going to happen. It is a much more complicated or I should say complex base because I think complexity is what we are really talking about here. The other thing is simply because there is some idealized vision of what could be that does not mean that that is the only thing they can do and they have to do it in the next 12 months. More, what you want to do is you have to just asses to see first of all what is the scope of control or influence that you have within the engagement. After all, when we talk about larger organizations, they are not monolithic and in most cases, larger organizations are really collections of subsidiaries which could be sizeable themselves, but you have to first of all figure out what is the scope of influence that you have, then within that, what we try to do is we try to expose as many stakeholders, direct and indirect, as possible to start setting expectations, what can be and what we can actually do.
Another thing in that we try to do with our engagements is that always our objective is to enable the client to do Agile themselves. For example, we have coach-the-coach programs, we bring coaches in, but you want to, and some people consider this an oxymoron, you want to institutionalize your agility, right? And what that means, and this is an interesting thing bringing us back to the management part, is the whole point, is to actually, continuously change your operation according to how things change in the industry. So, in the sense what you are actually learning is actually change management as a core competency and those companies that were able to see what is going on and then rapidly adapt, not just the IT part, but the whole value string, are the ones that are going to succeed in the innovation economy which is not going to go away, it is just going to become more and more and more.
Shane: Charley, really fascinating stuff. Thank you very much for taking the time to talk to InfoQ today. Thanks a lot.
Great. Thanks for having me here.