Twenty years of agile

Podcast transcript

Alexey Bôas:

Hello, and welcome to the Thoughtworks Technology Podcast. My name is Alexey Villas Bôas. I'm speaking from São Paulo in Brazil, and I will be one of your hosts this time, together with Mike Mason. Hello, Mike.

Mike Mason:

Hi, Alexey. How're you doing?

Alexey Bôas:

This time, we're very privileged to have Jim Highsmith and Martin Fowler here with us. Hello, Jim. How are you?

Jim Highsmith:

Hi, Alexey. I'm doing great.

Martin Fowler:

Yeah, this is the first time in even the same virtual space for ages.

Alexey Bôas:

Yeah, thank you very much, Martin and Jim, for joining. I'm sure this is widely known. Most people know that Jim and Martin are two of the authors of The Agile Manifesto, which is turning 20 years old, this year. So why don't we start there? Many people tell the history and talk about Manifesto, but here's an opportunity to hear it from you. I won't resist asking the silly question. What's The Agile Manifesto? How did it come to be? Can you talk a little bit about the meeting and some of Jim and Martin's history?

Martin Fowler:

I'll start off with me and Jim meeting. I was asked, and Jim obviously as well, to go to this conference thing going on in New Zealand in the late 90s. So I slogged it all the way down. It was my first trip down to the Antipodes, to well into New Zealand, this really lovely little city in New Zealand. I knew of one of the other headline speakers. It was Steve McConnell, whose books I was familiar with. But I didn't know Jim Highsmith at all. I don't think I'd even come across you, at this point. I sat to be listening, and I think the talk was entitled something like Project Management Tips or whatever. And I thought, oh my god, this going to be another crappy project-management talk and project planning and all that kind of rubbish. All my priors were very, very negative.

And this guy gets up on stage, who looked like a typical PMI, project management, older guy kind of thing. Oh, jeez. And then he starts spouting all this really good stuff and quite radical stuff. And I thought, wow, this is remarkably sensible. That was a shocker. Of course we actually met after that. We had the chance to meet up before he spoke, and we got to know each other a little bit.

Jim Highsmith:

Yeah, I remember that conference, because I had spoken at the software development conference in San Francisco the previous year. And the guy who ran the conferences in New Zealand asked me if I wanted to come to New Zealand and speak at a conference, and I didn't know this guy from anybody. But I called a couple of friends of mind, and they said, no, you ought to go. It's a pretty good trip. So Martin and I did meet, and one of the things that I think had happened is that a lot of the impetus towards, at that time, lightweight methodologies had come out of the OO community, Kent Beck and Martin and some other people. And that was not a community I was hooked into. My meeting with Martin helped that along.

And then Kent Beck and I swapped manuscripts of our two books that were coming out, his Extreme Programming and my Adaptive Software Development. And that led to a meeting in Oregon that Kent put together, to talk about XP. And there were a couple of non-XPers that were invited, myself, Alistair Cockburn. I don't if there was anybody else. That was the meeting before the manifesto meeting. Do you remember what we talked about there, Martin?

Martin Fowler:

Yeah, we talked about the future of XP. Oddly enough, I don't remember Alistair being there. I remember Prag-Dave being there. I thought he was, the other outsider, but my memory could be wrong, because my memories real wrong about these things. I do remember one thing in particular though that we talked about at that event, which was should extreme programming be this relatively narrow, well-defined thing with the 12 practices and all the rest of it? Or should it be this broader thing that encompassed a broader idea of what software development should be like in like what we now call Agile. And that was where XP, should it be narrow or should it be broad? And Kent decided he wanted it to be narrow, because he wanted it to be something that was much more well-defined than the broad, fuzzy thing that it would otherwise be, which of course then left open the question. Is there room for a broad, fuzzy thing in addition to the more concrete XP?

Jim Highsmith:

I remember walking down the road river at a break with Kent. He was talking a little bit about moving XP into organizations, and he was a little concerned with the moniker extreme programming. I said, "Kent, what are you going to call it? Moderate programming?"

Mike Mason:

How did it go from these initial connections to the meeting, the manifesto meeting? Did folks decide that a manifesto needed to be written, or was that something that came up at the meeting itself?

Martin Fowler:

