Jacky Li of InfoQ China spoke with Martin Fowler during ThoughtWorks' AgileChina conference. In this print interview, Martin Fowler talked about Scrum certification and the future of Agile.
InfoQ China (InfoQ): Several weeks ago InfoQ published an an investigation on how Scrum was adopted in China, and I can tell from the answers that many people, who have been trying to implement Scrum inside their own organization, had no idea about the meaning of Agile. They just hopped on the training, became a Certified ScrumMaster and began to adopt Scrum. Of course, the adoption failed. Those things not only happened in China, but also in other countries, a conclusion I drew from reading many emails in the Scrum and XP yahoo groups. I'd like to know: what do you think about this, and how can we improvement this?
Martin Fowler (MF): Well, with any technique, it's not easy to figure out how to take it on. I think Agile is particularly difficult because there are a lot of mindset changes. If you were in Richard Durnall's talk, you would hear him talking about the same experience in Lean Manufacturing, that a lot of people particularly focused on the practices, over the end-line philosophy. When you just try to do the practices, and don't adopt the philosophy, it's not going to work terribly well.
I personally think it's going to take several decades for Agile to have its impact. And I draw the comparison with objects: we have object-oriented technology, it first appeared in the late 60's to 70's. It took 20 years, into the 90's, before it became main stream programming languages like Java, C++ and C#. But even so, when we go to our clients today and look at their code, it's not object-oriented. It's written in Java, but it's not object-oriented! So it's still a further step to get to the point that most people actually write in an object-oriented fashion.
So, here we're talking ... what? 40 years for objects? and objects are much more limited in scope than Agile. Because objects is just about programming, and programming design. Agile is an entire process that you develop software in. So it's going to take longer for Agile than for objects.
The Certified Scrum training course is just basically two days' training, only so much you can learn in a two days' course! But, I don't like the fact that they've called it "certified", because I think it gives the wrong impression. But it does have one good advance. And that is, you do spend two days with someone who actually does understand Scrum. I mean the actual teachers of the Certified Scrum stuff, as far as I'm aware, are people who really know that stuff. And that's a PLUS. Because you see a lot of technologies where the teachers don't understand. And that's very common. I mean that was very ... umm... one of the big problems with the Rational Unified Process, and with the CMM. You have the problem that instructors didn't know what they were doing. But at least Certified Scrum Master course, instructors, as far as I know, they actually all know the stuff. But the problem is, you can't teach or put everything in two days! I think it takes several months to learn how to do Agile. You have to be on a team, you have to work in an Agile style, you have to begin to see how all the elements fit together. That is a multi-month exercise.
InfoQ: There're still many misunderstandings about Agile, such as "Agile means no documentation", "Agile means doing things quickly" or "If you want to do Agile, you must implement all the practices", etc. So what steps can we take to eliminate those misunderstanding?
MF: There's no easy step, I mean there's a lot; you have to keep explaining, showing examples. There're many people particularly active in the Agile world, they go out, they talk about it, they try to explain how things work. I'd like to say that ThoughtWorks is interested in making great examples, because we do these project, we work in this style, when a new person joins us, he see the operation, he doesn't have to imagine how it looks like, he experiences the whole thing. I think it's a good plus.
But I am also very patient, as I said, "several decades"! But I'm used to this because I've seen objects, we aren't finished with objects yet, so...it's one of the long-term exercises.
InfoQ: Do you think there can be a kind of standard in the Agile area?
MF: I don't think you can make a standard of it. The way that we've intended to use it is to help organizations understand what areas they are strong on and what areas they are not strong on, and for which things they need to improve. In fact, that's the original notion of CMM, it was an assessment exercise to help you learn how to improve. It's gotten TWISTED in the certification mechanism.
And, unforturnately, that is definitely a risk that could happen to Agile, and many people feel that, with the ScrumMaster thing ... We'll see. I mean all we can do is to struggle to try and keep on demonstrating what's going on.
InfoQ: 7 years have passed, ever since the Agile Manifesto was produced: do you think we can summarize the experiences from the past years into patterns, so that we can use them to guide our practices?
MF: Possibly! There're certainly lots of people who work on that kind of area. But I'd like to say it's not something that I intended to focus on. I was very near in early days of Agile, but I decided quite a few years ago now: there're lot of people who are talking about agile, advertising agile, and dedicated to it a lot. So I've tended to keep away from it - NOT because I don't think it's important, because I think it's extremely important, but lots of people are already doing that. I prefer a world where there's no competition. I'm on my own, it's easier that way. That's why I concentrated on things like enterprise architecture patterns and DSLs.
InfoQ: So you're just waiting to see how are things are going?
MF: Yeah, well, there are lots of good people in the Agile movement, both inside ThoughtWorks and outside, so... I am not going to help that much, it's better, to me, I think, to concentrate in the area where other people won't concentrate.
InfoQ: People ask the question, "How can we decide a project is Agile or not?" And I thin that it's an invalid question, we only need to know how to make improvements ...
MF: Yes!
InfoQ: ... not to check if it's agile or not.
MF: Absolutely.
InfoQ China (InfoQ): Several weeks ago InfoQ published an an investigation on how Scrum was adopted in China, and I can tell from the answers that many people, who have been trying to implement Scrum inside their own organization, had no idea about the meaning of Agile. They just hopped on the training, became a Certified ScrumMaster and began to adopt Scrum. Of course, the adoption failed. Those things not only happened in China, but also in other countries, a conclusion I drew from reading many emails in the Scrum and XP yahoo groups. I'd like to know: what do you think about this, and how can we improvement this?
Martin Fowler (MF): Well, with any technique, it's not easy to figure out how to take it on. I think Agile is particularly difficult because there are a lot of mindset changes. If you were in Richard Durnall's talk, you would hear him talking about the same experience in Lean Manufacturing, that a lot of people particularly focused on the practices, over the end-line philosophy. When you just try to do the practices, and don't adopt the philosophy, it's not going to work terribly well.
I personally think it's going to take several decades for Agile to have its impact. And I draw the comparison with objects: we have object-oriented technology, it first appeared in the late 60's to 70's. It took 20 years, into the 90's, before it became main stream programming languages like Java, C++ and C#. But even so, when we go to our clients today and look at their code, it's not object-oriented. It's written in Java, but it's not object-oriented! So it's still a further step to get to the point that most people actually write in an object-oriented fashion.
So, here we're talking ... what? 40 years for objects? and objects are much more limited in scope than Agile. Because objects is just about programming, and programming design. Agile is an entire process that you develop software in. So it's going to take longer for Agile than for objects.
The Certified Scrum training course is just basically two days' training, only so much you can learn in a two days' course! But, I don't like the fact that they've called it "certified", because I think it gives the wrong impression. But it does have one good advance. And that is, you do spend two days with someone who actually does understand Scrum. I mean the actual teachers of the Certified Scrum stuff, as far as I'm aware, are people who really know that stuff. And that's a PLUS. Because you see a lot of technologies where the teachers don't understand. And that's very common. I mean that was very ... umm... one of the big problems with the Rational Unified Process, and with the CMM. You have the problem that instructors didn't know what they were doing. But at least Certified Scrum Master course, instructors, as far as I know, they actually all know the stuff. But the problem is, you can't teach or put everything in two days! I think it takes several months to learn how to do Agile. You have to be on a team, you have to work in an Agile style, you have to begin to see how all the elements fit together. That is a multi-month exercise.
InfoQ: There're still many misunderstandings about Agile, such as "Agile means no documentation", "Agile means doing things quickly" or "If you want to do Agile, you must implement all the practices", etc. So what steps can we take to eliminate those misunderstanding?
MF: There's no easy step, I mean there's a lot; you have to keep explaining, showing examples. There're many people particularly active in the Agile world, they go out, they talk about it, they try to explain how things work. I'd like to say that ThoughtWorks is interested in making great examples, because we do these project, we work in this style, when a new person joins us, he see the operation, he doesn't have to imagine how it looks like, he experiences the whole thing. I think it's a good plus.
But I am also very patient, as I said, "several decades"! But I'm used to this because I've seen objects, we aren't finished with objects yet, so...it's one of the long-term exercises.
InfoQ: Do you think there can be a kind of standard in the Agile area?
MF: I don't think you can make a standard of it. The way that we've intended to use it is to help organizations understand what areas they are strong on and what areas they are not strong on, and for which things they need to improve. In fact, that's the original notion of CMM, it was an assessment exercise to help you learn how to improve. It's gotten TWISTED in the certification mechanism.
And, unforturnately, that is definitely a risk that could happen to Agile, and many people feel that, with the ScrumMaster thing ... We'll see. I mean all we can do is to struggle to try and keep on demonstrating what's going on.
InfoQ: 7 years have passed, ever since the Agile Manifesto was produced: do you think we can summarize the experiences from the past years into patterns, so that we can use them to guide our practices?
MF: Possibly! There're certainly lots of people who work on that kind of area. But I'd like to say it's not something that I intended to focus on. I was very near in early days of Agile, but I decided quite a few years ago now: there're lot of people who are talking about agile, advertising agile, and dedicated to it a lot. So I've tended to keep away from it - NOT because I don't think it's important, because I think it's extremely important, but lots of people are already doing that. I prefer a world where there's no competition. I'm on my own, it's easier that way. That's why I concentrated on things like enterprise architecture patterns and DSLs.
InfoQ: So you're just waiting to see how are things are going?
MF: Yeah, well, there are lots of good people in the Agile movement, both inside ThoughtWorks and outside, so... I am not going to help that much, it's better, to me, I think, to concentrate in the area where other people won't concentrate.
InfoQ: People ask the question, "How can we decide a project is Agile or not?" And I thin that it's an invalid question, we only need to know how to make improvements ...
MF: Yes!
InfoQ: ... not to check if it's agile or not.
MF: Absolutely.