Introductions
0:00Well, hello, everybody. This is another edition of the Agile Executive Podcast. And as always, this is one of your co-hosts, Michael Coté, available at peopleoverprocess.com. And we have one of the other co-hosts with us today. Would you like to introduce yourself? Hello, everyone. This is Israel Gat. I do the Agile Executive blog together with Coté. And I am delighted for us to have our guest today. Would you like to introduce yourself? Sure. This is Jim Highsmith. And I'm one of the authors of the Agile Manifesto. And I head up the Agile Consulting Practice for the Cutter Consortium. And along those lines, I mean, for people who aren't sort of like, haven't been curating their Agile library, over the years. I mean, can you give us kind of like a brief background of how you came to sort of be one of the strong voices in the Agile world? Like, how did you evolve into being involved as you are in Agile? Well, during the 1980s, I was very involved in more traditional methodologies. And towards the early part of the 1990s, I began to really question if it mirrored the way I actually worked.
Rapid Development, and Finding Scrum, DSDM and XP
1:23And in the early 1990s, I started doing rapid development, which was sort of, for me, the precursor to Agile. And did a lot of that all during the 1990s. Started writing my first book in the mid-90s, Adaptive Software Development. And then, as it got fairly close to publishing that book, I had known about DSDM. I had known about Scrum as sort of parallel types of efforts going on. And I found out about XP just before Kent wrote his book. And he and I had some conversations. And he looked over my book. And that led to some meetings, which eventually led to the group that wrote the Agile Manifesto. Right. And it's interesting, the background you have. Because I've always been curious, like, kind of what the comparison is between just rapid development and Agile development. Because they seem to both be going towards the same thing. But they're obviously sort of distinct philosophies, if you will. I mean, what do you think was different about rapid development? I think rapid development, and it really got started in the early 90s and lasted for a few years.
Where Adaptive Software Development Came From
2:42And, again, it was kind of the early look at how to do iterative development. But it had sort of a different philosophy behind it. It was oriented towards small projects. It was oriented towards kind of quick and dirty projects as opposed to sort of well-crafted projects. And it was also built on, you know, Barry Beam's smile model and Tom Guild's evolutionary models that came out in the late 1980s. But I think it just sort of evolved into, you know, the different precursors kind of of the Agile movement. And the RAD stuff never got really as big a foothold as Agile has. And so it just – I think it was kind of an evolutionary process. I mean, I first started calling mine radical software development in the mid-90s. And then that evolved as I got into complex adaptive systems theory. I said, oh, this is really adaptive development. So that was the evolution for me. Yeah, and it seemed like RAD development suffered from sort of tools vendor takeover, if you will.
When a Method Gets Defined by Its Tool
3:58And there was – you know, there was definitely a body of knowledge aside from itself. But then there were several – you know, it's interesting to see these trends happen over and over again where there's sort of an idea of how some technology or, in this case, software development should do. And then it sort of becomes defined by the tool itself. I think so. And I think that happened – I think you're right with the RAD movement because there were a lot of RAD tools out there. And interestingly enough, I think in the Agile movement, it's been the other way around. I think the Agile concepts and practices have really preceded and to some extent kind of dominated the tools, although there are, you know, a handful of tools out there now that, you know, that are doing Agile stuff. But I think the movement itself was pretty rich before that happened. Yeah, I mean, it's interesting in the Agile school of thought. There's not – you can't really buy like a – well, that I can think of. There's not like the Agile suite where you just buy that suite of tools and you're done. I mean, instead there's very – in very much the definition of what a tool is, there's lots of tools you can get to kind of assemble together. But you can't buy the work shed of pre-integrated tools together. No, and I think there's – I think, you know, at least one reason for that is that Agile is really rich in what Josh Kariefsky was talking to me about when we were in China together a couple of weeks ago.
Management Agility and Technical Agility Need Different Tools
5:21And so you have really management agility and technical agility, and they are very complementary of each other. And you need a whole different set of tools for each one. And so you don't really have an Agile tool. You have kind of a suite of Agile tools to support different kinds of things, project management, collaboration, continuous integration, and all the technical areas. And so nobody has the tool at this point. Yeah. You know, on a tangentially related topic, you mentioned being over in China recently. And when I was looking through some of your older blog posts, you were mentioning that, you know, I'm always interested in how cultural differences affect software development, if you will, and culture across all sorts of vectors. And in one of the posts you were saying, it was a post about instead of talking about self-directed teams, which people might associate with anarchy, you know, having a different phrasing for that rather than sort of giving people the idea that these teams of people are deciding critical things and so forth and so on. And there was an interesting kind of a side that you had that the ways you apply Agile, you know, in China might be different than how you would apply it in, you know, in Europe versus how you would apply it in South America or different places like that.
Agile in Different Geographies
6:40And I'm curious, since you mentioned being in China, like when you see Agile applied in different geographies as to choose one sort of cultural thing, like how things are panning out to be different with Agile? Well, it is. It's very different. And one of the things that I wrote recently about is the difference between impediments and barriers. And an impediment is something with training, money, time, persistence, you can hope to overcome. And a barrier is something that is culturally related, either within a company or a country or some combination of that, that really is like smacking your head up against the wall to try to overcome that barrier. And that in those kinds of instances, we have to look at adapting Agile to the situation as opposed to the other way around. And I think there are a lot of people who just think, you know, there's the Agile set of stuff and we have to do that everywhere. But you really do have to look at different cultures and companies in terms of particularly a lot of the management stuff. But there's also some of the technical stuff. Now, there's several articles running around about the difference in a feature focus and a component focus.
Impediments You Can Beat, Barriers You Cannot
7:56And when you get somebody that's building a huge application, i.e. 5 or 10 million lines of code, you know, there are certain subsets of those teams that probably need to be component teams rather than feature teams. So there is a lot of cultural stuff. And it's why a transition to Agile is not a step one, two, three, four kind of transition. It really does require a lot of thought about companies and cultures and organizations. And I was someplace recently and they were asking me about organizational structure and, you know, and I hadn't been with the company very long, didn't know a whole lot about them. And I said, you know, I can I can make some recommendations based on what an Agile philosophy would would say. But I can't make organizational recommendations without knowing a lot about your individual company. Yeah, yeah. There's sort of I mean, you have to know sort of the ethos of the company before you can start screwing around with like big organizational issues and figure out its goals and everything. I mean, there's I mean, that that that is I mean, that's another interesting leap in Agile that kind of gets to the the the new edition of your of your book that's out.
Above the Team Level, Into the Rest of the Business
9:12And that's figuring out when you sort of move Agile above the sort of product or team level and how it kind of gets its its tendons and tendrils out into the rest of the business. And I mean, along those lines, like having looked over some of the the new information and the or an overview, I should say, of the the stuff in the new edition. I mean, what what what what have you what have you been adding to to the the book in the second edition that kind of addresses fitting Agile into the bigger context? Well, I've really added four new chapters and revised a bunch of the stuff that was in previously. But the four things that I really focused on that I would say lead to both bigger projects and to more of an enterprise kind of stuff. One is on advanced release planning, just a bunch of topics about planning an overall project or release that I thought were pretty important because there are, again, some in the Agile community that tend to focus more on the iteration at a time as opposed to the project at a time. Yeah. Secondly, scaling. And there's a number of things out there about scaling now, but I really focused on scaling self-organizing teams.
The Four Additions to the Second Edition
10:29How do you build a hundred or five hundred person Agile team as opposed to, you know, the structure of the product and the architecture, although I go into that a little bit? The third area, and this is one of the things that you run into a lot with big companies, particularly if they're doing combinations of hardware and software development, are governance issues around the – they've never worked with a hardware company or in one of those bigger organizations. They haven't been really introduced to PhaseGate, but I run into that in a lot of big companies. And a PhaseGate system is a very linear system of governance. And so one of the things I've done is to find a kind of Agile way to work into that governance model. And then finally, and to me is the most important, is that if we really want to bring agility into organizations, then we really have to change the way we measure performance. Right now, most projects are managed by the old iron triangle of scope, schedule, and budget.
Be Adaptable, But Conform to This Narrow Plan
11:46And so on the one hand, we tell Agile teams, be flexible, be adaptable. And on the other hand, we say, but conform to this very narrow plan. So we want to be Agile, but in a very small box. And I think we have to open that box up through different ways of measuring success. Yeah, yeah. I mean, that is always the – measurement always becomes usually the link to compensation. And then there's a few things that motivate people to act favorably inside the box than that. Right. And it's always a difficult challenge to, I don't know, to map those two things together. You know, one thing you mentioned, you know, as far as the – I don't know what you'd call them, sort of systems developers, to use another term for hardware plus software folks, is the – you know, conforming the very – the seemingly rigid sort of demands of developing actual hardware with the looser demands of doing software development. And it seems like, especially, you know, of all the sort of methodologies or sort of practices you could pick out, Agile is kind of the most resistant towards kind of like the hard specificity that hardware development would have. Well, actually, it's interesting because I have worked with hardware developers. And there is a – in hardware development, there actually is a period of time during the concept and early development phase
Bits and Atoms, and Titanium Ion Chambers
13:10where Agile really does fit in. And at the point where you really turn from bits to atoms, so you go from looking at things as simulation models or as breadboards or, you know, engineering mock-ups or something like that, once you then go to – so, for example, one of my clients was building mass spectrometers and they had these ion chambers, titanium ion chambers. Once you start buying those kinds of things, you've committed a lot of cost. And so, the cost of change goes up. So, in a hardware project, you actually have a front end that is agile and a back end that is more traditional. And if you can do that, you can actually come out a lot better with hardware projects. But it's very difficult to get a team who can do both. Yeah. I mean, there's that certain, like, extreme flexibility at the beginning, but then you better lock it down or it does – it becomes immeasurably more expensive to change things at the end. That's right. And it's all around cost of change. And so, one of the strategies that I talk about in the project management book is that even if you're in hardware development, that the longer you can keep development in bits rather than atoms, the more flexibility and adaptability you're going to have.
Agile as a Highly Disciplined Approach
14:25Yeah, it's interesting also, there's – when I've had this discussion with sort of systems thinking people about how you apply any sort of software development or how you get more of the flexibility of software involved in hardware when you combine these two things together, it always brings up the sort of like the devilishly counterintuitive thing about agile that it actually is a very highly disciplined approach to doing things. Or I should say it brings as much discipline as you sort of want to apply to it, including quite a bit. And that it's interesting looking at other ways of going about software development and realizing that in certain forms, agile development has actually a fair amount of discipline when compared to the hardware development discipline that you have. And that there's actually the chance for a lot more compatibility between agile software development and the discipline in embedded systems than there is in sort of other methodologies that sort of expect a lot more change down the road necessarily. Right. And it does seem like there's an interesting opportunity there that isn't sort of immediately intuitive at first. I think so. And I think it's a little more difficult in the hardware environment. But I also think that it's pretty important.
Flexible Product Development in Hardware
15:42Preston Smith, for example, is kind of a hardware developer who's sort of the agile hardware development, has written a book on flexible product development. And so trying to bring that idea of flexibility, adaptability, experimentation, innovation into the hardware realm. And it's a little bit more difficult there, but not impossible. That's right. I think there's a reason that there's an extreme difference between hardware and software people. It's just sort of different mindsets that enjoy those problem sets. Yeah. Jim, allow me to stay for one more minute on this point of hardware use software, as Koze has just mentioned. If I do an agile project within the context of an overall environment in which there are a bunch of waterfall projects, what would be your good counsel in terms of being able to run with an agile project in an unconstrained manner? Namely, in the context of a component development which has both software and hardware,
An Agile Project Inside Waterfall Phase Gates
16:59you recommended to stay as long as you can with the bits instead of the atoms. What would be your good counsel about an agile project in the context of some waterfall project or some linear phase gates? Well, obviously, you know, I mean, that's an issue when people are doing big projects, when they're doing enhancements on big legacy projects. And really, it's a matter of synchronization. So you may have an agile project that's running on two- or three-week iterations, but every now and then you have a milestone or call it the end of a wave where you have something that links up to a hardware project. So maybe you have a hardware project that's running two-month iterations or three-month iterations. In the beginning, maybe the hardware projects are running even faster iterations on breadboards and mock-ups kinds of things. So it really, at that point, is a matter of synchronizing the various timeframes at some integration milestone. And then also, if there are some dependencies, is to, you know, work ahead of time on some of those dependencies,
Synchronization Points and Dependency Management
18:23just as you would if you had, for example, two waterfall kind of projects running in parallel. You wouldn't wait until the final bell until you looked at some of the interdependencies. So you do the same thing with an agile project. So, you know, it requires more coordination. It requires more dependency management. It requires more looking at just what's going to be available to integrate, for example, at each of the synchronization points. But that's one of the ways in which you could have an agile team working within an overall project that was, say, a waterfall team, but you were just starting up with agile. It does make sometimes a little bit more difficulty in terms of testing harnesses and testing cases and continuous integration. It makes it a little more difficult to do, but it can be done for both an agile software project and a hardware project or an agile software project running in parallel with some traditional waterfall software project. Understood. Thank you. So one of the other four new areas you were talking about was sort of release planning, essentially.
Release Planning as More Than Obligatory Bookends
19:40And to your point, as you were saying, a lot of the focus on agile software development is on the iteration planning and focusing on the iteration. And, you know, usually the idea of release planning, it can seem kind of and gets treated sometimes like sort of obligatory bookends on a bunch of iterations. And so I wonder, I mean, it sounds like, you know, you're trying to suss out some more, make release planning more than an obligatory bookend, essentially. Yeah. And I wonder how that's evolved for you. I think that's really critical. I have always, since the beginning, stressed release planning over iteration planning. I figure if you've got a good iteration plan, then iteration planning just kind of falls out. So I've always looked at looking at the entire release as important. One of the things that I have gotten feedback from managers here in this country, in Australia, New Zealand, in Germany, and several other places is that they have agile teams who are basically working at an iteration at a time level and don't want to answer questions like, well, how long is this project going to take or how much is it going to cost? You know, give me some constraints on this project. And, you know, the response from some of these teams is, well, that's not agile.
Budgets, Training and Marketing Have to Land Somewhere
20:58And in many companies, you know, you have to have some budgeting types of things. You have to have some scheduling. Whether it's internal and you need to know when to get people trained or ready for the release or whether you've got a product that's going to the marketplace and you've got to have, you know, there's a lot of marketing stuff that's got to go into place for a big product release. And so there's some reaction in the agile community to having scope and schedule kind of nailed down for them before. And now the alternative is not to do any of that. And so I think it's, you know, fairly important to do that. So, you know, and also to have multi-level plans and not just a story and a feature level, but maybe a capability feature and story level so that you look at, say, a product roadmap for a year or 18 months at the level of a business capability or a product capability. You look at a release plan, maybe a three- to six-month release plan at a feature level, and you look at an iteration plan at a story level. So you're trying to have some long-range plans, but at a high enough level that you don't spend an enormous amount of time actually working on those plans,
Losing the Release in the Iterations
22:18but they give you sort of a feasibility of the project and some broad constraints on that project. Yeah, I mean, you know, part of what you're saying is the classic forest and trees problem where you spend all your time focusing on iterations and different features. And it could become easy to kind of lose track with the sort of end goal with the release that you're doing all these iterations for. And then definitely as the rest of the company kind of looks at a chunk of software as what you end up with at the end rather than maybe what you have every, you know, whatever, whether it's, you know, weekly or monthly or whatever iterations that you have, you know, especially, you know, when you raise up marketing concerns, that seems like one of the areas where if you were an ISV, for example, or someone selling a product built on top of the software, the marketing people, if they hadn't spent a lot of time getting involved and seeing the evolution of the software, would sort of be probably not too delightfully surprised at what release they end up with at the end. Right. One of the things that I sometimes talk about is the difference between iteration and oscillation. And if you don't have an overall plan, a release plan that you're looking at, have some sort of theme for your development effort, you get so caught up in iterations that you can actually get to oscillating rather than iterating.
Circling Rather Than Progressing
23:38In other words, you're just kind of going around in circles rather than progressing towards some goal. And that can be either at a requirements level, you're just sort of, you know, going back and forth and back and forth on some kind of minor requirement, or at a technical level where you're just sort of refactoring and refactoring and refactoring. And, you know, it's getting technically just minutely better each time, but you're really not progressing towards the overall goal of the project. Yeah. So, you know, I'm curious, you know, for as much sort of subtle bashing as we've done sort of to the teams paying attention to the iteration, like how can people on the other side of that, sort of whether they're marketing folks or the budget folks, like how can they kind of interact with the development process to kind of aid, to make better keeping your eye on the goal and like keeping an eye on the final release? I mean, is it sort of like something that you do kind of on a day-to-day or an iteration process to kind of guide the team or teams towards what this final release is? It can be at a couple of different levels. It can be at the, let's say that I have a roadmap, a product roadmap. Well, it may be that some of the marketing people get in and salespeople get involved at that product roadmap and or the release planning level,
Different Levels of Product Involvement
24:55but don't get as much involved at the iteration planning and development level. And so you have product specialists that are getting involved at the detail level. And maybe you have the product manager who really doesn't get quite as involved at that level. So you may have different levels of involvement given the different levels of planning and not only in the planning, but also, for example, maybe the product specialists or the people that are working directly with the iteration, they get to look at the feature demos at the end of the iteration, but maybe at the end of a milestone that the product manager, the people that were involved in the release and or the road mapping, they get involved in a demo of those major features or capabilities. So that's also part of this kind of the scaling issue is different size components, different pieces of the organization, different lengths of time. And so I think you do get those marketing and salespeople involved, but maybe just not every iteration. Right. That's interesting. So one of the other areas you were talking about was the always interestingly titled – sort of technically titled scaling up a team if you're self-organizing teams.
Scaling Up Against Scaling Out
26:16And, I mean, first off, I mean, what – when you use that word scaling, like what do you mean exactly by scaling a self-organizing team up? Well, there – to me, there were two kinds of scaling issues, scaling up, which means bigger projects, and scaling out, which means distributed projects. And the scaling up is what happens if you have a 600-person team versus a 10- or 15-person team. And there are a couple of major factors in there, one of which is the organizational design, the second of which is communication collaboration design, and the third of which is something that very few people talk about, which is decision design. How do decisions get made in a 500-person team versus a 15-person team? You can't have all 500 people involved in every detailed decision that the team makes. And so how you design how those decisions are made then turn into working agreements between teams on this overall large team. And just like you have within an agile team, you have a set of working agreements between team members as to how they're going to work together.
Decisions, Collaboration, and Organizational Design
27:36You have working agreements at a team-to-team level. And a lot of those things have to do with who gets to make what kinds of decisions. So I think all three of those things, decision-making, communications collaboration design, and organizational design, go into designing a large agile team. Right. So it sounds like you sort of established some principles, if you will. And then, I mean, I guess one of the dangers you have with scaling in any direction is you end up spending a lot of time on communications channels and syncing up and kind of passing around the baton of authority to let people make decisions. And it sounds like what you're getting at is you try to establish some rules that allow intra-team decisions to be made without having to call lengthy meetings, you know, to ground it a little bit at the same time. And coming up with a way that, you know, who's sort of responsible for making this decision and who should you talk with about making these different decisions and kind of progressing without – I mean, I guess once you clearly decide – once you clearly define how decisions are made, you can spend a lot less time each time a major decision comes up figuring out how you're going to make a decision.
Teams Need Input Into the Decisions
28:51That's right. And you also know – you also know, you know, and one of the most important things in this is that teams that have some input to those decisions feel like they have some input and some influence on the decisions. And so you may have – for example, if you have an architecture team, you'll have membership in an architecture team from all the feature teams or several of the feature teams. Their senior people or developers or testers will be part of that architecture team. So they get direct input to the decisions and they also get involved in those decisions. And so there's cross-linking between teams. And one of the things that does happen, you know, in larger teams, like you say, is you do feel – spend more time on communication and collaboration. It's just part of having a bigger team. One of the – one of the phenomenas that I've found very interesting in bigger projects is you'll have agile teams who are basically customers of other agile teams. In other words, another agile team will have some component that they need to deliver. And the first agile team who is the customer of the other agile team, they're the worst customers in the world.
Being Somebody Else's Customer
30:12They don't want to take the time to do the requirements, to do the acceptance testing, to do the – you know, to talk about the requirements. If their customers treated them that way, they would raise hell. But they're willing to treat other teams that way when they're the customers. And so that's one of the things that I talk about with a lot of teams, bigger teams, is how you have to be sometimes a customer and put that time and energy into being a customer. Yeah. I mean, there's sort of – I guess as you scale things up, there's the – you have to apply the golden rule a lot more than you would if you were in small scale because you're expected to behave in that role. Yeah, that is interesting to – I can imagine that especially in software development teams would prefer not to have the luxurious amount of specification it takes to actually figure out what, you know, what someone wants to code. And there's sort of like this assumption that because we're all developers, we can kind of like, you know, just wink and nod at each other and understand what the requirements are. But what's interesting is that the agile team who's the customer, also they tend to make completely unreasonable demands on the component teams that are feeding them. Right. It's like, again, if their customers, you know, treated them like that, they'd be really upset.
"Must Be Robust and Enterprise-Grade"
31:29But they don't see themselves in the role of a customer in that kind of inter-team component that gets done. They don't really see themselves in the role of a customer. And oftentimes I have to point that out to them. Yeah, they start giving requirements like feature must be robust and enterprise-grade and other big things that make no sense. Right. Or we must have it by this iteration as opposed to – Even better. That's right. Jim, what do you see as the effect of the scaling out on the set of scale-up problems that we have just discussed? Obviously, at a certain point in time, any scaling up would become, by necessity, a scale-out as well. How do you see the interplay between the two? Usually, I sort of like Dean Leffingwell's comment that at scale all projects are distributed. A couple of pieces of data from some studies that were done a few years ago that collaboration begins to break down significantly at distances exceeding 50 feet. And that knowledge sharing, informal knowledge sharing begins to break down pretty quickly in groups exceeding a couple hundred.
Virtual Co-location on a 600-Person Team
32:52And so, particularly on the collaboration thing, if you have a – you know, if you have a big team, if you have, you know, 100, 200 people on a team, they're probably going to be at least on different floors of a building or in different areas of a building. And I know with one large team of about 600 a few years ago, I came up with the term virtual co-location. And what I wanted them to do is I wanted them to act as if they were co-located even when they weren't. I think – so I think that in general, the communication, collaboration, issues, tools that you have are the same for large projects as they are for distributed projects. In distributed projects, then you have another set of constraints, which tends to be distance, number one, because even if you're in the same building, you can get together to do iteration plans or release plans pretty inexpensively. If you distribute it, that's more expensive. So distance does have some impact on the team and being able to get together to do stuff. Company cultures and country cultures tend to impact here, and also time zones, as you know from your projects, Israel.
What Distribution Adds Over Size
34:14So there are some additional factors with distributed projects over and above just larger projects. But once you start talking about the issues of communication and collaboration in large projects, many of those things are the same kinds of issues you deal with in distributed projects. I could not agree more, and as a matter of fact, I would say we dealt in certain cases with distribution in a very expensive manner. Maybe we would fly at least for a few days, or then for more than a few days, we will fly folks from offshore locations, either to Austin, Texas or to Houston, Texas, in order to be able to be able to, at least for a period of time, to be co-located. So my own experience has been that overcoming the difficulties of distribution, or distributed environments, or scale out, as you call it, really requires additional investment of money, so you have got to plan and budget for it. Otherwise, the mechanisms of communication and collaboration, which are available across the fund, are often insufficient.
Separable Architecture, Relationships, Complexity
35:38Right. So when I look at scaling and distribution factors, I look at the product architecture. For example, do you have a piece of the product that you can pull off that's really separable from the rest of it to give to a distributed team or not? If it's highly integrated, that's one issue. Relationships. Do the people who are distributed have existing relationships? So they're pretty well unknown to each other. And then project complexity, you know, how big, how many people, how distributed is it, those kinds of things. And then the particular practices that you're using. So, for example, one of the things you said is you brought together people together to do release planning. And release planning is a fairly involved practice where you really do need to get high levels of communication and understanding. As opposed to, for example, a daily stand-up meeting, which can be done over the telephone fairly easily, doesn't require, it's not as complex a practice as release planning. So what you have to do is to look at those scaling and distribution factors in terms of how you design the communication and collaboration.
Spending the Expensive Modes Where They Matter
36:55Yeah, you'd like to have everybody be able to get together every day, but that may not be possible. So you look at those things where it really is imperative that they get together, and you use the higher cost modes, if you will, for those kinds of things. Indeed. So I guess to round out the four areas, the other area that you said you were adding in the new edition was more detail on metrics and measuring. Well, it actually is more strategic than detail. Right, right. So if I look at agile projects and I say, what are the things that I really am interested in and the things that are most important? Number one is value. And so, but I want to look at value from a strategic perspective. I'm not looking at the detailed requirements or even the detailed stories. I want to ask the question, have we done enough on this project or product so that I can release this product to the customer use? So I'm looking at is this product releasable and did we do it within certain business objectives and constraints?
Value First, Then Quality and Technical Debt
38:16So number one is value. Number two is actually quality. And quality is the thing that enables you to deliver value over time because if I deliver value in this first release of the project, but the technical quality is so low and the technical debt is so high that the second release is very difficult to do, then I haven't really gotten the full continuous value out of this thing. So reliable, so reliable, adaptable product is the quality aspect, which is number two. And then the third is really what I call constraints. And constraints are the traditional measures of cost, schedule, and scope. So cost and schedule aren't goals. They're constraints. And even scope is not a goal. It's a constraint on do I have enough capability to release this project. And so one of the things I'm really looking at here is really a big shift from looking at the traditional project management iron triangle of scope, schedule, and cost, and then really looking at kind of fuzzier quantities of value and quality.
Fuzzy Measures of Important Things
39:33They're fuzzier, but they're more important. And to me, it's much more important to have a fuzzy measure of something that's really important than a precise measure of something that's less important. Like lines of code or something like that. Like lines of code or even like cost and schedule. Cost and schedule are measurable, but they're not necessarily the most important thing. In fact, there's a quote somewhere in the material from a CIO of a company who basically said that it was more important to meet scope and schedule and produce lower business value than to have a project that was over budget and over schedule and of a lot of business value because that's how they were measured. Yeah. And if that's the way we're going to measure people, then we're not going to be successful, I don't think, getting agile implemented in big organizations. That we have to really focus on these other things. And quite frankly, I've had enormous response to this. I haven't had anybody yet say, oh, this is crazy. I have had people say, I'm not sure this will fly in my organization. Yeah, well, that's usually the response that means you're on to something. But, again, I want people to think of the strategic issues around value and quality.
The Value Cost Ratio
40:52And interestingly enough, once you start focusing upper management on those things, their sort of focus on cost and schedule decreases. You know, they can see that they're getting value, for example. And then the other thing that's involved in this, too, is what I call the value cost ratio, which is the question, if I can give you 100% of the value for 100% of the cost, or I could give you 90% of the value of this project for 75% of the cost, which one would you pick? Right. And my guess is most executives would pick the 75% of cost for the 90% of the value. And so, by looking at value all the way along an Agile project, you can actually begin to say, where's the right cutoff? When do I need to actually release this product? I don't have 100% of the stories that I would really like to have, but I've got the most valuable ones. I've got the 90% most valuable ones. And now's the time to cut this project off. So I think in that way, you actually end up potentially with tremendous cost savings as well. So when you're kind of looking at organizations like kind of working in this area, you know, bumping up against this or doing it, like where does sort of responsibility rest for figuring out what that value is?
Collecting the Data to Assess Value at All
42:20I mean, whether it's kind of like not only sort of figuring out the ratio and deciding which ratio you would want, but sort of collecting the raw data that allows them to kind of figure out what the value is, if you will. I mean, it's an interesting role to kind of – it's kind of a high-level assessment of like what is it we have here and of what value is it to our customers? It is, and I think that's a combination of the product manager and the executive sponsor or the executives who are involved in this effort, but the product manager to a large extent. And I think we have to educate product managers to this value-cost curve and to getting the most value out early. The problem we've had in the past, I think, is because projects have been so long, they've been, you know, one-year, 18-month projects, that all the product managers are trying to do is get as many features as they possibly can because they know it's going to be another 12 or 18 months before the next release. And if you can get the releases down to the three- to six-month level, then you can begin to say, you know, by delaying something until the next release or, you know, leaving it on the backlog, it's not as big an ask as it is to ask somebody to forego this for, you know, 18 or 24 months.
Product Management Beyond Feature Counts
43:37And I think we have to have product managers who are looking at it from a, you know, again, from a business value standpoint and not just, you know, getting as many features as I possibly can into this next release. Yeah, I mean, you know, now that we're kind of talking about this, it seems like doing that assessment seems to be lacking in quite a bit of software. It's just kind of like having the time to sit back and think, you know, is this software actually, not so, like, you know, instead of, like, are we meeting these deadlines and these metrics and these seemingly arbitrary goals that we have, but just asking, like, are we actually doing something that's worthwhile is, it doesn't seem to happen ongoing as much as you would assume it would. And one of the things that, again, that I've added in this book, and it actually is in the advanced release planning chapter, to get people to kind of think this way a little bit better and a little bit more is I'm actually asking people to calculate value points. So we have story points or story cost, but I'm actually asking people to calculate value, and it's actually a fairly simple allocation, but it can be very powerful in terms of having people focus on value and having some additional information with which to make some decisions about what gets done.
No Time for Value, No Time for Cost
44:55And one of the points I made in the book is that, you know, people are going to say, well, I don't have time to calculate value. And my response to this is, okay, we don't have time to calculate cost then. Right, right. Yeah, it's, I think to that point, it's, and Israel and I have talked about this in past podcasts, there's, I think, I think with an agile mindset, it's always easy to get envious of public web companies, because they have such a short path, or they can have such a short path to understanding value they're delivering or not delivering, versus sort of like ISVs and bigger enterprise software people. It can be difficult to get that really fast feedback to determine if some feature you've developed or you haven't delivered yet, if there's like, if there's a huge amount of sort of business and customer value in it. Right. And so one of the things about this in a lot of situations is just as story points are not absolute costs, they're relative costs, you can do value points that are relative, not absolute. In other words, they don't have dollars on them, but they're relative to each other. So within a project, you know what the higher value things are and the lower value things are relatively. Right. You would find the following data point from my trip last week to Washington, D.C., where obviously many of the projects are government-type projects.
Customers Shifting From Traditional Measures to Value
46:19Their emphasis right now on value and on event value is at a much higher level than I would have expected. Then I actually stepped out of a whole day with 60, 70 customers, rally customers in D.C., very encouraged by how far they have shifted from the traditional measures into thinking in terms of value. And that has been a point in the Agile community for quite some time is to focus on value and focus on incremental value. But we haven't really gotten rid of or changed the overall kind of Iron Triangle approach. And that's one of the things I'm trying to do here is to put the Iron Triangle scope, schedule, and cost within perspective as constraints. And they're still important. And this is a major premise in your book, correct? Yes. So, in fact, this is probably the number one driver to the new book is putting this stuff on performance measurement and what I call the Agile Triangle out there.
What It Takes to Establish Agile in Bigger Companies
47:36It has a critical piece of how we have to move in order to get Agile more established in bigger companies. Yeah. And to kind of get to the point, we're actually delivering valuable software. And you have the whole process underneath it that supports that. Right. So, we haven't actually mentioned the name of the book now that I think about it. But before we wrap up, I mean, we've said that it's a second edition of it. But what's the actual title of the book and what's the availability of it? It's Agile Project Management, Creating Innovative Products, second edition. And it is already available on Amazon and Amazon Canada within the next couple of weeks to other countries. But it is out and available. And, you know, unless Israel had any other sort of on-topic questions, I just had one little slightly off-topic question. Okay. And of course I have an off-topic question, Mike. You know me. That's right. Well, you want to go ahead then? Well, may I ask you, Jim, to do a retrospective on the past eight years. You have been one of the originators and signers of the Agile Manifesto just about eight years ago.
Looking Back at the Road Traversed
48:58When you take a look at the road we have traversed since then, what do you feel? What is your assessment of what we have done well and what perhaps we have done in a different manner? Well, it's interesting. There's a couple of big things happening this year. They're at the Agile conference in August in a few weeks. There's going to be a joint launch of the PMI, Project Management Institute, Community of Practice of Agile. So PMI is getting active in the Agile world. And earlier this year, we had the Software Engineering Institute who released a paper, 30 or 40-page paper, on how to combine CMM and Agile. And so you have two of the organizations that have been somewhat antithetical to the Agile movement becoming involved in the Agile movement. So I think that's significant. I think it parallels the fact that seven or eight years ago what we did in Agile was really small projects, small transitions.
From Rogue Project Teams to 600-Person Transitions
50:14What I call rogue project teams within organizations were doing Agile. Three, four, five years, three or four years ago, we started getting more bigger organizations. Rather than rogue project teams, we would have CIOs or VPs of engineering come to us and say, okay, we want to go Agile with 100 people, 400 people, 500 people. I did one in 2005, 2006, involved about 600 people in development and engineering. So that growth in size, and then recently, as I mentioned, I was in China, and this was a potential transition of 25,000 plus, where you have entire big organizations, and there are a number of these around the world. IBM, for example, there's pieces of IBM that have mentioned this 25,000 number internally also. So I think those are positive trends. On the maybe not so positive trend, I've also seen the reluctance in some Agile circles to be Agile, to be adaptable. They're sort of hung up on the specifics of one methodology or the other to almost a religious fervor
Where the Community Is Still Resistant
51:36and are not willing to begin to integrate things from either other Agile practices or things like CMM and PMI. They are still resistant to that. So that would be one of my probably comments about something that's not as positive. Well, that's a nice overview. So the last question I was going to ask, I noticed that the release date for the Kindle book is like some months after the hard copy book. And since people are always interested in the Kindle and you're an author, I was curious, do you get involved in the process for converting it to a Kindle, or is it just sort of like a straight conversion of the book? Because it seems like there would be different features and things that you could add in if you wanted to spend the time, or maybe not. I don't know. I'm kind of curious how that process works. Well, number one, I don't get involved in it at all. Number two, the Kindle edition is out already. Oh, okay. And in fact, if you look at the Agile project management books list within Amazon, the Kindle version is number two, and the other version, the paperback version is number three.
Kindle Editions and What an E-book Could Add
52:52There you go. And to kind of follow up on that, I actually asked the publisher about a month or so ago, I said, can I get a Kindle version of my own book? And, you know, obviously, not having to pay for it, and I don't have an answer to that one yet. Yeah, yeah, yeah. I mean, it seems, like I was saying, it seems like there would be extra things you could add into an e-book, like whether it was on a Kindle or like an iPhone or something like that, that would be kind of a curious thing to lace into a book, but it doesn't sound like, at least in this instance, there's sort of like the opportunity to extend it in that form. Not that I have seen yet. Like I said, I didn't get involved in it. Yeah, yeah. Huh. Well, that's interesting. Well, I mean, thanks for spending all this time to talk with us today. It was actually like, I think especially the topic on, the discussion on figuring out if you're actually, like, getting a result that's valuable to the business is, I mean, it's always funny to, like, make statements like this, because, of course, that's what you would be doing with software, but for those people who actually, you know, work in software, it can be a kind of tragically alien notion, so it's fun to kind of dig around on the practicalities of actually getting to that point where the obvious sort of thing is what actually gets done instead of the sort of cynically unobvious thing. Right. Well, that's great. Well, thanks for talking with us today. That was a good time. Well, thank you. I enjoyed it. Definitely. Thanks so much, Ian.
Machine transcription, lightly formatted. Chapter headings were written from the transcript; speakers are not identified, so nothing here is attributed.