That didn't come up before the meeting, although it was probably seeded into it. I don't remember. I know there was a general feeling amongst some people after the meeting in Oregon that we wanted to do something about this broader thing that was broader than extreme programming. And Bob was very keen to do that, and Bob says that we had lunch in Chicago, me and him, where we talked through a guest list. I have no memory of this lunch, but it's quite possible it happened, because my memory is really bad about all of these things. And I didn't keep a journal in those days. Just one thing, if I were able to go back to myself, 30 years ago, I would tell myself, "Keep a journal, please. I beg you."

But the group was assembled, and I don't think we had any particular agenda other than to exchange ideas. Because it was clear we were all doing similar things, and there was a lot of commonality to what we did. And there was a bit of an example in the object oriented world from a conference called WOOD, Workshop on Object-Oriented Development, which coincidentally, was also held at Snowbird. And it had been held there in the early 90s. And it brought together various OO folks. It was actually where I first met Kent and many of those folks. Those were just really to exchange ideas about this new object-oriented thing and how we'd spread it around. The idea was to do a similar kind of event but for people working on this lightweight method stuff. And it was only in that meeting, as I recall, that Bob said, "I'd like us to write a manifesto." I remember my reaction being, well we won't come up with anything worth while, but the exercise of trying to write one will probably be interesting. 

Jim Highsmith:

Yeah, it was a really interesting meeting, I've said. I've been in hundreds and hundreds of meetings over my career of some 54 years, and this was probably one of, if not the best meeting I'd ever been in. Because it just sort of flowed, and people were really focused on what some of the issues were. And different people got up and facilitated different parts of the meeting. You can imagine 17 fairly well-known people trying to all get some of their ideas in, and you would think it would be a very, very difficult meeting. But I think it went pretty easily, and like I say, people really focused on the industry and contributing to the industry, rather than personal profit.

Now, everybody wanted to make some money as they moved forward in their careers, but that wasn't the focus. The focus was what can we do for the industry that's going to change the industry? I think there was this niggling feeling that we had something there that could change the software development industry, but we weren't real confident that it would really happen.

Mike Mason:

And of course 20 years later, we know that it has and very much so. That must be incredible for you folks to have been part of that and to see this whole thing spread and become useful and drive the industry forwards.

Jim Highsmith:

Yeah, I think it turned out to be more than we had imagined or hoped for. Maybe in the back of some minds, there was hopefully this will help a lot, but I'm not sure that any of us thought it would take off the way it did. Then at the meeting, we wrote the values, but the 12 principles, we argued about for three months and rewrote them and rewrote them. We did that all online and through emails, it was a little bit more involved process. Then, people started writing articles about the manifesto. Martin and I wrote an article in the Summer of 2001 in Software Development magazine. Back then, they actually had real magazines that were printed as opposed to online. So it's changed a lot over the last 20 years.

Mike Mason:

How did that work with the article. Is that something where the magazine publishers are looking for articles, and you just submit something? Or was it because you had credentials? How did that come about?

Jim Highsmith:

I think part of it was we had credentials, because I had published several things in Software Development. Martin had written several books, and I had written Adaptive Software Development book that was out by that time. So I think part of it was just a credibility of not only Martin and I but the people who were behind the manifesto.

Martin Fowler:

I think I'd heard that it had happened. And of course the manifesto hadn't really made a big impact as soon as it was first published.

Jim Highsmith:

Right, and I think part of that impact was something that we just, and I don't know who thought of this maybe, but we did the manifesto, but then you could also sign in to the manifesto and sign and make comments about it. And there were just thousands and thousands and thousands of people who, over the years, signed on to that and wrote comments about how much it had impacted them. And I think that was something that probably happened, and it exceeded our expectations.

Martin Fowler:

Yeah, that was Ward's idea. Ward set that up. And yeah, that happened for quite a few years afterwards. People would still keep adding their... They would sign, which is where sometimes people refer to the manifesto office as the signatures. And then I get pedantic and say, no, we were the authors. The signatures are the thousands of people that have added stuff since. We shouldn't forget that, because it's their own way of indicating that they've been part of it, really.

Alexey Bôas:

And how about the spread of Agile to the industry and to the world. I'm sure you have lots of stories of successes and challenges of getting Agile into organization. Can you share some of those?

Jim Highsmith:

Obviously, we were combating the Waterfall methodologies of the time. One of the Waterfall methodologies was really Capability Maturity Model from the Software Engineering Institute. So, we set that up as a target. And I can remember speaking at one of the SEI conferences, and there was a panel discussion about was the Capability Maturity Model dead? And there were two people who said no, it would continue. And there were two of us, and I don't remember even who the other person was, that said no, it's destined for the scrap heap.

