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.
1. This is Shane Hastie for InfoQ; we are here at the Agile 2012 conference and we have the privilege of talking to Jim Highsmith; Jim is one of the original signatories of the Agile Manifesto and is currently an executive consultant with ThoughtWorks; Jim, welcome and thank you for taking the time to talk to us today.
Thanks Shane, I appreciate it.
Well I’m doing a couple of presentations on adaptive leadership and a subset of that and so that’s my primary reason for being here and I’m also here to sort of help show the flag for ThoughtWorks.
Well one of the things that, you know, as I look at bigger organizations that get involved in Agile; so five years ago, six years ago, it was kind of teams that were involved in Agile and there was kind of rogue teams within the organizations and over the last five or six years there had been more big organizations that have tried to implement Agile; as that’s kind of occurred, one of the things that I had found about the Agile movement is we’ve been pretty good about having practices and procedures and guidelines for what testers or developers or product owners do, but we’ve had less information really for managers as a whole, managers and leaders and really what their role is and what they need to do; so I’ve sort of been looking at three different kinds of things.
Really enterprise agility, in other words: why would you want an enterprise as a whole to be Agile, what are the things about building a responsive organization that responds to technology changes or business changes or competitors changes; so building a responsive organization is really important in many industries.
The second piece of this is sort of – so the first one is why do you need to build a responsive organization. The second one is what does an adaptive or Agile manager need to do differently, what is their kind of role in terms of doing and that doing revolves around being able to deliver a continuous stream of value to customers; so what are the things, what are the levers that they have to really kind of help do that.
Well there’s some levers that managers have to be able to link from sort of the business objectives down to the individual practices of Kanban or XP or Scrum or whatever you’re using and so these are things that managers can control; so for example one of those is really looking hard at quality and you know, how can they impact quality through providing resources or some sort of focus on quality; and really the piece of this that’s really important is the fact that organizations are moving more and more to things like continuous development and continuous delivery. So doing things on a very frequent basis; the more you do that, the more you want to do that, the more you have to really focus on quality all the time; you know, if you’re in a waterfall environment, you can sort of put quality off until the end and try to test it in and then you can release a product and, you know, it’s sort of a lower quality, but you can kind of get by with it, you think, but then it kind of catches up with you over time.
The more you go to continuous delivery, the more you have to keep that delivery engine primed and ready to go all the time and so any sort of fall off in quality is felt the next iteration or the following iteration; and so you really need to think about those kind of quality issues, automated testing issues those, kinds of things in order to move into a continuous delivery environment; so that’s kind of one of the things that managers can do.
I asked the question on a session today; so I had 120 people in the session and I said “how many of you are doing too many things in your organization?” and I think every hand went up. So one of the things that managers can do is to do less, to really begin got focus on those things that are really, really important; the example I used was from Steve Job’s biography that was out recently where when he went back to Apple, the first thing he did was to take a look at how many products they were developing and it was like 50 and he said we’re going to do four things; so this idea of doing less. So managers and executives a lot of times their kind of focus is how much more can we do as opposed to focus on a few things, get them done and then get on to something else sort of the Lean, Kanban approach to things; so that’s another kind of thing they can do.
The other one is to if you’re going to really manage in an Agile way that you need to think about how are you going to measure performance; so I talked to people about this Agile triangle which is offshoot or different from the iron triangle of cost, scope, and schedule. The Agile triangle is more about value, quality and constraints and then the constraints are scope, schedule and cost; and so talk about the value oriented thing which enables you to be more adaptive and more Agile because you’re always sort of continuing, you’re constantly turning out that value; so those are some of the things that you can do differently.
5. You touched on the concept of metrics and measurement, measuring success and progress, how do we do that in this new frame for management because certainly my understanding is a lot of the old metrics don’t work, in fact they’re counterproductive?
Right; a lot of the old metrics don’t work and so for example the traditional project management metrics of scope, schedule, and cost, those are really constraints, those are not objectives; and so the objective is really how can I deliver a continuous stream of value to the customers and so we really want to look at looking at the value of a project, looking at the value of features within a project and kind of keeping track of that either in an – and just like we do with story points; story points are relative cost of things so we need to have some way of developing the relative value of thing as well as the relative cost then we can kind of make some decisions about value.
We do have to maintain – you know, there’s both an idea of adaptability and predictability and so which is it that we want to do and the answer you got to do both; you’ve got to figure out ways to be predictable. So one of the ways we’re predictable in an Agile environment is we time-box releases and we say look we’re going to release certain features of a product by this time and we’re always going to release on schedule; we may not get all of the features that you want or all the stories that you want in each release but we’re going to release on schedule so that’s a degree of predictability; and then we want to leave room to be adaptable and to change things as we learn stuff as we go forward; so we may want to say okay at a capability or an epic level we might say okay we’re going to deliver this epic or this capability but exactly what the stories are that are going to enable us to do that may change over time as we get into the project and we learn more; so we try to figure out how to do both adaptability and predictability.
The other thing that we really want to look it as this idea of quality and one of the problems that we have with quality is that we sort of traditionally have this historical dilemma; so we ask our business partners what do you want, do you want more features or do you want a lower McCabe cyclomatic complexity index; I mean that’s essentially what we’re doing when we’re saying do you want higher quality, we’re asking, you know, really detailed technical questions; so we’re asking them to do a business outcome tradeoff versus a technical outcome tradeoff. So what we’d like to do is to substitute a business outcome tradeoff to a business outcome tradeoff and that really ends up being cycle time; because as you move into a continuous environment and begin reducing cycle time of how long it takes to get something out, you really have to maintain that quality on an iteration by iteration basis or your ability to do that kind of falls off; and so you can really for, as you get closer to continuous delivery, equate cycle time and quality; so those are really two business tradeoffs in terms of features and cycle time because, you know, cycle time is something that means something to the business whereas complexity index or technical depth doesn’t mean as much to our business partners. So those are some of the things that Agile or adaptive leaders can do to try to make the reason, the rationales for doing Agile more understandable to a business audience.
6. Thank you very much; you published a blog post that was pretty well reported around the world and certainly we at InfoQ reported on it; it was “Velocity is Killing Agility;” do you want to tell us a little bit about that?
That was interesting because as I mentioned earlier, I got 8000 hits in a couple of days and brought my website down and so it was really well read so it was kind of one of my better catchy titles; but what I’m really talking about there, again, as part of this performance measurement stuff and that I’ve seen organizations that tried to only measure velocity and they measured velocity say at a team level and an organizational level, you know, product level and an organization level and what happens in many of those organizations is velocity really becomes a stand in for productivity; productivity really doesn’t mean much in a knowledge work kind of environment and so we end up measuring the wrong thing.
Velocity was originally intended as a capacity measure to kind of help the team and product manager kind of figure out how long it was going to take to do something and how much they can do; and over time it just becomes, you know, how much velocity do you have today or how much velocity did you have last week; so I’ve seen organizations really get into trouble.
In fact I was visiting with a ThoughtWorks team a number of months ago and I said “well how is it going” and they said “well it’s going pretty good, the customer is happy, you know, we’re delivering something of value and they really like what we’re delivering”; and I said “well are you having any issues or any problems with the customer” and they said “well they beat us up every now and then on velocity”; I said “so what do you report to the customer” and they said “velocity”.
So I say “well, you know, what about value” and so one of the interesting things that they did is I said just putting a 1 to 5 asterisk on a story card as to the relative value of that story card versus something else might be something that might help; and so they came up with a scheme that went beyond that a little bit and that they do a goal; so in any release, they may have three or four business goals and those three or four business goals might be reached if they have some minimal number of – you know, minimal valuable product stories or minimal valuable features that they deliver against that goal; so now they’re reporting not only in terms of velocity but they’re also reporting in terms of percentage of value goal achieved; so that’s just a way of really reporting something a little bit different.
So it’s not that velocity by itself is a bad measure; it’s just that people are using it way too frequently for way too many things and they sort of are using it in a way that becomes a real productivity measure; they’re measuring it across teams for which it was never intended; and so again it kind of gets back to this issue is: if you want people to be Agile and adaptive and flexible, you got to change the way you measure success. One of the questions I always ask in one of these sessions is how many of you worked on projects whereas somebody has said “be agile, be flexible, be adaptable but meet the fixed plan”; you know, everybody has been in that kind of situation so one of the things management has to do is to change their governance model to meet what Agile projects actually do, but that doesn’t mean throw away a governance model; they’ve got to learn different ways that they can govern projects that are based on value and quality and to some extent the constraints of scope, schedule and cost; but to look at those things in a different way and look on them at a multidimensional way.
Shane : Metrics are hard.
Metrics are very hard.
Shane : Velocity is easy to measure.
One of the better books on metrics was Rob Austin’s book that he wrote in the mid ‘90s Measurement and Management in Organizations something like that; it was an outcome of his dissertation; and it really was talking about that most measurements that organizations put in place are dysfunctional and become dysfunctional over time as people learn how to game the system; so that you have to be very, very careful of metrics and we all know of the classic software development metric which was lines of code; and so how many lines of code did you produce; well you want lines of code, we’ll give you lines of code, but that is not the outcome that you’re looking form, that’s a stand-in for the outcome; and so what we really need to measure are those outcomes that we really want which may be more difficult to measure; so for example value maybe more difficult to measure than cost, but I’d rather have a fuzzy measurement of something important than a precise measurement of something that’s not important; so we have to really think about measurements and metrics and multidimensional metrics not single metrics and changing them around over time so that they don’t become dysfunctional in organizations.
Shane : Great, thank you; just to round things off I suppose, you’ve been with ThoughtWorks now for nearly two years.
Well I’m really enjoying working with ThoughtWorks; I’ve known many of the people Roy Singham and Martin Fowler and some other people in ThoughtWorks for a number of years; and so as an executive consultant, my role is to talk about things like adaptive leadership and help connect to executives and managers in organizations that we’re working with and really go, you know, help them think beyond just the Agile software engineering kinds of things but more the management and leadership kinds of issues and really kind of connecting with that audience has been one of my primary things; and I do a lot of presentations like at this conference and then also internal presentations for some of our clients around the world and also get to write my blog and do some other kinds of writing and outreach kinds of things like that.
Shane : Great; well Jim, thank you very much for taking the time to talk to InfoQ today and good luck for the rest of the conference.