Jim Highsmith is somewhat of a luminary in Agile circles. The co-author of the Agile Manifesto, which guides the Agile project management philosophy, is in Australia for the Thoughworks Live conference, which focuses on helping large enterprise be lean and innovative. He spoke with CIO editor, Georgina Swan, about the role adaptive leadership plays.
Swan: Can you give us some background to 'Adaptive Leadership'?
Highsmith: I've been doing this for quite a while, nearly 20 years now. We, the Agile industry, have done a pretty good job at the delivery level; it has really been focused on fast delivery, teams and bigger projects and more distributed projects and those kinds of things.
We haven't been as successful [in] getting organisations as a whole - either within IT or outside IT - to understand this message of agility. We haven't had a decent response to the questions from middle managers in big organisations: What do I do? What is my role in this Agile transformation?
In those terms, adaptive leadership is focused around three things. Number one is why does it make any difference? Why is it important? And it really is around building a responsive enterprise. I make the distinction at a strategic level about basic strategy of responsiveness versus a basic strategy of efficiency. The ultimate expression of responsiveness is continuous delivery; being able to deliver daily or weekly or monthly impacts an organisation far beyond just IT. [We look at] why an organisation need to be more responsive and where? Particularly in the light of what's going on in the world and at business today.
Number two is: What do Agile Adaptive leaders need to do differently? We know what development teams do, but what about managers? They have a big impact on delivery and development. I gather those things under the heading of 'continuous delivery' a 'continuous stream of value'. The emphasis there is on the value - what are the most valuable things we could be doing, so that a little bit of the lean approach comes in there.
What do you mean by this concept of continuous?
It is an idea of a continuous delivery engine and the fact that we have to work on the engine as we do things more frequently. In a traditional environment, where I deliver a good application once a year, I think I can afford not to do some things, like automated testing and continuous delivery. If I want to undertake releases of my product once a week, on the other hand, I have to keep that engine fine-tuned. And so I have to do things like reduce technical debt, keep the quality high, those kinds of things.
So, the first job of an 'Agile' or 'Adaptive' leader is this continuous stream of value.
The third thing is asking: How do I have to be? What are the values and principles that will enable me to create an innovative organisation? It's things like being more adaptive, looking at the world to be more evolutionary as opposed to plan/do, I want to envision, explore. So there are some other aspects of that.
You mentioned the concepts of value and being a lean organisation. How do you see value given it's one of those esoteric concepts?
There are a couple of things. One is to calculate value either on an absolute basis or a relative basis for features. We do that for cost, but we don't really look at value in a very precise way. Then there have been at least three separate studies that I know of that indicate that in excess of 50 per cent of all features in software are rarely or never used. And so why go that last 10 or 15 or 20 percent? Let's try to cut projects off early and so that I can get more overall throughput. It means that I can spend more resources on things like reducing the existing technical data in systems, by doing the investment that I need in continuous delivery, doing the investment in automated test suites.
Take, for example, Salesforce.com, which is really a very agile organisation. Its pipeline for continuous delivery now includes more than 100,000 automated tests. That enables them to do some things very quickly that you couldn't do otherwise because you just can't run that kind of test suite manually on any kind of regular basis.
Reducing work in process, for example, is another aspect. Far too many organisations have far too many projects going on concurrently and they timeshare people to the point where they don't get anything done. So there's a lot of that lean kind of idea.
So how do you adapt? How do you put those mechanisms in place that allows that to happen?
I find a lot of organisations don't spend enough time talking about a why. They don't have a well-articulated rationale for being more responsive in their organisations. They say things like: We want to be faster or we want to have higher quality or we want to reduce costs. But they don't really take it beyond that to an organisational imperative that relates back to responsiveness.
It has been interesting -- I thought it was pretty simple to talk about strategy in terms of responsiveness versus efficiency, but it has turned out to be something that people have really been interested in. It's not to say one is important and the other was an unimportant, but in certain organisations, one is the objective and the other one is the constraint.
And it can be for an organisation, a business unit or a product. You can have some business units in an organisation that are responsive oriented and some that are efficiency oriented. But it's a fundamental discussion point that people in the business need to have around where do they need to be responsive and how do they need to be responsive.
One of the things that I advocate is evaluation on cycle time. From check-in to deployment, for example. Microsoft's timeframe is about eight months, Amazon's is about eight hours. That doesn't really say that one is right and one is wrong. But that's something that people need to look at.
Why do organisations need to be more responsive?
One of the things that's really important as we move into an era where responsiveness is that people begin to nail the measurements that they actually need to take. One of the better sources of sort of rationale was an IBM study that was done the end of 2010, which looked at the responsiveness of organisations and what CEO's were interested in. They interviewed about 1500 CEOs and a large percentage said, you know, business responsiveness is at the top of our list and by the way, we don't really know how to do it.
So we know the issues, but they do require a fair amount of organisational change. And I think that organisational change is going to be driven from a really deep understanding of why we're doing it.
It seems a lot of CIOs are in this boat - they know what the issues are, but nobody's cracked the nut yet...
Eventually, it has to be a culture change. Which is really difficult, but I think it's something that people really need to look at. For example, I talk about having an exploring mindset, which means, moving from a more traditional mindset of plan/do. Instead, I get it to a mindset of envisioning of where we need to go and exploring into that vision. So I don't have a detailed step-by-step plan. I have some boundaries, I have maybe some schedules, I have a vision of where I want to go, but it's an exploratory process. And that's a difficult mindset change for a lot of people.
What does the CIO need to take this on board? As leaders, they need to have a good understanding across their peer network, shouldn't it also extend down within the organisation?
Yes. And that's the big challenge is the middle management ranks. And, in many respects, I don't think it's the middle manager's fault. I don't think that necessarily they've been resistant, but if you use a system where you are measuring certain things that a traditional manager, manner, then they are going to respond to those traditional measures. Measurement and performance systems are important, but you must also give them a better idea of what it is that they need to be doing and then work on the culture side.
For example, if you tell people to be exploratory and adaptive, but on the other hand you say they must conform to a plan of scope, schedule and cost for a particular project, you are giving people mixed messages. And they are going to respond to the performance measurement system rather than to the idea of being exploratory.
Follow Georgina Swan on Twitter: @swandives
Follow CIO Australia on Twitter: @CIO_Australia
Follow Georgina Swan on Google+