At the end of that conference, there was something that said to me, yup, that's what's going to kill this, is the evaluation of the conference was a 15-page thing. And I just said this is typical documentation-heavy kind of thing. So to me, that was one of the things that we had to fight was the documentation. And one of the things about Agile is people were concerned, in particular with XP, that it was sort of ad hoc and undisciplined. And I tried to point out continuously the difference between discipline and formal and that formality was one of the things that the Waterfall methodologies really focused on but not necessarily discipline. Because they didn't do the things that they said they had needed to do because of the process. Because if they did those kinds of things, they'd never get anything done.

Mike Mason:

I remember reading the XP book. There's a bit in the XP book where Kent's writing about your manager coming in and screaming at you, because you've been very clear about what you can do by a particular date, and you're threatened and all this kind of business. And you just stand your ground. You're clear on what you can do by what date, and the management have an option to get rid of you and the rest of your team and find somebody else or to actually believe you and to continue onwards. And that had a huge impact on me as a young 20-something engineer when all of this stuff was coming about. But although I'd read the XP book, and I believed how impactful this stuff was going to be, I wasn't able to make much progress on it as an individual. I did a few things, like I didn't know it was called continuous integration, but I had a build server in the corner based off of CVS commit hooks and stuff like that and some amount of automated testing, I guess. 

But it wasn't actually until I got to Thoughtworks and was surrounded by people who were already doing this stuff, that I could actually adopt it. And I certainly feel like that seems like it would have been a common problem in industry adoption, that you need a certain amount of momentum or people who know what they're doing, before you can move the needle on that for a particular organization. Would you find that the main challenge, or was it simply seen as the cowboy development methodology? 

Jim Highsmith:

I think it depended on who you talked to, and it was certainly looked on as cowboy methodology by a certain segment of the population. And I think in those early days, it was very difficult and, to some extent, still is, to move from one or two or three pilot projects more widely into the organization. The success of several different projects didn't necessarily mean organization success. 

Then you had things like, I had a middle-level manager call me one time. He worked for a financial company on the East Coast. He said that they had been doing successful Agile for several years, had the numbers to prove it. He had a boss come in, and he was calling me to see if I could come in and give him some ammunition to talk to his boss, because his boss was a Waterfall person. And he changed the whole organization back to Waterfall. And the guy that I had talked to eventually left, because he didn't want to work in that kind of environment. Those are some of the kinds of things that we were up against at that level. 

And then we were also up against things like, I worked with an educational software company in Phoenix on a project they had. They had an architect that was really into diagrams and into up-front architecture and then wouldn't get to do anything in the back. And so, it was kind of interesting. I said, okay. He wanted to do all these UML diagrams and such. I said, "Do anything you want in terms of the architecture. You got two weeks, and then we're going to sit down. We're going to look at it."

So we sat down. He made a presentation on the architecture, and I turned to the developers on the staff, and I said, "So, now do you know what to do?" They said, we don't have a clue. And luckily, this guy was also a programmer. And I said, "Okay, sit down with the developers and show them what you want them to do." And they got it eventually.

And the other thing that happened was about two or three months later, after the architecture had evolved. The architect came back to me, and he said, "You know." He said, "If we had done this upfront, we would have never ended up with this architecture. But we evolved into this architecture, and it's really much, much better than it would have been in the beginning." So, he was growing into it. But on a personal level, on an organizational level, that's got to take place over some period of time, and some people obviously get stuck.

Martin Fowler:

Yeah, for me, this time has been entirely within the Thoughtworks bubble. Even by the time we'd gone to Snowbird, I'd joined Thoughtworks by then. I'd been an employee for just under a year, I think. So for me, my priority has always been making it safe for Thoughtworks to work the way we want it to, which was in this Agile style. And early clients were very resistant to the name. I certainly remember going to give a talk for a financial company in Australia, and they said, whatever you do, you're not going to talk about the Agile stuff are you? And this was in the mid-2000s, when I was known for doing Agile things. And that was still a lot of it was going on, and we would be in projects where we said, no, we're not doing extreme programming. We're doing this lots of testing and continuing integration and refactoring and design evolution. But no, we're not doing extreme programming, of course. That would be dangerous.

