00:19:04 video length
Bio Jim Highsmith is an executive consultant with ThoughtWorks, Inc., having spent 30-plus years as an IT manager, product manager, project manager, consultant, and software developer. In 2005 he was honored to receive international Stevens Award for outstanding contributions to systems development. Jim is coauthor of the Agile Manifesto and a founding member of The AgileAlliance.
The Agile Alliance organizes the Agile series conference, which bring together all the key people in the Agile space to talk about techniques and technologies, attitudes and policies, research and experience, and the management and development sides of agile software development.
I’m doing great.
2. Glad to have you here. Thanks for being here. Jim needs no introduction but Jim is indeed one of the 17 original Agile Manifesto signatories. This is the 10th anniversary of the Agile Manifesto and I know that Jim in February, there was a meeting of most of the original 17 here in Utah.
There was. Many of them got together, there was, I don’t maybe half. I wasn’t able to attend that one but it was great to see most everybody here this week.
I did, I talked to several people that had been there and it was a pretty good meeting. It was up at Snowbird in the original place that we had held the meeting ten years ago.
A little bit. I don’t think they went in with the real idea of what the agenda was which is kind of how we ran the first meeting but they did do some things about looking to the future. One of the questions I’ve been asked many times this week is: what do I think is going to happen over the next ten years? And my kind of response is that: well, Agileists don’t predict that far ahead.
Yes, I did. It was a great event. Basically, it was to get Senior Executives together and give them an opportunity to talk to each other; to present to each other; to engage and really talking about how to bring Agility into the enterprise. And there are some people that think that the Agile Manifesto, the original one, was kind of a tipping point for Agile software development. And there are some of us who think we’re sort of that same kind of a tipping point for agility in the enterprise. So that’s what’s that conference was really all about. We brought 60 top level executives together for a pretty intense day.
Well, I think the take-away from the forum is that there are a lot of Senior Execs that are much more engaged in this kind of agility, Agile transformations of their organizations that we might expect because we also had a lot of people that talked to us that really would have liked to come but, you know, for their schedules and all, didn’t quite make it. But for a first time event, it was very successful.
7. How does Agile make its way into the organization and there’s one camp that maybe believes that there’s been a groundswell movement of the troops that the development team says, "We need Agile." And they kind of take it in and it filters up towards the management team. It might be a great process for an early adoption of a new technology but Agile has been around for about ten years now, well exactly. So, maybe it’s time for the management to be filtering Agile out into its organization?
Right. I think you’ve seen three phases of Agile adaption and the first phase was the early phase and I call the road team phase where you would have teams and organizations that would ‘want to do Agile’ so they would go to their management and they would sort of dispensation to do Agile. So they might do one, or two, or three or four projects. But it really is difficult to get it embedded in the organization, as I say, the organizational antibodies would come out and attack.
So, a second era that started four or five years ago in which executives would, say, a CIO or CTO or VP of Engineering would say, "I think I might go Agile, let’s do a couple of experimental projects and see," but it was kind of coming from the top down.
And what we’re saying now particularly in the last year or so is very Senior Executives who are coming in and basically saying, "We want our whole organization to go Agile." They probably had some teams and some projects that have been a success and now they really want to roll it out across the whole organization. So I think I talk to organization this week, 17,000 engineers is what they want to roll it out to.
And I think one of the big differences today is that in the sort of waterfall methodology era in the 1980s, it was pretty much totally driven top down from the top and the troops really didn’t want to do it. And so what happens was when the management pressure let up, it kind of died.
And I think the difference in the Agile movement is that it’s driven from the bottom and the bottom really wants to do it this way and it is also supported from the top. So you get a much better overall transition than you do with sort of a waterfall methodology.
Well, so my first book was Adaptive Software Development and the adaptive part of that comes from a lot of study of complex adaptive systems and how they adapt to their ecosystems; so, that’s kind of where adaptive came from. And then, Imagineering is I kind of imagine the possible and particularly as it relates to organizations and enterprises, you know, what could we do and that sort of where I got that from and a little bit of Disney.
9. You’re with ThoughtWorks on the consulting side. ThoughtWorks studios, I guess, where the products side talks a lot about Adaptive ALM, are they using these same concepts basically that you’re talking about?
Yes, the concept of Adaptive ALM is how to support the entire development process and all the way down to continuous deployment and continuous integration from basically from project management iteration planning, that level through acceptance testing down to kind of automating that last mile. So, that’s kind of the whole ALM that supports the Agile development process.
It is, in fact it’s one of the diagrams that I look at the most with them because I talk about the evolution of Agile from the early years which kind of what I call intuitive development. So we did iterations, and we did a little planning and we did story cards and we did stand-ups but we may or may not have done some of the technical practices, continuous integrations, and those kinds of things although the XP people encourage people to do that.
And I’d say the second phase was really continuous integration. And continuous integration, the checkmark for that is comprehensive unit testing. For example, Steve Greene at salesforce.com who spoke the other day at the Executives Forum says they run a hundred thousand automated unit tests; so, that’s CI.
And the next phase is really continuous deployment, continuous delivery; and the thing about it as you move through that kind of scenario to there and I actually think continuous deployment is sort of the ultimate expression of Agile, it really impacts the business more and more. It could help the business more and more. So you also have to have a more Agile business, more Agile managers in order to take advantage of what continuous delivery and continuous deployment can do for you.
So as I talk to people about those things, I’d say, "That’s not a technical issue, that’s a business strategy issue as to whether or not that’s gonna be valuable for your organization." On the other hand, if you say, "I could deploy new features in this particular area three times a day, how could I take advantage of that?"
11. So first of all, there’s a distinction between delivery and deployment. And there are organizations they are definitely afraid of deployment. Deployment is the end result right? It’s what you’re trying to achieve. But when it comes to deployment time, I talked to a couple of developers last night and the idea of continuous deployment scared the begeezus out of them.
Well, for example, if you look at flickr website, they advertise how many times in the last hour they actually deployed, new features and changes and those kinds of things? So, there are sort of multiple times per day. So, that was for a particular product.
I worked with a guy one time who did iterative development and at the end of every iteration, they had code that was deployable but they only deployed once every two years. And the reason was it was the flight avionic software for the F-15 aircraft and the pilots didn’t want to learn how to re-fly the airplane three times a day.
And so, it really depends on the business situation as to how much actual continuous deployment you really want to do and that’s why you have to get the business involved. But the other part of that is if those business managers aren’t Agile and don’t kind of think about things in those terms, then they would tend to push deployment out longer and longer as opposed to try to say what could really happen if we did that in a shorter timeframe.
12. Sure, so if it’s a critical application to an organization, running the Nasdaq for instance, or the Department of Defense run very critical applications where they can’t afford to have things break, are you saying that these are not candidates for continuous deployment?
No, I don’t think it has anything to do with whether or not it has breakable tendencies because I think continuous delivery and continuous deployment are things in which, you know, high orders of automation, automated testing would actually make it safer. But it has to do with the business use as opposed to the business risk and security of having errors in deployment.
I’m working on two different areas right now. One is I do a lot of presentations and discussions with Senior management about their role in Agile transformation. One of the things that’s going to happen in the Agile industry is we have plenty of material for project teams, for developers, for testers, but by and large, we only ask management for money and some support but we don’t actually ask management to do hard things.
If you think about the Agile movement, it would ask developers to do refactoring and unit testing and work in pairs. So, we ask developers and testers to do hard things.
There are equally hard things that we need to ask management to do: reduce technical debt, really focus on quality, think about doing fewer things and doing them better - there’s a list of things that I’ve been talking to senior management about. It means which is their role in an Agile transformation. So, that’s an area that I’ve been working quite a bit in and also strategies for transformation for larger organizations.
14. I guess the Agile community then has been focused mostly on the front end of the continuous integration on the development on unit testing and really, we’re finally starting to look not only up and down the chain of command but also across the life cycle of development.
Right, and not only across the life cycle of development but also out in the other parts of the organization. There is an IBM study that was done I think last year where they interviewed 1500 CEOs and basically asked what kept them up at night? And what keeps them up at night is the high rate of change, the ambiguity, the uncertainty, the risks in the environment. And so, 90% of the CEOs said, "This is a big problem." And 50% said that, "knew how to handle it."
So, it’s a lot of this is moved towards agility in the organization and not everybody calls it agility but it’s the same kind of thing. It’s really now being driven from the CEO s as they look at the business environment that they’re looking at.
And there are also people out there who are coming completely from the management and organization development space as opposed from the internal IT who are driving it from and need to change management.
So, for example, one of the Executives that’s spoken to our Executives Conference on Monday. He was a Human Resource strategy guy, Senior Vice-President of the organization. They are just now getting to looking at IT and making it more Agile. They’ve been working on organizational agility within the management ranks. So, they’re going the opposite way.
So, it really both are happening as IT organizations get more Agile, they’re sort of driving it into the business and in some organization, it’s going the other way.
16. So there are several things going on there as from an enterprise point of view, there is the kind of training aspect which probably, where there are management, there’s training for developers and then there’s more consulting end of it where once they really understand the basics that they still have problems have to solve, and you’re focus is really on that consulting?
It’s on that consulting and, you know, at a higher level and also to some extent, coaching the Execs on, you know, what Agile is all abut, what their role needs to be, how they need to help out in terms of rolling out Agile within their organizations and the systems in their organizations beyond just the delivery stuff that needs to go on in order to kind of turn the organizations around and make them more Agile as an organization.
17. I think we touch on this but what do you see through the next couple of years for Agile? I’m not going to go out ten years. We don’t need to do that because nobody knows but what’s kind of like just over the horizon here?
Well, I think just over the horizon, there’s been a lot of emphasis on like, as I said, continuous integration and continuous delivery and Devops, continuous deployment. So I think that’s a trend that kind of just getting legs. A lot of big software companies and web-based companies have kind of been there for a few years now but I think it’s making it into the mainstream in a way that it really hasn’t before. So, I think that’s one of the things.
I think this emphasis of management and leadership, I’ve attended several sessions here at the conference on management and leadership issues and they’ve all been overflowing. So, there’s a lot of interest in that area today. So, I think those are two things that are really happening and again, roll out of Agile across large organizations driven from the top supported by delivery teams who are working on it on the bottom and I think that is accelerating.
Yes, I use both those words, Agile and Lean, and some people try to pull them apart, some people will try to pull them together but at ThoughtWorks, for example, we sort of talk about both of those. We do Agile stuff, we do Lean stuff. We go into organizations and help them do value mapping and those kinds of things from a Lean perspective. So, I think the two go together very well, very, easily. The other aspect of that that people are looking at a lot of is Kanban and how do they use that together with that sort of subset of Lean. So, all of those things I think are focused on similar kinds of things, similar kinds of values and principles.
Well, it depends on which camp you’re talking to as to which one and I look at them as sort of equal camps, you know, the Lean people would say, "Agile is just a piece of Lean," and the Agile people would say, "Lean is just a piece of Agile." But I think they’re complementary camps and I don’t know that one needs to be elevated and the other one not.
I think the only other thing I would like to share is the fact that for the first time in ten years, 15 of the 17 authors got together and it was really a great experience and one of the things that happened is, after ten years and some of these people I had not seen in ten years, we hadn’t seen each other in ten years, that we jelled back together very quickly. And we had a get-together on Tuesday night which was just the authors. And the one thing that we decided that we had done wrong in the last ten years is to wait ten years to meet again. And so, we’re not going to do that again. We’ll meet more frequently.