1 00:00:00,000 --> 00:00:04,420 Well, hello, everybody. This is another edition of the Agile Executive Podcast. 2 00:00:05,320 --> 00:00:10,500 And as always, this is one of your co-hosts, Michael Coté, available at peopleoverprocess.com. 3 00:00:10,600 --> 00:00:14,040 And we have one of the other co-hosts with us today. Would you like to introduce yourself? 4 00:00:15,980 --> 00:00:23,540 Hello, everyone. This is Israel Gat. I do the Agile Executive blog together with Coté. 5 00:00:24,380 --> 00:00:30,840 And I am delighted for us to have our guest today. Would you like to introduce yourself? 6 00:00:32,160 --> 00:00:38,520 Sure. This is Jim Highsmith. And I'm one of the authors of the Agile Manifesto. 7 00:00:39,180 --> 00:00:44,840 And I head up the Agile Consulting Practice for the Cutter Consortium. 8 00:00:45,980 --> 00:00:53,300 And along those lines, I mean, for people who aren't sort of like, haven't been curating their Agile library, 9 00:00:53,540 --> 00:01:00,600 over the years. I mean, can you give us kind of like a brief background of how you came to sort of be 10 00:01:00,600 --> 00:01:07,420 one of the strong voices in the Agile world? Like, how did you evolve into being involved as you are in Agile? 11 00:01:08,100 --> 00:01:13,280 Well, during the 1980s, I was very involved in more traditional methodologies. 12 00:01:14,020 --> 00:01:22,220 And towards the early part of the 1990s, I began to really question if it mirrored the way I actually worked. 13 00:01:23,020 --> 00:01:30,720 And in the early 1990s, I started doing rapid development, which was sort of, for me, the precursor to Agile. 14 00:01:31,080 --> 00:01:35,520 And did a lot of that all during the 1990s. 15 00:01:35,720 --> 00:01:40,640 Started writing my first book in the mid-90s, Adaptive Software Development. 16 00:01:41,380 --> 00:01:47,600 And then, as it got fairly close to publishing that book, I had known about DSDM. 17 00:01:47,700 --> 00:01:53,820 I had known about Scrum as sort of parallel types of efforts going on. 18 00:01:54,320 --> 00:01:59,360 And I found out about XP just before Kent wrote his book. 19 00:02:00,080 --> 00:02:02,360 And he and I had some conversations. 20 00:02:02,760 --> 00:02:04,280 And he looked over my book. 21 00:02:04,580 --> 00:02:10,680 And that led to some meetings, which eventually led to the group that wrote the Agile Manifesto. 22 00:02:11,520 --> 00:02:11,620 Right. 23 00:02:11,840 --> 00:02:15,760 And it's interesting, the background you have. 24 00:02:15,800 --> 00:02:22,360 Because I've always been curious, like, kind of what the comparison is between just rapid development and Agile development. 25 00:02:22,360 --> 00:02:25,560 Because they seem to both be going towards the same thing. 26 00:02:25,560 --> 00:02:30,220 But they're obviously sort of distinct philosophies, if you will. 27 00:02:30,340 --> 00:02:33,900 I mean, what do you think was different about rapid development? 28 00:02:35,120 --> 00:02:41,140 I think rapid development, and it really got started in the early 90s and lasted for a few years. 29 00:02:42,520 --> 00:02:47,520 And, again, it was kind of the early look at how to do iterative development. 30 00:02:48,020 --> 00:02:50,840 But it had sort of a different philosophy behind it. 31 00:02:50,960 --> 00:02:53,020 It was oriented towards small projects. 32 00:02:53,260 --> 00:03:00,300 It was oriented towards kind of quick and dirty projects as opposed to sort of well-crafted projects. 33 00:03:01,540 --> 00:03:12,680 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. 34 00:03:12,800 --> 00:03:22,980 But I think it just sort of evolved into, you know, the different precursors kind of of the Agile movement. 35 00:03:22,980 --> 00:03:32,960 And the RAD stuff never got really as big a foothold as Agile has. 36 00:03:33,900 --> 00:03:36,480 And so it just – I think it was kind of an evolutionary process. 37 00:03:37,360 --> 00:03:42,620 I mean, I first started calling mine radical software development in the mid-90s. 38 00:03:42,640 --> 00:03:46,540 And then that evolved as I got into complex adaptive systems theory. 39 00:03:46,640 --> 00:03:48,680 I said, oh, this is really adaptive development. 40 00:03:48,900 --> 00:03:50,900 So that was the evolution for me. 41 00:03:50,900 --> 00:03:57,980 Yeah, and it seemed like RAD development suffered from sort of tools vendor takeover, if you will. 42 00:03:58,320 --> 00:04:02,320 And there was – you know, there was definitely a body of knowledge aside from itself. 43 00:04:02,540 --> 00:04:13,440 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. 44 00:04:13,500 --> 00:04:15,980 And then it sort of becomes defined by the tool itself. 45 00:04:16,640 --> 00:04:17,320 I think so. 46 00:04:17,420 --> 00:04:21,420 And I think that happened – I think you're right with the RAD movement because there were a lot of RAD tools out there. 47 00:04:21,920 --> 00:04:25,500 And interestingly enough, I think in the Agile movement, it's been the other way around. 48 00:04:25,720 --> 00:04:40,080 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. 49 00:04:40,080 --> 00:04:43,460 But I think the movement itself was pretty rich before that happened. 50 00:04:43,800 --> 00:04:47,040 Yeah, I mean, it's interesting in the Agile school of thought. 51 00:04:47,180 --> 00:04:50,720 There's not – you can't really buy like a – well, that I can think of. 52 00:04:50,760 --> 00:04:54,440 There's not like the Agile suite where you just buy that suite of tools and you're done. 53 00:04:54,980 --> 00:05:02,300 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. 54 00:05:02,420 --> 00:05:06,680 But you can't buy the work shed of pre-integrated tools together. 55 00:05:06,920 --> 00:05:20,400 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. 56 00:05:21,300 --> 00:05:27,580 And so you have really management agility and technical agility, and they are very complementary of each other. 57 00:05:28,640 --> 00:05:31,980 And you need a whole different set of tools for each one. 58 00:05:32,320 --> 00:05:36,380 And so you don't really have an Agile tool. 59 00:05:36,520 --> 00:05:46,180 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. 60 00:05:46,180 --> 00:05:49,340 And so nobody has the tool at this point. 61 00:05:49,820 --> 00:05:49,840 Yeah. 62 00:05:50,080 --> 00:05:56,060 You know, on a tangentially related topic, you mentioned being over in China recently. 63 00:05:56,240 --> 00:06:09,800 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. 64 00:06:09,800 --> 00:06:28,040 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. 65 00:06:28,580 --> 00:06:40,040 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. 66 00:06:40,040 --> 00:06:51,120 And 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? 67 00:06:52,120 --> 00:07:01,400 Well, it is. It's very different. And one of the things that I wrote recently about is the difference between impediments and barriers. 68 00:07:01,920 --> 00:07:07,940 And an impediment is something with training, money, time, persistence, you can hope to overcome. 69 00:07:08,780 --> 00:07:20,720 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. 70 00:07:21,320 --> 00:07:28,620 And that in those kinds of instances, we have to look at adapting Agile to the situation as opposed to the other way around. 71 00:07:29,700 --> 00:07:36,660 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. 72 00:07:36,660 --> 00:07:47,020 But you really do have to look at different cultures and companies in terms of particularly a lot of the management stuff. 73 00:07:47,420 --> 00:07:49,660 But there's also some of the technical stuff. 74 00:07:49,740 --> 00:07:56,320 Now, there's several articles running around about the difference in a feature focus and a component focus. 75 00:07:56,560 --> 00:08:11,300 And 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. 76 00:08:11,300 --> 00:08:14,600 So there is a lot of cultural stuff. 77 00:08:14,660 --> 00:08:23,120 And it's why a transition to Agile is not a step one, two, three, four kind of transition. 78 00:08:23,120 --> 00:08:29,640 It really does require a lot of thought about companies and cultures and organizations. 79 00:08:30,260 --> 00:08:41,220 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. 80 00:08:41,240 --> 00:08:48,020 And I said, you know, I can I can make some recommendations based on what an Agile philosophy would would say. 81 00:08:48,260 --> 00:08:53,820 But I can't make organizational recommendations without knowing a lot about your individual company. 82 00:08:54,280 --> 00:08:54,640 Yeah, yeah. 83 00:08:54,980 --> 00:09:04,200 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. 84 00:09:04,380 --> 00:09:12,640 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. 85 00:09:12,640 --> 00:09:22,060 And 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. 86 00:09:22,840 --> 00:09:31,240 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. 87 00:09:31,360 --> 00:09:39,660 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? 88 00:09:40,160 --> 00:09:48,560 Well, I've really added four new chapters and revised a bunch of the stuff that was in previously. 89 00:09:49,200 --> 00:09:59,020 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. 90 00:09:59,500 --> 00:10:11,620 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, 91 00:10:11,740 --> 00:10:17,540 some in the Agile community that tend to focus more on the iteration at a time as opposed to the project at a time. 92 00:10:17,880 --> 00:10:17,960 Yeah. 93 00:10:18,400 --> 00:10:19,440 Secondly, scaling. 94 00:10:19,920 --> 00:10:29,200 And there's a number of things out there about scaling now, but I really focused on scaling self-organizing teams. 95 00:10:29,400 --> 00:10:40,980 How 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? 96 00:10:41,920 --> 00:10:51,040 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, 97 00:10:51,700 --> 00:11:02,880 are governance issues around the – they've never worked with a hardware company or in one of those bigger organizations. 98 00:11:03,540 --> 00:11:08,040 They haven't been really introduced to PhaseGate, but I run into that in a lot of big companies. 99 00:11:08,640 --> 00:11:11,740 And a PhaseGate system is a very linear system of governance. 100 00:11:12,540 --> 00:11:19,720 And so one of the things I've done is to find a kind of Agile way to work into that governance model. 101 00:11:20,260 --> 00:11:33,560 And then finally, and to me is the most important, is that if we really want to bring agility into organizations, 102 00:11:33,980 --> 00:11:37,140 then we really have to change the way we measure performance. 103 00:11:37,880 --> 00:11:45,460 Right now, most projects are managed by the old iron triangle of scope, schedule, and budget. 104 00:11:46,160 --> 00:11:50,540 And so on the one hand, we tell Agile teams, be flexible, be adaptable. 105 00:11:51,020 --> 00:11:54,860 And on the other hand, we say, but conform to this very narrow plan. 106 00:11:55,220 --> 00:11:57,780 So we want to be Agile, but in a very small box. 107 00:11:57,980 --> 00:12:02,320 And I think we have to open that box up through different ways of measuring success. 108 00:12:03,300 --> 00:12:03,760 Yeah, yeah. 109 00:12:03,920 --> 00:12:09,940 I mean, that is always the – measurement always becomes usually the link to compensation. 110 00:12:09,940 --> 00:12:15,900 And then there's a few things that motivate people to act favorably inside the box than that. 111 00:12:16,160 --> 00:12:16,640 Right. 112 00:12:16,820 --> 00:12:22,560 And it's always a difficult challenge to, I don't know, to map those two things together. 113 00:12:22,740 --> 00:12:26,840 You know, one thing you mentioned, you know, as far as the – I don't know what you'd call them, 114 00:12:26,840 --> 00:12:30,640 sort of systems developers, to use another term for hardware plus software folks, 115 00:12:31,200 --> 00:12:43,240 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. 116 00:12:43,240 --> 00:12:49,440 And it seems like, especially, you know, of all the sort of methodologies or sort of practices you could pick out, 117 00:12:49,500 --> 00:12:56,580 Agile is kind of the most resistant towards kind of like the hard specificity that hardware development would have. 118 00:12:56,580 --> 00:12:59,500 Well, actually, it's interesting because I have worked with hardware developers. 119 00:13:00,300 --> 00:13:10,600 And there is a – in hardware development, there actually is a period of time during the concept and early development phase 120 00:13:10,600 --> 00:13:13,200 where Agile really does fit in. 121 00:13:13,560 --> 00:13:22,040 And at the point where you really turn from bits to atoms, so you go from looking at things as simulation models 122 00:13:22,040 --> 00:13:29,400 or as breadboards or, you know, engineering mock-ups or something like that, once you then go to – 123 00:13:29,400 --> 00:13:39,740 so, for example, one of my clients was building mass spectrometers and they had these ion chambers, titanium ion chambers. 124 00:13:39,740 --> 00:13:43,460 Once you start buying those kinds of things, you've committed a lot of cost. 125 00:13:43,560 --> 00:13:45,100 And so, the cost of change goes up. 126 00:13:45,720 --> 00:13:51,220 So, in a hardware project, you actually have a front end that is agile and a back end that is more traditional. 127 00:13:52,000 --> 00:13:57,180 And if you can do that, you can actually come out a lot better with hardware projects. 128 00:13:57,540 --> 00:14:00,160 But it's very difficult to get a team who can do both. 129 00:14:01,620 --> 00:14:02,020 Yeah. 130 00:14:02,300 --> 00:14:06,880 I mean, there's that certain, like, extreme flexibility at the beginning, but then you better lock it down 131 00:14:06,880 --> 00:14:10,680 or it does – it becomes immeasurably more expensive to change things at the end. 132 00:14:10,860 --> 00:14:11,460 That's right. 133 00:14:11,560 --> 00:14:13,640 And it's all around cost of change. 134 00:14:13,740 --> 00:14:19,220 And so, one of the strategies that I talk about in the project management book is that even if you're in hardware development, 135 00:14:19,380 --> 00:14:25,960 that the longer you can keep development in bits rather than atoms, the more flexibility and adaptability you're going to have. 136 00:14:25,960 --> 00:14:35,440 Yeah, 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 137 00:14:35,440 --> 00:14:41,180 or how you get more of the flexibility of software involved in hardware when you combine these two things together, 138 00:14:41,700 --> 00:14:49,700 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. 139 00:14:49,700 --> 00:14:54,840 Or I should say it brings as much discipline as you sort of want to apply to it, including quite a bit. 140 00:14:55,420 --> 00:15:00,460 And that it's interesting looking at other ways of going about software development 141 00:15:00,460 --> 00:15:07,080 and realizing that in certain forms, agile development has actually a fair amount of discipline 142 00:15:07,080 --> 00:15:11,520 when compared to the hardware development discipline that you have. 143 00:15:12,060 --> 00:15:16,060 And that there's actually the chance for a lot more compatibility between agile software development 144 00:15:16,060 --> 00:15:20,600 and the discipline in embedded systems than there is in sort of other methodologies 145 00:15:20,600 --> 00:15:25,620 that sort of expect a lot more change down the road necessarily. 146 00:15:26,220 --> 00:15:26,340 Right. 147 00:15:26,340 --> 00:15:32,020 And it does seem like there's an interesting opportunity there that isn't sort of immediately intuitive at first. 148 00:15:32,780 --> 00:15:33,600 I think so. 149 00:15:33,680 --> 00:15:37,580 And I think it's a little more difficult in the hardware environment. 150 00:15:37,640 --> 00:15:41,880 But I also think that it's pretty important. 151 00:15:42,020 --> 00:15:48,780 Preston Smith, for example, is kind of a hardware developer who's sort of the agile hardware development, 152 00:15:49,400 --> 00:15:51,780 has written a book on flexible product development. 153 00:15:52,460 --> 00:16:00,180 And so trying to bring that idea of flexibility, adaptability, experimentation, innovation into the hardware realm. 154 00:16:00,880 --> 00:16:06,340 And it's a little bit more difficult there, but not impossible. 155 00:16:06,940 --> 00:16:07,360 That's right. 156 00:16:07,900 --> 00:16:12,420 I think there's a reason that there's an extreme difference between hardware and software people. 157 00:16:12,560 --> 00:16:16,560 It's just sort of different mindsets that enjoy those problem sets. 158 00:16:16,840 --> 00:16:17,020 Yeah. 159 00:16:18,340 --> 00:16:28,640 Jim, allow me to stay for one more minute on this point of hardware use software, as Koze has just mentioned. 160 00:16:30,380 --> 00:16:42,100 If I do an agile project within the context of an overall environment in which there are a bunch of waterfall projects, 161 00:16:42,620 --> 00:16:51,540 what would be your good counsel in terms of being able to run with an agile project in an unconstrained manner? 162 00:16:52,280 --> 00:16:58,820 Namely, in the context of a component development which has both software and hardware, 163 00:16:59,460 --> 00:17:04,440 you recommended to stay as long as you can with the bits instead of the atoms. 164 00:17:04,980 --> 00:17:15,680 What would be your good counsel about an agile project in the context of some waterfall project or some linear phase gates? 165 00:17:17,680 --> 00:17:23,000 Well, obviously, you know, I mean, that's an issue when people are doing big projects, 166 00:17:23,140 --> 00:17:26,980 when they're doing enhancements on big legacy projects. 167 00:17:28,240 --> 00:17:31,200 And really, it's a matter of synchronization. 168 00:17:32,460 --> 00:17:38,640 So you may have an agile project that's running on two- or three-week iterations, 169 00:17:39,320 --> 00:17:43,980 but every now and then you have a milestone or call it the end of a wave 170 00:17:43,980 --> 00:17:48,540 where you have something that links up to a hardware project. 171 00:17:48,540 --> 00:17:53,820 So maybe you have a hardware project that's running two-month iterations or three-month iterations. 172 00:17:54,540 --> 00:18:00,440 In the beginning, maybe the hardware projects are running even faster iterations on breadboards and mock-ups kinds of things. 173 00:18:00,440 --> 00:18:11,260 So it really, at that point, is a matter of synchronizing the various timeframes at some integration milestone. 174 00:18:12,800 --> 00:18:22,760 And then also, if there are some dependencies, is to, you know, work ahead of time on some of those dependencies, 175 00:18:23,520 --> 00:18:28,500 just as you would if you had, for example, two waterfall kind of projects running in parallel. 176 00:18:28,840 --> 00:18:34,480 You wouldn't wait until the final bell until you looked at some of the interdependencies. 177 00:18:35,340 --> 00:18:37,380 So you do the same thing with an agile project. 178 00:18:37,380 --> 00:18:40,200 So, you know, it requires more coordination. 179 00:18:40,380 --> 00:18:43,060 It requires more dependency management. 180 00:18:43,300 --> 00:18:52,320 It requires more looking at just what's going to be available to integrate, for example, at each of the synchronization points. 181 00:18:52,800 --> 00:19:02,760 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, 182 00:19:02,840 --> 00:19:05,340 but you were just starting up with agile. 183 00:19:05,340 --> 00:19:14,180 It does make sometimes a little bit more difficulty in terms of testing harnesses and testing cases and continuous integration. 184 00:19:14,580 --> 00:19:23,660 It makes it a little more difficult to do, but it can be done for both an agile software project and a hardware project 185 00:19:23,660 --> 00:19:30,820 or an agile software project running in parallel with some traditional waterfall software project. 186 00:19:32,020 --> 00:19:33,180 Understood. Thank you. 187 00:19:33,980 --> 00:19:40,500 So one of the other four new areas you were talking about was sort of release planning, essentially. 188 00:19:40,840 --> 00:19:47,980 And to your point, as you were saying, a lot of the focus on agile software development is on the iteration planning 189 00:19:47,980 --> 00:19:49,300 and focusing on the iteration. 190 00:19:49,300 --> 00:19:57,660 And, you know, usually the idea of release planning, it can seem kind of and gets treated sometimes like sort of obligatory bookends 191 00:19:57,660 --> 00:19:58,680 on a bunch of iterations. 192 00:19:59,420 --> 00:20:07,040 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. 193 00:20:07,260 --> 00:20:07,420 Yeah. 194 00:20:07,660 --> 00:20:09,420 And I wonder how that's evolved for you. 195 00:20:09,780 --> 00:20:10,880 I think that's really critical. 196 00:20:11,400 --> 00:20:15,380 I have always, since the beginning, stressed release planning over iteration planning. 197 00:20:15,380 --> 00:20:21,500 I figure if you've got a good iteration plan, then iteration planning just kind of falls out. 198 00:20:21,500 --> 00:20:26,080 So I've always looked at looking at the entire release as important. 199 00:20:26,720 --> 00:20:35,700 One of the things that I have gotten feedback from managers here in this country, in Australia, New Zealand, in Germany, 200 00:20:36,120 --> 00:20:43,200 and several other places is that they have agile teams who are basically working at an iteration at a time level 201 00:20:43,200 --> 00:20:49,800 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? 202 00:20:49,940 --> 00:20:52,380 You know, give me some constraints on this project. 203 00:20:53,240 --> 00:20:57,120 And, you know, the response from some of these teams is, well, that's not agile. 204 00:20:58,380 --> 00:21:03,580 And in many companies, you know, you have to have some budgeting types of things. 205 00:21:03,640 --> 00:21:04,840 You have to have some scheduling. 206 00:21:05,240 --> 00:21:09,980 Whether it's internal and you need to know when to get people trained or ready for the release 207 00:21:09,980 --> 00:21:14,760 or whether you've got a product that's going to the marketplace and you've got to have, you know, 208 00:21:14,760 --> 00:21:18,800 there's a lot of marketing stuff that's got to go into place for a big product release. 209 00:21:19,460 --> 00:21:28,280 And so there's some reaction in the agile community to having scope and schedule kind of nailed down for them before. 210 00:21:28,860 --> 00:21:32,280 And now the alternative is not to do any of that. 211 00:21:32,840 --> 00:21:36,180 And so I think it's, you know, fairly important to do that. 212 00:21:36,760 --> 00:21:43,940 So, you know, and also to have multi-level plans and not just a story and a feature level, 213 00:21:43,940 --> 00:21:53,440 but maybe a capability feature and story level so that you look at, say, a product roadmap for a year or 18 months 214 00:21:53,440 --> 00:21:56,740 at the level of a business capability or a product capability. 215 00:21:57,140 --> 00:22:02,400 You look at a release plan, maybe a three- to six-month release plan at a feature level, 216 00:22:02,640 --> 00:22:05,060 and you look at an iteration plan at a story level. 217 00:22:05,060 --> 00:22:18,700 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, 218 00:22:18,700 --> 00:22:26,540 but they give you sort of a feasibility of the project and some broad constraints on that project. 219 00:22:26,740 --> 00:22:35,380 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. 220 00:22:35,540 --> 00:22:41,540 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. 221 00:22:42,160 --> 00:22:51,020 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, 222 00:22:51,080 --> 00:22:55,760 whatever, whether it's, you know, weekly or monthly or whatever iterations that you have, you know, 223 00:22:55,840 --> 00:23:02,720 especially, you know, when you raise up marketing concerns, that seems like one of the areas where if you were an ISV, for example, 224 00:23:02,720 --> 00:23:11,180 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, 225 00:23:11,320 --> 00:23:17,780 would sort of be probably not too delightfully surprised at what release they end up with at the end. 226 00:23:17,800 --> 00:23:22,620 Right. One of the things that I sometimes talk about is the difference between iteration and oscillation. 227 00:23:23,280 --> 00:23:31,620 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, 228 00:23:31,880 --> 00:23:37,980 you get so caught up in iterations that you can actually get to oscillating rather than iterating. 229 00:23:38,020 --> 00:23:42,280 In other words, you're just kind of going around in circles rather than progressing towards some goal. 230 00:23:42,800 --> 00:23:50,660 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, 231 00:23:50,880 --> 00:23:55,160 or at a technical level where you're just sort of refactoring and refactoring and refactoring. 232 00:23:55,800 --> 00:24:03,220 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. 233 00:24:03,220 --> 00:24:12,320 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, 234 00:24:13,420 --> 00:24:18,880 like how can people on the other side of that, sort of whether they're marketing folks or the budget folks, 235 00:24:18,940 --> 00:24:26,660 like how can they kind of interact with the development process to kind of aid, to make better keeping your eye on the goal 236 00:24:26,660 --> 00:24:29,400 and like keeping an eye on the final release? 237 00:24:29,400 --> 00:24:39,260 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? 238 00:24:39,260 --> 00:24:47,740 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. 239 00:24:48,040 --> 00:24:55,300 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, 240 00:24:55,420 --> 00:25:00,360 but don't get as much involved at the iteration planning and development level. 241 00:25:00,860 --> 00:25:05,680 And so you have product specialists that are getting involved at the detail level. 242 00:25:05,780 --> 00:25:10,460 And maybe you have the product manager who really doesn't get quite as involved at that level. 243 00:25:10,460 --> 00:25:17,480 So you may have different levels of involvement given the different levels of planning and not only in the planning, 244 00:25:17,480 --> 00:25:23,800 but also, for example, maybe the product specialists or the people that are working directly with the iteration, 245 00:25:24,220 --> 00:25:28,240 they get to look at the feature demos at the end of the iteration, 246 00:25:28,240 --> 00:25:40,440 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, 247 00:25:40,660 --> 00:25:45,860 they get involved in a demo of those major features or capabilities. 248 00:25:45,860 --> 00:25:56,600 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. 249 00:25:57,200 --> 00:26:03,180 And so I think you do get those marketing and salespeople involved, but maybe just not every iteration. 250 00:26:03,740 --> 00:26:05,100 Right. That's interesting. 251 00:26:06,060 --> 00:26:15,880 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. 252 00:26:16,180 --> 00:26:24,660 And, 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? 253 00:26:25,160 --> 00:26:31,400 Well, there – to me, there were two kinds of scaling issues, scaling up, which means bigger projects, 254 00:26:31,480 --> 00:26:33,700 and scaling out, which means distributed projects. 255 00:26:34,320 --> 00:26:43,460 And the scaling up is what happens if you have a 600-person team versus a 10- or 15-person team. 256 00:26:44,120 --> 00:26:52,800 And there are a couple of major factors in there, one of which is the organizational design, 257 00:26:53,340 --> 00:26:56,980 the second of which is communication collaboration design, 258 00:26:57,140 --> 00:27:03,740 and the third of which is something that very few people talk about, which is decision design. 259 00:27:04,320 --> 00:27:10,540 How do decisions get made in a 500-person team versus a 15-person team? 260 00:27:11,000 --> 00:27:16,180 You can't have all 500 people involved in every detailed decision that the team makes. 261 00:27:16,820 --> 00:27:27,900 And so how you design how those decisions are made then turn into working agreements between teams on this overall large team. 262 00:27:28,120 --> 00:27:36,420 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. 263 00:27:36,760 --> 00:27:40,240 You have working agreements at a team-to-team level. 264 00:27:40,640 --> 00:27:45,860 And a lot of those things have to do with who gets to make what kinds of decisions. 265 00:27:47,020 --> 00:27:54,320 So I think all three of those things, decision-making, communications collaboration design, and organizational design, 266 00:27:54,640 --> 00:27:59,220 go into designing a large agile team. 267 00:27:59,900 --> 00:27:59,960 Right. 268 00:28:00,160 --> 00:28:04,260 So it sounds like you sort of established some principles, if you will. 269 00:28:04,500 --> 00:28:12,980 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 270 00:28:12,980 --> 00:28:18,320 and syncing up and kind of passing around the baton of authority to let people make decisions. 271 00:28:19,080 --> 00:28:26,440 And it sounds like what you're getting at is you try to establish some rules that allow intra-team decisions to be made 272 00:28:26,440 --> 00:28:30,800 without having to call lengthy meetings, you know, to ground it a little bit at the same time. 273 00:28:30,800 --> 00:28:36,200 And coming up with a way that, you know, who's sort of responsible for making this decision 274 00:28:36,200 --> 00:28:41,880 and who should you talk with about making these different decisions and kind of progressing without – 275 00:28:41,880 --> 00:28:46,080 I mean, I guess once you clearly decide – once you clearly define how decisions are made, 276 00:28:46,520 --> 00:28:51,300 you can spend a lot less time each time a major decision comes up figuring out how you're going to make a decision. 277 00:28:51,680 --> 00:28:52,280 That's right. 278 00:28:52,280 --> 00:29:01,080 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 279 00:29:01,080 --> 00:29:05,300 feel like they have some input and some influence on the decisions. 280 00:29:05,640 --> 00:29:12,260 And so you may have – for example, if you have an architecture team, you'll have membership in an architecture team 281 00:29:12,260 --> 00:29:16,700 from all the feature teams or several of the feature teams. 282 00:29:17,340 --> 00:29:22,240 Their senior people or developers or testers will be part of that architecture team. 283 00:29:22,240 --> 00:29:30,460 So they get direct input to the decisions and they also get involved in those decisions. 284 00:29:31,060 --> 00:29:33,180 And so there's cross-linking between teams. 285 00:29:33,540 --> 00:29:37,460 And one of the things that does happen, you know, in larger teams, like you say, 286 00:29:37,520 --> 00:29:41,300 is you do feel – spend more time on communication and collaboration. 287 00:29:41,300 --> 00:29:44,180 It's just part of having a bigger team. 288 00:29:44,180 --> 00:29:49,060 One of the – one of the phenomenas that I've found very interesting in bigger projects 289 00:29:49,060 --> 00:29:57,940 is you'll have agile teams who are basically customers of other agile teams. 290 00:29:58,000 --> 00:30:02,560 In other words, another agile team will have some component that they need to deliver. 291 00:30:03,160 --> 00:30:10,780 And the first agile team who is the customer of the other agile team, they're the worst customers in the world. 292 00:30:12,120 --> 00:30:16,220 They don't want to take the time to do the requirements, to do the acceptance testing, 293 00:30:16,340 --> 00:30:19,360 to do the – you know, to talk about the requirements. 294 00:30:19,880 --> 00:30:23,760 If their customers treated them that way, they would raise hell. 295 00:30:24,300 --> 00:30:28,000 But they're willing to treat other teams that way when they're the customers. 296 00:30:28,000 --> 00:30:32,480 And so that's one of the things that I talk about with a lot of teams, bigger teams, 297 00:30:32,620 --> 00:30:41,400 is how you have to be sometimes a customer and put that time and energy into being a customer. 298 00:30:41,900 --> 00:30:42,060 Yeah. 299 00:30:42,180 --> 00:30:47,480 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 300 00:30:47,480 --> 00:30:52,520 than you would if you were in small scale because you're expected to behave in that role. 301 00:30:52,620 --> 00:30:59,120 Yeah, that is interesting to – I can imagine that especially in software development teams would prefer not to have 302 00:30:59,120 --> 00:31:05,380 the luxurious amount of specification it takes to actually figure out what, you know, what someone wants to code. 303 00:31:06,040 --> 00:31:10,660 And there's sort of like this assumption that because we're all developers, we can kind of like, you know, 304 00:31:10,720 --> 00:31:13,720 just wink and nod at each other and understand what the requirements are. 305 00:31:14,600 --> 00:31:22,060 But what's interesting is that the agile team who's the customer, also they tend to make completely unreasonable demands 306 00:31:22,060 --> 00:31:24,000 on the component teams that are feeding them. 307 00:31:24,520 --> 00:31:24,640 Right. 308 00:31:25,000 --> 00:31:29,000 It's like, again, if their customers, you know, treated them like that, they'd be really upset. 309 00:31:29,540 --> 00:31:37,700 But they don't see themselves in the role of a customer in that kind of inter-team component that gets done. 310 00:31:37,800 --> 00:31:39,960 They don't really see themselves in the role of a customer. 311 00:31:40,140 --> 00:31:42,620 And oftentimes I have to point that out to them. 312 00:31:42,740 --> 00:31:47,860 Yeah, they start giving requirements like feature must be robust and enterprise-grade 313 00:31:47,860 --> 00:31:51,060 and other big things that make no sense. 314 00:31:51,360 --> 00:31:51,560 Right. 315 00:31:51,620 --> 00:31:54,720 Or we must have it by this iteration as opposed to – 316 00:31:54,720 --> 00:31:55,200 Even better. 317 00:31:56,840 --> 00:31:57,400 That's right. 318 00:31:57,400 --> 00:32:09,240 Jim, what do you see as the effect of the scaling out on the set of scale-up problems that we have just discussed? 319 00:32:09,420 --> 00:32:17,160 Obviously, at a certain point in time, any scaling up would become, by necessity, a scale-out as well. 320 00:32:17,820 --> 00:32:19,920 How do you see the interplay between the two? 321 00:32:21,780 --> 00:32:30,960 Usually, I sort of like Dean Leffingwell's comment that at scale all projects are distributed. 322 00:32:31,820 --> 00:32:42,360 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. 323 00:32:43,540 --> 00:32:51,180 And that knowledge sharing, informal knowledge sharing begins to break down pretty quickly in groups exceeding a couple hundred. 324 00:32:52,080 --> 00:33:01,040 And 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, 325 00:33:01,540 --> 00:33:08,820 they're probably going to be at least on different floors of a building or in different areas of a building. 326 00:33:09,320 --> 00:33:18,000 And I know with one large team of about 600 a few years ago, I came up with the term virtual co-location. 327 00:33:18,620 --> 00:33:23,920 And what I wanted them to do is I wanted them to act as if they were co-located even when they weren't. 328 00:33:24,940 --> 00:33:38,780 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. 329 00:33:39,000 --> 00:33:47,560 In distributed projects, then you have another set of constraints, which tends to be distance, number one, 330 00:33:47,680 --> 00:33:55,080 because even if you're in the same building, you can get together to do iteration plans or release plans pretty inexpensively. 331 00:33:55,180 --> 00:33:57,600 If you distribute it, that's more expensive. 332 00:33:58,280 --> 00:34:04,800 So distance does have some impact on the team and being able to get together to do stuff. 333 00:34:05,760 --> 00:34:14,340 Company cultures and country cultures tend to impact here, and also time zones, as you know from your projects, Israel. 334 00:34:14,520 --> 00:34:21,880 So there are some additional factors with distributed projects over and above just larger projects. 335 00:34:21,880 --> 00:34:26,940 But once you start talking about the issues of communication and collaboration in large projects, 336 00:34:27,160 --> 00:34:33,300 many of those things are the same kinds of issues you deal with in distributed projects. 337 00:34:34,300 --> 00:34:44,140 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. 338 00:34:44,400 --> 00:34:50,480 Maybe we would fly at least for a few days, or then for more than a few days, 339 00:34:50,480 --> 00:34:57,920 we will fly folks from offshore locations, either to Austin, Texas or to Houston, Texas, 340 00:34:58,240 --> 00:35:02,980 in order to be able to be able to, at least for a period of time, to be co-located. 341 00:35:02,980 --> 00:35:10,120 So my own experience has been that overcoming the difficulties of distribution, 342 00:35:10,760 --> 00:35:19,940 or distributed environments, or scale out, as you call it, 343 00:35:20,340 --> 00:35:27,440 really requires additional investment of money, so you have got to plan and budget for it. 344 00:35:27,440 --> 00:35:38,140 Otherwise, the mechanisms of communication and collaboration, which are available across the fund, are often insufficient. 345 00:35:38,800 --> 00:35:44,420 Right. So when I look at scaling and distribution factors, I look at the product architecture. 346 00:35:44,920 --> 00:35:55,440 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? 347 00:35:55,500 --> 00:35:57,540 If it's highly integrated, that's one issue. 348 00:35:59,000 --> 00:36:03,340 Relationships. Do the people who are distributed have existing relationships? 349 00:36:03,480 --> 00:36:05,120 So they're pretty well unknown to each other. 350 00:36:05,860 --> 00:36:13,380 And then project complexity, you know, how big, how many people, how distributed is it, those kinds of things. 351 00:36:13,700 --> 00:36:17,420 And then the particular practices that you're using. 352 00:36:17,560 --> 00:36:23,300 So, for example, one of the things you said is you brought together people together to do release planning. 353 00:36:24,100 --> 00:36:32,720 And release planning is a fairly involved practice where you really do need to get high levels of communication and understanding. 354 00:36:33,280 --> 00:36:45,220 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. 355 00:36:45,440 --> 00:36:54,900 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. 356 00:36:55,740 --> 00:37:01,080 Yeah, you'd like to have everybody be able to get together every day, but that may not be possible. 357 00:37:01,080 --> 00:37:12,380 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. 358 00:37:14,140 --> 00:37:14,660 Indeed. 359 00:37:15,780 --> 00:37:26,840 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. 360 00:37:26,920 --> 00:37:30,780 Well, it actually is more strategic than detail. 361 00:37:31,260 --> 00:37:31,620 Right, right. 362 00:37:31,940 --> 00:37:44,880 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? 363 00:37:45,280 --> 00:37:47,780 Number one is value. 364 00:37:47,780 --> 00:37:52,100 And so, but I want to look at value from a strategic perspective. 365 00:37:52,520 --> 00:37:56,580 I'm not looking at the detailed requirements or even the detailed stories. 366 00:37:56,860 --> 00:38:06,560 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? 367 00:38:06,620 --> 00:38:16,240 So I'm looking at is this product releasable and did we do it within certain business objectives and constraints? 368 00:38:16,540 --> 00:38:17,760 So number one is value. 369 00:38:18,200 --> 00:38:21,340 Number two is actually quality. 370 00:38:22,040 --> 00:38:41,900 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. 371 00:38:41,900 --> 00:38:47,140 So reliable, so reliable, adaptable product is the quality aspect, which is number two. 372 00:38:47,960 --> 00:38:50,600 And then the third is really what I call constraints. 373 00:38:51,220 --> 00:38:56,040 And constraints are the traditional measures of cost, schedule, and scope. 374 00:38:56,700 --> 00:39:01,560 So cost and schedule aren't goals. 375 00:39:01,920 --> 00:39:02,760 They're constraints. 376 00:39:03,760 --> 00:39:05,920 And even scope is not a goal. 377 00:39:05,920 --> 00:39:12,560 It's a constraint on do I have enough capability to release this project. 378 00:39:13,300 --> 00:39:25,660 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, 379 00:39:26,260 --> 00:39:33,380 and then really looking at kind of fuzzier quantities of value and quality. 380 00:39:33,560 --> 00:39:34,940 They're fuzzier, but they're more important. 381 00:39:34,940 --> 00:39:43,620 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. 382 00:39:44,000 --> 00:39:45,240 Like lines of code or something like that. 383 00:39:45,240 --> 00:39:47,280 Like lines of code or even like cost and schedule. 384 00:39:47,440 --> 00:39:52,140 Cost and schedule are measurable, but they're not necessarily the most important thing. 385 00:39:52,140 --> 00:40:15,320 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. 386 00:40:15,320 --> 00:40:15,660 Yeah. 387 00:40:15,660 --> 00:40:23,840 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. 388 00:40:23,840 --> 00:40:26,780 That we have to really focus on these other things. 389 00:40:27,200 --> 00:40:31,920 And quite frankly, I've had enormous response to this. 390 00:40:33,200 --> 00:40:35,740 I haven't had anybody yet say, oh, this is crazy. 391 00:40:36,120 --> 00:40:39,500 I have had people say, I'm not sure this will fly in my organization. 392 00:40:40,000 --> 00:40:42,720 Yeah, well, that's usually the response that means you're on to something. 393 00:40:44,660 --> 00:40:51,380 But, again, I want people to think of the strategic issues around value and quality. 394 00:40:52,160 --> 00:41:02,840 And interestingly enough, once you start focusing upper management on those things, their sort of focus on cost and schedule decreases. 395 00:41:04,240 --> 00:41:09,820 You know, they can see that they're getting value, for example. 396 00:41:10,200 --> 00:41:27,400 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? 397 00:41:27,780 --> 00:41:28,040 Right. 398 00:41:28,700 --> 00:41:35,420 And my guess is most executives would pick the 75% of cost for the 90% of the value. 399 00:41:35,560 --> 00:41:45,700 And so, by looking at value all the way along an Agile project, you can actually begin to say, where's the right cutoff? 400 00:41:45,800 --> 00:41:47,620 When do I need to actually release this product? 401 00:41:48,000 --> 00:41:56,020 I don't have 100% of the stories that I would really like to have, but I've got the most valuable ones. 402 00:41:56,080 --> 00:41:58,020 I've got the 90% most valuable ones. 403 00:41:58,280 --> 00:42:00,880 And now's the time to cut this project off. 404 00:42:00,880 --> 00:42:06,360 So I think in that way, you actually end up potentially with tremendous cost savings as well. 405 00:42:06,920 --> 00:42:20,220 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? 406 00:42:20,220 --> 00:42:31,120 I 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. 407 00:42:31,200 --> 00:42:37,820 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? 408 00:42:37,820 --> 00:42:50,860 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. 409 00:42:50,860 --> 00:43:00,140 And I think we have to educate product managers to this value-cost curve and to getting the most value out early. 410 00:43:01,320 --> 00:43:16,640 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. 411 00:43:17,240 --> 00:43:37,300 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. 412 00:43:37,500 --> 00:43:49,180 And 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. 413 00:43:50,460 --> 00:43:59,380 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. 414 00:43:59,540 --> 00:44:13,080 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, 415 00:44:13,080 --> 00:44:19,760 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. 416 00:44:19,760 --> 00:44:33,700 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. 417 00:44:34,060 --> 00:44:55,800 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. 418 00:44:55,920 --> 00:45:01,580 And 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. 419 00:45:01,900 --> 00:45:04,920 And my response to this is, okay, we don't have time to calculate cost then. 420 00:45:05,480 --> 00:45:05,800 Right, right. 421 00:45:05,860 --> 00:45:18,860 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, 422 00:45:18,860 --> 00:45:28,480 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. 423 00:45:28,640 --> 00:45:39,580 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. 424 00:45:39,580 --> 00:45:54,220 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. 425 00:45:54,340 --> 00:45:58,320 In other words, they don't have dollars on them, but they're relative to each other. 426 00:45:58,420 --> 00:46:05,000 So within a project, you know what the higher value things are and the lower value things are relatively. 427 00:46:05,980 --> 00:46:06,460 Right. 428 00:46:06,860 --> 00:46:18,880 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. 429 00:46:19,460 --> 00:46:26,380 Their emphasis right now on value and on event value is at a much higher level than I would have expected. 430 00:46:26,720 --> 00:46:45,700 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. 431 00:46:47,300 --> 00:46:55,000 And that has been a point in the Agile community for quite some time is to focus on value and focus on incremental value. 432 00:46:56,120 --> 00:47:02,980 But we haven't really gotten rid of or changed the overall kind of Iron Triangle approach. 433 00:47:03,060 --> 00:47:12,640 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. 434 00:47:12,640 --> 00:47:13,960 And they're still important. 435 00:47:13,960 --> 00:47:20,580 And this is a major premise in your book, correct? 436 00:47:21,360 --> 00:47:21,620 Yes. 437 00:47:23,240 --> 00:47:36,260 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. 438 00:47:36,740 --> 00:47:46,800 It has a critical piece of how we have to move in order to get Agile more established in bigger companies. 439 00:47:47,460 --> 00:47:47,860 Yeah. 440 00:47:48,080 --> 00:47:51,340 And to kind of get to the point, we're actually delivering valuable software. 441 00:47:51,600 --> 00:47:54,120 And you have the whole process underneath it that supports that. 442 00:47:54,600 --> 00:47:54,960 Right. 443 00:47:55,440 --> 00:47:58,580 So, we haven't actually mentioned the name of the book now that I think about it. 444 00:48:00,020 --> 00:48:05,300 But before we wrap up, I mean, we've said that it's a second edition of it. 445 00:48:05,360 --> 00:48:09,020 But what's the actual title of the book and what's the availability of it? 446 00:48:09,500 --> 00:48:14,020 It's Agile Project Management, Creating Innovative Products, second edition. 447 00:48:14,680 --> 00:48:24,620 And it is already available on Amazon and Amazon Canada within the next couple of weeks to other countries. 448 00:48:24,740 --> 00:48:26,360 But it is out and available. 449 00:48:27,000 --> 00:48:33,000 And, you know, unless Israel had any other sort of on-topic questions, I just had one little slightly off-topic question. 450 00:48:33,800 --> 00:48:34,200 Okay. 451 00:48:34,760 --> 00:48:37,680 And of course I have an off-topic question, Mike. 452 00:48:37,840 --> 00:48:38,380 You know me. 453 00:48:38,660 --> 00:48:39,340 That's right. 454 00:48:40,340 --> 00:48:41,900 Well, you want to go ahead then? 455 00:48:43,020 --> 00:48:49,160 Well, may I ask you, Jim, to do a retrospective on the past eight years. 456 00:48:49,360 --> 00:48:57,400 You have been one of the originators and signers of the Agile Manifesto just about eight years ago. 457 00:48:58,060 --> 00:49:04,980 When you take a look at the road we have traversed since then, what do you feel? 458 00:49:05,260 --> 00:49:11,000 What is your assessment of what we have done well and what perhaps we have done in a different manner? 459 00:49:11,000 --> 00:49:14,680 Well, it's interesting. 460 00:49:14,880 --> 00:49:17,840 There's a couple of big things happening this year. 461 00:49:19,040 --> 00:49:22,680 They're at the Agile conference in August in a few weeks. 462 00:49:23,220 --> 00:49:32,300 There's going to be a joint launch of the PMI, Project Management Institute, Community of Practice of Agile. 463 00:49:32,460 --> 00:49:36,880 So PMI is getting active in the Agile world. 464 00:49:36,880 --> 00:49:47,540 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. 465 00:49:48,340 --> 00:50:00,600 And so you have two of the organizations that have been somewhat antithetical to the Agile movement becoming involved in the Agile movement. 466 00:50:00,780 --> 00:50:02,700 So I think that's significant. 467 00:50:03,220 --> 00:50:12,820 I think it parallels the fact that seven or eight years ago what we did in Agile was really small projects, small transitions. 468 00:50:14,560 --> 00:50:18,800 What I call rogue project teams within organizations were doing Agile. 469 00:50:19,700 --> 00:50:26,880 Three, four, five years, three or four years ago, we started getting more bigger organizations. 470 00:50:27,040 --> 00:50:38,900 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. 471 00:50:39,620 --> 00:50:46,080 I did one in 2005, 2006, involved about 600 people in development and engineering. 472 00:50:47,260 --> 00:50:56,000 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, 473 00:50:56,480 --> 00:51:02,660 where you have entire big organizations, and there are a number of these around the world. 474 00:51:03,580 --> 00:51:10,640 IBM, for example, there's pieces of IBM that have mentioned this 25,000 number internally also. 475 00:51:10,860 --> 00:51:14,020 So I think those are positive trends. 476 00:51:15,380 --> 00:51:27,080 On the maybe not so positive trend, I've also seen the reluctance in some Agile circles to be Agile, to be adaptable. 477 00:51:28,000 --> 00:51:36,740 They're sort of hung up on the specifics of one methodology or the other to almost a religious fervor 478 00:51:36,740 --> 00:51:47,980 and are not willing to begin to integrate things from either other Agile practices or things like CMM and PMI. 479 00:51:48,280 --> 00:51:50,320 They are still resistant to that. 480 00:51:50,320 --> 00:51:55,620 So that would be one of my probably comments about something that's not as positive. 481 00:51:58,000 --> 00:51:59,640 Well, that's a nice overview. 482 00:52:00,860 --> 00:52:10,680 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. 483 00:52:11,380 --> 00:52:19,020 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, 484 00:52:19,100 --> 00:52:21,360 or is it just sort of like a straight conversion of the book? 485 00:52:21,360 --> 00:52:27,100 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. 486 00:52:27,160 --> 00:52:27,420 I don't know. 487 00:52:27,480 --> 00:52:29,160 I'm kind of curious how that process works. 488 00:52:29,260 --> 00:52:32,560 Well, number one, I don't get involved in it at all. 489 00:52:33,220 --> 00:52:37,140 Number two, the Kindle edition is out already. 490 00:52:37,280 --> 00:52:37,740 Oh, okay. 491 00:52:37,740 --> 00:52:52,360 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. 492 00:52:52,980 --> 00:52:53,840 There you go. 493 00:52:54,700 --> 00:53:03,360 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? 494 00:53:03,680 --> 00:53:09,440 And, you know, obviously, not having to pay for it, and I don't have an answer to that one yet. 495 00:53:09,780 --> 00:53:10,480 Yeah, yeah, yeah. 496 00:53:10,760 --> 00:53:19,680 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, 497 00:53:19,700 --> 00:53:28,840 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. 498 00:53:30,920 --> 00:53:32,560 Not that I have seen yet. 499 00:53:32,600 --> 00:53:34,280 Like I said, I didn't get involved in it. 500 00:53:34,600 --> 00:53:34,820 Yeah, yeah. 501 00:53:36,300 --> 00:53:36,520 Huh. 502 00:53:36,640 --> 00:53:37,340 Well, that's interesting. 503 00:53:37,500 --> 00:53:40,900 Well, I mean, thanks for spending all this time to talk with us today. 504 00:53:40,980 --> 00:53:54,760 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, 505 00:53:54,760 --> 00:54:02,920 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, 506 00:54:03,060 --> 00:54:14,920 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. 507 00:54:15,540 --> 00:54:15,700 Right. 508 00:54:16,620 --> 00:54:17,340 Well, that's great. 509 00:54:17,400 --> 00:54:19,280 Well, thanks for talking with us today. 510 00:54:19,560 --> 00:54:19,740 That was a good time. 511 00:54:19,740 --> 00:54:20,220 Well, thank you. 512 00:54:20,300 --> 00:54:20,980 I enjoyed it. 513 00:54:21,320 --> 00:54:21,720 Definitely. 514 00:54:21,720 --> 00:54:22,540 Thanks so much, Ian.