So, the great change that has occurred for me is we can actually say we're doing Agile. We're actually asked to do Agile. Of course, the problem now is that what people think Agile is a good way distant to what we actually know it is. And so the problem has changed, but at least we're able... I think we're in a better position to work the way that we know is effective. And that's really what I'm interested in, is can we work the way we know that is effective with our projects that we're doing.

Jim Highsmith:

Yeah, I think one of the issue with Agile over the years has been, it has followed Gerry Weinberg's Law of Raspberry Jam, which is the thinner you spread it, the shallower it gets. And so I think it's a natural evolution of anything like this, anything in business or scientific community, that sort of is the thing, and it has a lifecycle. And one of the things to me that has been so incredible about Agile is that it hasn't fallen off. It's continued to expand, and yes, sometimes it gets thinner. But it's still is something that most people in the world now, in terms of IT and software development, are at least trying, if not fully involved in it. 

So I think it has stood the test of time, and I really think one of the biggest reasons for that is the values and principles that were in the manifesto. It has been a philosophical core that has really, really helped, and I think one of the things about a lot of methodologies up until then, and I was involved in Waterfall methodologies a lot during the 80s and early 90s, is they didn't have this core philosophy really focused on the people who were doing the work. It was more about how do you manage stuff than it was about how you do software development.

Mike Mason:

I think, for me, what was interesting about the phrasing of the manifesto was we are discovering better ways of working. I think the discovering word was really important, because to me, there is some fundamental truths of how Agile helps you build better software that are something that is almost fundamental to the way humans and teams interact and stuff like that. Like Conway's Law, we keep finding new ways for that to be applicable across organizations. So in some ways, I feel like there's a nugget of something that was discovered almost like we discover mathematical principles or physics principles that was somehow embodied in Agile, which is why it's been so enduring.

Martin Fowler:

Yeah, although interestingly, the word we used was uncover, as opposed to discover, with the feeling that people out there are doing their stuff, but we just need to make it more visible. At least that's how I took it. I'm sure we talked a lot about that opening sentence and putting it in. It's I think an important part of the page, because it brings out the fact that we don't have a fixed answer. We expect things to change. We expect understanding to grow. And although I think the manifesto stands up really well, considering, it's aged well I think over the last 20 years, we didn't intend it to be a statement for all time that would never change.

Alexey Bôas:

Yeah, one thing I find interesting about what you said, Jim, the philosophical core, is that I see many examples of people not looking at that as a technique, solely, but trying to apply that to different contexts. I see clients asking, can we apply those principles to our HR department, or how can we bring that other parts of the organization and spread that in different ways? At least from a way of thinking and a change-of-mindset perspective, the broader organization is trying to look at that and apply that in different ways. I also wonder if that's also part of the answer for its resilience and adoption and-

Jim Highsmith:

Yeah, it think so. I think its resilience and the ability to push into other parts of the organization has really been important, and that has happened over the years. You've got different parts of the organization that have tried to become more Agile, and of course in the last 10 years or so, 15 years, with accelerated pace of technology change, that's been even more important. How do you incorporate those things into a learning thing? And that actually was how I got into it what the precursor to Agile was in the early 1990s. I had been doing Waterfall methodologies for the decade of the 80s. And towards the end, I got to thinking about, you know, that's not really how I personally like to work. I like to personally work in much more interlude fashion. 

And so that was the genesis of a rapid development methodology that I developed in the 1990s, which was kind of the precursor to Agile. Just like Scrum was developed during that period of time, DSDM in Europe, some of Alistair's Crystal stuff, was all kind of germinated in the 1990s, because it was more the way we actually worked. And the other thing was businesses were demanding that we become, at that point, really faster and more focused on business kinds of things. I remember doing a project for a large, apparel company on the West Coast, and this was 1995, something like that. They had a project, a very important project in their apparel division, that they had spent 18 months doing requirements definition. They had this nice document that was completely out of date at the end, and I went out and helped them do project in six months with one month iterations that actually produced something workable and installable at the end of that period of time. But people were so enamored of the Waterfall methods, particularly from a management standpoint, that it was difficult to overcome then.

Mike Mason:

Something I had often thought is that there's been a synergy between Agile and technologies that enable it. I think cloud is one of the big ones, in that on-demand infrastructure has allowed us to do a bunch of things faster and more iteratively than we otherwise would have been able to do. That's not to say you can't do these things with fixed infrastructure, because we all were doing them with traditional, on-prem infrastructure. But I think the cloud has really helped with that. Would you agree with that, and would say there's anything else that has happened over the last 20 years that isn't strictly Agile but that has been complimentary to that.

Jim Highsmith:

Let me just go back for a second to the 1970s, and in that point in time, the input was punched card. So you had to write out your programs on a sheet, hand it to the punch card people, they would punch it up, and you'd go back and desk check it, and you'd put it into the computer. And maybe, maybe the next morning, you would get out a printout. And so in that kind of environment, it would have been very, very difficult to do Agile. So I think the technology has impacted our ability to do Agile quite a bit, particularly in the last-

Martin Fowler:

Yeah, I don't think it's a particular coincidence that so many of the leaders in the Agile movement came from Smalltalk background, because Smalltalk had a lot of characteristics of what working in programming languages in the 90s and since have been. It gave you this very rapid turnaround. It gave you ability to structure a large system, things that were actually really quite tough in the 80s and 90s. When I've compared the C++ development, in those days, with the Smalltalk, really very different. And so I think the fact that a lot of these ideas kind of hatched with an assumption of a more rapid turnaround was no coincidence. 

And then again, you've got this, I think the cloud further helps accelerate things, because we know how difficult setting up infrastructure is and things of that kind. Again, if you can speed that round, then that encourages you to do things that you were able to take advantage of that great speed. So, yeah I definitely think there has been nice synergy with technological improvements, and then the philosophy of Agile helped encourages us to take advantage of them.

Jim Highsmith:

I was just going to say, Tom Friedman, from the New York Times, wrote a book in 2007. And one of the things he said in that book is that was a big year of change, where you had iPhone come out, Hadoop, GitHub, social media. And so there was a tremendous technological change in 2007, when you put all these things together, and I think that's something that kicked the need to be Agile into even higher gear.

Alexey Bôas:

Yeah, on that note, can we take that synergy a step further. So the world is innovating at a much faster pace, and the need for experimentation feedback cycles to change has been increasing a lot. So maybe we can take the analogy a step further. And organizations that have become nimbler and have the need to become nimbler and that Agile enables that and at the same time, that creates the need for things like Agile. So I wonder if the analogy can go a step further to organizations in general and even society.

Jim Highsmith:

I think so. If you look at, for example, McKinsey & Company over the last few years, there's been a lot more articles written with the word Agile in there somewhere, or Agility. So I think that's one indication.

Martin Fowler:

Yeah, certainly we get the ability to do things more quickly, then the advantage of trying something, seeing how well it's working and then either doubling down on it or switching to something else, that broad philosophical strategy works better. Because that all depends on feedback. I remember I gave a talk a few years ago with Neal Ford, where we really talked about the notion that feedback is the fundamental thing, that the more rapidly you can set up your feedback loops, then the more you're able to take advantage of it. And that's really the key that Agile thinking is setting up feedback loops. And so the more things that we have to tighten those feedback loops, the greater leverage we get, the more advantage we get by having the Agile mindset.

Mike Mason:

So, when you're thinking about Agile adoption, is there anything that the industry still doesn't get? It's been 20 years, was there a point that you were trying to make that people still miss regularly?

Jim Highsmith:

I would say one thing they miss is the difference between doing Agile and being Agile. Doing Agile sort of brings up a oxymoron's tag for me. It's prescriptive agility that a lot of people can't get past. It's an oxymoron, right? There should be anything called prescriptive agility. But there really is in a lot of organizations, because they take some things like practices and say, if I can do these practices, then I'm agile, as opposed to adopting the philosophy of Agile. And I think that's something that has slowed a number of implementations down and made them less than what a lot of us would like to see.

Martin Fowler:

Yeah, a couple of years ago, I gave a talk in Australia about the state of Agile software in 2018. And there, I said we have some significant challenges. On the surface, things are looking really good, because Agile is everywhere. But the problem is that what you see everywhere is a faux Agile, as opposed to the real thing, and we find this in our work. We show up at clients, and the clients will say, oh yeah, we've been doing Agile for years. And then our Thoughtworks folks take a look at it and say, hmm that word does not mean what you think it means. And I identified three areas that I felt were the biggest challenges. 

The first was an Agile-industrial complex, where it's often trying to force particular ways of working upon teams. When really to me, the heart of Agile is the team figures out the way it wants to work, a way that suits the problem they're dealing with, a way that suits the interrelationships that they have with the people around them, a way that suits the team themselves and that that way they work should also be something they're in charge of evolving. So that they change it as they go along. And when they're told that they have to produce, fill in Jira tickets or whatever, that's not the same thing at all. And of course, we see that quite a bit where we're seeing clients trying to force an Agile approach onto teams rather than let the teams take ideas from people around them. But the team in the end should still be the primary feel of the way they work.

The second thing I identified was that people didn't recognize the importance of technical excellence, that teams have to get good at software skills like testing, like continuous integration, like refactoring. These are technical skills that people have to be good at. It can't just be a management issue. And this is where the rise of Scrum has probably caused a lot of problems, because Scrum has tended to emphasize managerial elements and not emphasize technical elements. You talk to the leading Scrum people, they recognize the importance of technical elements. But they didn't make them part of Scrum, because they didn't want to mandate them. But the problem is that it's often left to people leaving them out. And of course, you need technical ability to be able to push the technical excellence, and that often doesn't overlap with managerial ability or career progression. So as a result, that has caused problems. 

And we thought about that in Thoughtworks by having a strong technical career track and making sure that people can progress while remaining very much technical. I credit our CTO, Rebecca, hugely for that, because she's really managed to instill a technical career and a technical leadership structure into the organization. She's had good support from that. It helps having Xiao be a CEO, being an ex-developer himself who really respects that, but I think it's people who have developed that. And we've worked well with Rebecca to make that happen over the years, both with North American leadership and then global leadership. That's important within an organization, and other organizations need to follow that.

The third element is having a product-oriented mindset instead of a project one, and that's another one we've been seeing for years upon years, that we think of long-term products, not do a project and get it done. And that's the third element of the mindset that I think is... Those are things I identified back in 2018, and from my sense, it's still very much a similar list now.

Jim Highsmith:

Yeah, I would add a fourth one to that, which is a movement from what's called a velocity-oriented approach to a customer-value oriented approach, so that as you've got a lot of uncertainty, you can't necessarily plan exactly in terms of scope, schedule, and cost. Those are constraints on the process. But the real thing you're shooting for is am I delivering customer value? I used to ask the question, if I could deliver a hundred percent of the value at a hundred percent of the time, what if I could deliver 90 percent of the value in 80 percent of the time? Would I stop the project? And so many people just continue on and on until they get to the end of what they said their feature set is, but they don't ask the question about value. And it can be fairly simple. 

I was doing some work, not actually work, I was visiting a Thoughtworks team. This was like 2012, 13, and something like that, in London. And I talked to them for a while, and I said, "So, what do your customers think about what you do?" And they said, oh, the customer's pretty happy. They like what we do, et cetera, et cetera. I said, "What is their concerns?" And they said, well, their concern is velocity. And I said, "Well, what do you measure and give to them?" And they said, velocity. So I said, "Why don't we do this simple experiment? We take each of the story cards, and we put one to five stars on those story cards that have to do with what's the customer value of that story. And so what we're going to report to them is how many value points we've delivered during a particular iteration, as opposed to how many velocity points we delivered." And that very simple thing changed their mindset about what they were trying to do, and it really resonated with the customer. 

And so value orientation doesn't have to be complex, although in some situations, it probably is we've got to get a little more than that. But I think that's a big change that people have to make. When their uncertainty is high and when the speed is fast, you can't necessarily shoot for a planned ending. You have to evolve towards that by measuring customer value.

One thing I would say, and this applies to a number of organizations, that Agile has moved from being a strategic-differentiated. There was a point in time, when you said, we're doing Agile. Then so, everybody else is not doing Agile, so that's our competitive advantage. And I think today, it's more of a core competency than a strategic differentiator. And to be really good at things like transformations and product orientation and things like that, it is a core competency that we have to have at a very high level. But there's so many people that say they're doing Agile these days, it's not as much of a differentiator as it used to be.

Mike Mason:

I think just coming back to the doing Agile versus being Agile thing, I think one of the things for that's difficult is, we have a conversation at Thoughtworks around the sensible defaults, so the usual things that you will do, unless you have a reason not to. And when you think about Agile adoption, sometimes you have to give somebody rules to live by in order for them to understand what those things do before they can understand the benefit and then become adaptive in the future. And I think a lot of organizations either get stuck at the rule-based mentality and don't give people any chance to do any adaptation, or they jump, actually some practitioners do this, they jump straight to the adaptation bit and say, we're going throw out some of these practices. And they always tend to be the difficult practices rather than the easy ones. And they say, okay, we're being adaptive here, or we're being Agile. And what we actually see is, well, you've discounted this practice without really understanding what benefit that would have gotten you had you been following it.

Jim Highsmith:

Right. I think as a learning process, prescriptive Agility is not a bad idea. You say do this and figure out how it works for you, and then as a result, you become more adaptive Agility later on. So I think that's a real important point, but too many people get stuck at prescriptive Agility. And they're not really being Agile. They're not really adapting as they go forward. And so I think that's a barrier for a number of organizations.

Martin Fowler:

Yeah, it's a tricky trade-off, because I think the heart of Agile thinking is very much the team decides how they want to work. And obviously at the beginning, a lot of teams don't really know what they know or what they don't know. And so they have to try things, some extent, to a leap of faith. Just give it a try. That was a particularly strikes me, going back to the first XP project at Chrysler, where there was a bunch of things I didn't think were going to work. But I thought, hey, well Kent's in charge of this gig, so I'll just go along with him, see how it goes. And we got some bright people here. We'll fix it when it goes wrong. And a lot of the things I was concerned about did not happen, did not go wrong. But you wouldn't have known that had you not tried it. There is an extent to which people need to do that, and of course, it greatly helps if they can have people around who've been around the loop a few more times. And that's the advantage you've got now, when you've got folks who have done these kinds of projects. We've seen it, and we know what it feels like when it's working properly. And that gives you obviously, a great advantage. But you have to have access to those kind of people to be there.

What frustrates me is when a team that does have that kind of knowledge and is operating in the right kind of way, gets pushed out of sync by a corporate Agile standard. Because that kills the more important element.

Mike Mason:

That's actually a really important topic that we didn't touch on yet, which is broadly, doing Agile at scale across an organization. Like Agile adoption, taking an organization where people are not working that way and teaching them a better way of working. And the way I would articulate the problem is that Agile has quite, I wouldn't say easily, but quite often, you can demonstrate success at the 20-, 30-, 50-person team level. Because it is such a better way of working that you can be wildly more productive. And then leadership in an organization see that in that small pocket of the organization, and they suddenly want it everywhere. And the ask becomes, can you please crank the handle on that and churn out this wonderful thing across my whole organization? And I can see the reason that that is what's being asked for, but we all know it's more difficult than that. I feel like that's one of the biggest problems in the industry today, is trying to do Agile at scale across an organization.

Jim Highsmith:

I think what happens is again back to this, at scale, organizations become more prescriptive. And that's a kind of antithesis to Agile, that we need to be less prescriptive at scale, just like we need to be less prescriptive at the development level. And we're not quite there yet in a lot of organizations, a lot of organizations.

Martin Fowler:

Yeah, my reaction is actually I really don't know very much about that. One of the nice things about my life is I'm not an expert on Agile anymore, really, at Thoughtworks. There's tons of Thoughtworkers you can run into who know a hell of a lot more about this than I do. Talk about Agile at scale, we've done all sorts of things with Agile at scale. And Mike, Alexey, you've probably been closer to them and seen more of them than I have. And I kind of like the fact I'm kind of an ignorant person in all of this, and I'm not able to answer these questions. We're kind of being trumpets and trying to change things back at Snowbird, when we were leading the charge, but the fact that other people have taken up the baton and taken it much further than we could have done is to me, one of the big things that has occurred since.

Again going back to that talk I gave a couple of years ago, I made the comment, I was very negative in the talk, because I was talking about all these things that were bad about faux Agile and Agile not living up to its hopes that we'd set up. But I wanted to finish on an optimistic note, and the note I picked was to say, well, really what we have is we've created a community that can go much further. And my example was, you look at a photograph, if we had done a group photograph of the 17 of us at Agile, it would look a bit jarring now. Because you look at that photograph, and what you'd see is a bunch of middle-aged white guys, because that's what we all were. There was no women at that meeting. 

But what's happened since in the Agile community, is a lot of women have stepped up and led the community in all sorts of interesting directions. You think of Mary Poppendieck with the stuff on lean software development. You think of Rebecca and all that she's done at Thoughtworks and being a chair at Agile Alliance for quite a few years. You think of Esther Derby with her stuff on leadership. There's a ton of people who have pushed the Agile community, and it's not the 17 of us who wrote the manifesto. And actually we've done is kind of minor really in the whole sense of things. 

I look at what have I achieved for the Agile world in the last 10 years, and it's not really been that much. I revised a refactoring book. Well, yeah that's useful. It's necessary for part of technical excellence, but it's only a tiny piece of the puzzle. And lot of people have contributed in all sorts of ways, both in the wider community and particularly, within Thoughtworks. If someone once asked me to come in and give them advice on large scale organization change for instance, I'd say I haven't the foggiest, but I know a whole bunch of people at Thoughtworks who do, who've done this kind of thing all over the world, in different cultures. And that's the really exciting thing for me is the fact that there's all of these other people that have leapt forwards and really done great things in these 20 years.

Jim Highsmith:

There are also two aspects to scale, and we actually often times, don't differentiate these two aspects of scale. One aspect of scale is I want to get everybody in my organization trained in Agile, and most of the projects or product teams that I have are five to 15 people. So you've got small- to medium-sized products or projects. The other kind of scale is a large product. For example, a large product today might be the autonomous car. I've seen estimates the autonomous car will have a billion lines of code. That's a very different kind of scale than trying to get everybody in my organization up to speed, with my average-sized product or project that is 10 or 15 people. So those two aspects of scale are different, and for example, in the large-product arena, architecture becomes critical, critical piece of that particular equation.

Alexey Bôas:

If we want to talk about uncertainty, maybe 2020 has shown us one big example of what we call deep crisis. So, how can some of the lessons from Agile help us deal with situation like that, for example?

Martin Fowler:

One thing that I think that's important was how quickly we were able to adjust our ways of working to deal with a fully-remote environment, when we struggled to get any of our clients to provide a greater degree of remote working. We've long been banging around, saying, it would be really good if we could do more remote work. And clients would say, no, we've got to be all in the office. And then suddenly, we have to work remote. I think that the Agile mindset is what's important here. 

There is no white book, extreme programming book, that's the template for here's how you switch from a fully on-site organization to a remote organization in a week. That book did not exist. But if you have an Agile mindset, you figure out what you need to very well do to get there. You know what things are important. You focus on how do I make these changes. And you realize that what you're doing week one is not going to be the best answer. And you can evolve and adapt over the course of time, try new things out, and go through this whole do something, sense, see what the world's like, change, and shift notion. That's what leads you through it. And I think that's what led us through it and allowed us to adapt as quickly as we did.

Again, the philosophy is what counts in being able to react to that kind of uncertainty and the uncertainty we'll have coming out of COVID. Because we don't really what the path out of COVID looks like. It's going to be a hell of a lot nicer than the path going in. We're pretty sure of that. But exactly what happens, what timescales, what kinds of things open up when, what kind of shucks we might have from variants, and all the rest of it, we don't know. And that uncertainty is still going to be present. And again, what's key is that notion of we don't know the answers, but we are confident we can have a way to discover them, by reacting to it in an appropriate] way.

Jim Highsmith:

In biology, there's a term called punctuated equilibrium. And a punctuated equilibrium is when something major happens. And so the meteor strike that led to the demise of the dinosaurs and the rise of mammals is a punctuated equilibrium. And I think COVID is probably similar to that in terms of there's two strategies that will allow survival after a punctuated equilibrium. One is luck. If you are in the Amazon business of ordering online and delivering, your luck is good. If you're in an airline business, you're luck is bad. And there's nothing the airline can do to overcome that, except time and losing a lot of money. And so luck is part of it. 

But for example, why did the mammal succeed where the dinosaurs didn't? It was because they were more adaptable. They could adapt to colder climates, and so that adaptability is why the mammals survived and thrived. And so there's going to be the same kind of thing in big organizations and organizations, actually small ones too, like small restaurants. Part of it is luck, restaurants were unlucky. But they still adapted fairly quickly to certain kinds of things. You got restaurants with bubbles now outside. So even though you're enclosed in this bubble, and the airflow in that bubble is really terrible, you're still outside, right?

And then big organizations, for example the travel industry, cruise ships have been hit really, really hard. So they're just trying to adapt to survive, whereas other companies that were... Like grocery stores, they're adapting to fulfill greatly enhanced needs, greatly enhanced demands. It strikes unevenly across industries, which is different than a lot of the changes we've seen in the past.

Alexey Bôas:

Well, this takes us to the end of the episode. Thank you very much, Tim and Martin, for joining. Thank you very much, Mike, and hope to talk to you next time. Thanks a lot.

Martin Fowler:

Thank you.

Mike Mason:

Thanks, Alexey. Thank you, Jim and Martin.