Well, I didn’t know it was going to be a quiz. I've been in software development for just under a half of century now. Starting out doing some very interesting work for the government that I can't talk to you about in much detail, but we saved billions of lives. I was fortunate in that job to get the opportunity to study all kinds of technology - that was the real purpose of the organization. That just started me off on a really good footing; I didn't have to go through the "I will be a C programmer for the next 10,000 years." So I've done a lot of work with operating systems, relational databases and so on. And by the time Agile started coming along in '96, I was just about burnt out on doing software because it seemed like it didn't work, that there were things wrong.
I knew it could be better, that I could do some things better, but I couldn't seem to make it all come together. Then I was lucky enough to be on Kent Beck's C3 Project (The Chrysler Payroll Project). I was kind of the on-site coach because he was flying in and out, as he does. We kind of evolved extreme programming at that point, we really did the full iterative thing, we had the team doing all the work. It wasn't the Kent Beck - Ron Jeffries project, it was a team project. So that kind of got the ball rolling and I started writing on the C2 wiki at that time and made myself pretty unpopular with the people who thought that was a patterns wiki, as a matter of fact. But that got a lot of the word out about extreme programming and what was going on in the early time.
To me it just seems like this stuff works at a level (and we'll probably talk about that) and so I've stuck with it, because to me it is a way of putting the joy into programming, the software development, that I found in my career. And I see a lot of people around too, who look like they could use a little more joy.
2. What are you interested in these days?
As you probably know, I've been doing CSM training and we're starting to do this Agile developer skills thing that leads to the CSD. So, for the last year and a half - two years I've been doing a lot of training. I wanted to get back to doing some software development, not necessarily for somebody, but just to get my hands on the keyboard of programming again. I've been writing some stuff with Scala to just kind of get some of those programming chops back because that's really to me where the fun is. The other thing I'm trying to do is to write. And I've been allegedly working on a very short book now for a few years and it's beginning to make me think that the problem isn't my schedule, that there is something else wrong that I'm not getting that done. I really want to get back to that.
I think that this was right at the center of a very interesting topic. I'm fairly famous as a Certified Scrum Trainer for saying that the Certified Scrum Master certificate is almost meaningless. It means you attended two days of training. If you were paying attention, maybe your eyes opened to an idea. How many ideas can you get in two days that you'll actually carry forward? I think that, if you only look around at all these Agile projects, for various reasons, many of them are not succeeding very well. I think everybody gets some benefit. If you try it on, you'll be lifted up a little bit and you'll get 20-30% and think "Hey, this is cool!" But where is the twice, where is the five times? This can happen.
If we see a team that goes from five to five times or ten times their performances (Jeff Sutherland often does) I think we're seeing teams that were originally basically at zero performance, that couldn't accomplish anything. A team that actually produces software and ships it every now and again, will get a benefit, but I don't think they'll get five times faster. I think they'd have to be five times smarter, but that's unlikely. I've been pretty leery of the certification notion and at the same time pushing to say "Look, one of the primary reasons that Scrum teams sometimes don't succeed very well is that they don't have good technical practices inside doing the work." If you are going to release software every few weeks, it has to work every few weeks, which means it has to be tested every few weeks, which means, if you did manual testing, you'd fill the parking lot with testers.
So you must have automated testing. It's not like we recommend automated testing it's like the law of nature is: if you are going to do this, you are going to have to automate your testing. So the practices of automated testing are out there and understood. Extreme programming and other sources know how to do that. Similarly with refactoring - if you are going to build software every couple of weeks, you are going to have to start with simple design, because you can't do very much design in two weeks. So your design must evolve and refactoring comes into play. These are a family of skills which are identified with extreme programming type of practices, but we have been drawn into XP from all over that are really necessary to developers in order to do a good job of Scrum or whatever kind of Agile they're doing.
We're talking within the Scrum Alliance for well over a year saying "We got to get these practices understood." Everyone agrees we have to lift up the standard of performance for Scrum. If you are going to be a Scrum Alliance person you recognize the CSM stand doesn't mean much. They have the Certified Scrum Practitioner, which is much more of a "You've really done this" kind of a role. The idea of the Certified Scrum Developer was if you could do these things, you will know how to actually do the software. It's a three day course, which means in three days I can introduce you to these things, I can let you experience what it is to refactor, I can let you experience what it is to write tests and you have to have 10,000 hours of practice before you'll be good at it.
Again, it's an eye-opening effort more than anything else. It seems to be very popular. It's certainly very popular on the selling side - there must be 15 million SA reps, as the Scrum Alliance calls them, who can now teach this course. I mean there are innumerable people on this list already who want to do it. As far as I know, there have been only a couple or three courses taught, but everyone thinks that there is a need for this and I think there is a need for it. What troubles me is that this too will be a relatively weak certification. It will say "You take this course and you have to pass a written test." The written test is actually written by the course producer but it has to be approved by the Scrum Alliance. So I write the test for my course, you write the test for your course. The Scrum Alliance says "Good test" and the people often pass it.
I don't believe you can test whether somebody can program, in a team incrementally over time, in a written test. The only way for you to begin to get anything of that would be to see the programs and see what the programs look like - "Refactor this horrible code and make it pretty." I think this is still a very small first step in the direction of "Let's raise up people's abilities." If we look at what seems to be coming out with Alistair and the other guys I see in Agile, they have a much more comprehensive spectrum of material and courses. It's very much like the one that we have on the Agile skills project, which is this volunteer effort that I've been a little bit part of and that I think you've probably had a time or two on your side.
We would basically say "What are the dimensions to all of this?" One of them is programming, another one is planning, another one is working with people. There are others of the seven pillars of the Agile skills project; one of them is about technology and six of them are about other things you have to do to do Agile. I think that would give us a curriculum, a study plan that says "Here are things that you ought to know if you are going to be really good at your job, these are things that you want to know well." I'm concerned about the fact that in both cases, in the Scrum Alliance, pretty much and in Alistair's thing to a much bigger degree that keys to whether you can teach this material are in the hands of the people who seem to own the material.
Alistair's material would be open source, if you will, it will be available for anybody to look at, as is the stuff in the Agile Skills project. We see them as a map of the big country of where we'd have to be and I think as a map, if you imagine "Here is this continent of Agile and this little place right here is the Certified Scrum Master and this little place over here is Certified Agile Developer, and this is all still unknown territory that you have to conquer if you are going to own this continent." But the keys to who can teach this material are embedded in those organizations.
And they are unfortunately financial keys, which to me, the way I like to put it in that gentle way that I have is, that is inherently corrupt. You cannot but turn out to be a corrupting influence. These are great people, on both sides; they are wonderful people. They are almost as wonderful as I am. I find that my Certified Scrum Master course sells probably twice as well as it would have if it didn't offer that silly 2-day certification. I feel the pressure of that. I'd like to say "I'm not going to do the certified Scrum Master training any more. I'll give you my same course; it's a three day course, it's better than 2 days by at least 50 percent, its a fantastic course." And I know it would not sell as well and I can feel the gravity that says it would be foolish to not offer that sort of certification - it's harmless, surely.
I'm concerned about the corrupting influence of having the money and the education tied together that way. We'll see how it works out. I had the experience of (you have to type it in exactly right), but I went on Google and I said translate "The market wants certification", from marketing to English." And Google said "People will pay for certification" and that's true - they will! If that means that it's easier to get your boss to send you to a course if you get certified. It really is. And the training is better than nothing. But we look at Java certifications and we know that you can come out of a Java certification and barely know how to write a line of code. With any of these few days' courses, that's the deal!
5. Is it really the 10,000 hours that you are talking about?
Yes, I'm talking about 10,000 hours. I'm as good as I am, and I'm pretty good, because I have lived and breathed software for a half century. You maybe don't have to ruin your life as much as I ruined mine to be good at it. But you've really got to get into it. But where I'm coming from on this thing is, I love this work. I love doing it, it feels good to do it well in the same way I'm sure that it feels good to be a really great carpenter or feels really good to be able to run down the court and dunk the ball. It feels really good to do this well and I'd like people to have that experience if they want it. I'd like people to be able to get that sensation of "Hey, this is really fun, now!" What's interesting is that working in the Agile style with all those practices, I go faster than I did the old way.
It doesn't feel faster because it feels very relaxed. It feels slow motion. It feels like "You just do this and you do that and the program works". Whereas you used to get all that adrenaline because you’d say, "This might work", then you get all nervous, then you run it and it explodes and you spend hours debugging it. "At last, I've debugged it". Then you get these champion feelings whereas the other way, it's just smooth. I watched an Aikido master give a demonstration and he had the whole class out there giving demonstrations and the deal with Aikido is you don't attack, you just defend. They all do the things and they roll around on the ground, they do all that stuff. His part of the demo is he stands there like this and seven people jump on him and he just goes like this, [moving his hands], and they all fall down.
It looks fake, it's so easy. In a way that's what it's like when you do Agile when you do software development really well. When you watch Ward Cunningham writing software you are like "This is fake! He must have that memorized. It can't be that easy!" but it is. And that's what I would like for people to get.
7. Your face changed, your eyes lit up of just talking about it.
That's why I'm behind the curriculum side of the certification thing and why I'm tolerating my fear that the economics will corrupt those organizations over time. Because the material is good, the road map is good and it's just so much fun when you get to do it.
In a way, I'm disappointed with Agile because it has so much potential and because it has not attained what it could. I try to recognize that any enterprise involving skill, you have a lot of people at the bottom and as you go up in quality you get fewer and fewer. An order of magnitude I don't know, but you get fewer and fewer. But between the efforts of the general Agile movement and particularly Scrum, (and I don't mean either of these in a negative way). They have brought in a huge pool of beginners who are beneath even what we call the Shu level in the Shu-Ha-Ri, kind of thing. Those people do float up a little bit, then they get better, but for various reasons they don't actually do the things that you have to do to really begin to internalize how the stuff works.
9. "We tried baseball and it didn't work."
"We tried baseball and it didn't work". I believe that in order to understand what some art is like, you have to actually do it the way it's "supposed to be done" according to some master. Not necessarily me, not necessarily you, but somebody has a theory of how you do this and you should do it his way, until you can do it, until you understand how it really works. What we see instead is organizations on their own and frankly organizations who bring in particularly big transition type experts who will say "That doesn't fit in your context, just don't do it." I'm sorry, but a lot of the stuff we do in programming is the only way that we know to do this stuff and it had better fit in your context.
If you have your QA separate from your development, there will be long delay between development thinking they're done and QA saying they're done. That feedback loop is held open by the fact that you split up QA and development. We used to think that was a good idea - independence, all that. It doesn't work! I'm sorry. You have to do your testing and your development together. If you don't, you simply can't rise up there.
The Agile Alliance, all the people who are out there touting it have brought in this giant pool of people who are getting some benefit and having a wonderful conference and all that stuff. But I feel like the tower of quality is sort of narrow and in part I think it's narrow because when we bring people in we say "This is going to save your life. Agile is going to save you, Scrum is going to save you. You can do this; just inspect and adapt, everything will be fine." Chet Hendrickson will say, and we will say in the talk on Friday - "If inspect and adapt really worked penguins could write software" and we know they can't. There has to be more and I think that the industry side of things needs to be raining down on all of these people and saying "Look, there is stuff out there beyond the three roles and the four meetings and the principle and all that."
There is stuff out there that you really are going to need to know about. You really need to look at Lean, you really need to see what's in it and you should know it well enough to be able to pull something off the Lean rack when it applies to your organization. And it will because in your organization, your value stream is certainly screwed up and you really ought to look at that. Because what's really happening with your company is they take six or eight months planning and then you code something for six or eight months and then you take six or eight months releasing it.
If you got rid of those six or eight months [planning and releasing], it wouldn't matter how slow you were developing it you’d be it three times faster. Look at your value stream, it comes from Lean – you got to know that, read the books, see Mary, talk to Allen, do these things. Similarly, there are all these ideas about programming that come from extreme programming and elsewhere. Learn this stuff - your programmers have to know this. I would like to see, when people are brought in, that they are not just told "This will save you, Agile will save you. These five letters will save you", but that they are told "These five letters will get you started, and here is the stack of all the things that you had better know about. You are not done with this until really begin to know about these things."
I understand the enthusiasm that goes into this stuff when you are new and when you are selling it, because I have been, and probably still am, an extreme programming fanatic and I'm sure I've said "You just do this and it will work." I actually still believe if you just do it, it will work because if you do it, you will learn why it works, if you do it mindfully. If you do it stupidly, of course you won't learn anything. If you do something mindfully, you will learn how it works. But if we're going to say "Just do these few things" or "Just do the little meeting, you have a meeting every day", you got to say there is more out there that you have to bring in and make it part of your own or else you're not going to get it.
Part of my message is "Come on, Scrum Alliance, you have to embrace Lean, you have to embrace extreme programming." You have to recognize these are ideas that are the only ideas that are going to help your people actually come up the chain. You don't even give them just lip service. I don't say "Bring them into the Scrum." I think Scrum is beautifully elegant because it's just this tiny loop. But you have to say inside this tiny loop here is this fruit you have to put in here. That's not happened yet. It's harder, but I think also that the whole recession thing that happened right about the time of this has caused a lot of competition within the Agile community.
I've got sell my deal, you've got to sell your deal, Alistair's got to sell his deal and what seemed like we were all going to come together when we wrote the manifesto and have this movement where we're all going to sweep the world of new stuff, turned into a competition. Everybody's got to identify their own brand and be different from everybody else when the truth is doing something well is a synthesis of all the ideas that are out there, it's not just taking a little thin slice. I want to see the community get beyond that and begin saying "We have to synthesize all these ideas, we have to recognize Kanban is probably a good idea in some cases. How do we use it? It’s not Kanban versus Scrum, it’s how do we combine these ideas and make something that's better than either one?"
That's going to be hard. The Scrum Alliance doesn't want to lose its identity, Scrum.org doesn't want to lose its identity, etc. but I think it's part of what we need - just to bring all that together.
I don't know for sure whether it's hopeless or not, I didn't hear Dave Thomas's talk, but I believe he said yesterday that it is hopeless, that large enterprises will not make the transition to Agile. And I believe he believes that most programmers are not capable of doing the things you have to do to do Agile and I sort of believe both of those things. My experience with large organizations is they certainly don't turn around on a dime, so their transition to Agile, if they make one, is going to be incredibly slow by the lifetime of the human standards. I saw a thing on a list just today where somebody said well, (Mike Cohn in fact), "I'm visiting this client and they are trying to make an Agile transition and the VP of technology has done it twice and their CEO basically doesn't get it - he's 40 years old and he doesn't get it. Cohn says he's old!"
I think that for the enterprise, there’s arguments that could be made that they’ll never get there that they will not recruit the kind of people they need to, that they will not train them at what they need to. So, in some sense, I think those people do need another answer. We have a friend who I'm not allowed to name on this tape who works for a large enterprise who are outsourcing all of their work to India. They are outsourcing it in such a way that the turnover of the programmers is over 30% per year. They are bringing in very beginner programmers and as soon as these guys get enough for resume that they can get another job they go somewhere else. He's got 30% annual turnover, which if my internal calculator is correct, means everybody's gone in 3 years and he's got to do something, he's got to figure out a way to be successful.
He's asking "What has Agile got for me?" My answer is "Agile doesn't have anything for you." But one of his ideas is that he has this framework that can be used and will help these people write software very quickly and will tend to keep it in a consistent way, which grows the framework idea since the beginning of time. It may be your only hope if you are going to have only 30% turnover. I don't believe Agile has to answer the question "What do you do with 30% turnover?" rather than say "Bless you, but we can't help you because we want you to have all your programmers in a room in the same country doing these things and these people can't do it." In some sense it may well be that the periphery of enterprises is doomed for a long, long time to not be in this space.
I’m kind of interested, as are a lot of other people here at the conference - Jim Shore, Bob Martin, Arlo Belshee. I'm interested in the people who want to do well, so my personal taste is if a team wants to really improve as well as really work to improve, I'll visit them. I want to work with those guys. In that sense, we're drawing out of this larger pool candidates who want to do the hard stuff and want to do the stuff well. Maybe the rest of the world has to do things by using tools. Maybe most companies shouldn't be writing software, they should be buying software. That would mean that the software had to be better to buy because it's hard to buy stuff. I remember when Chrysler wanted to buy payroll instead of use ours. They went to PeopleSoft who are the best at payroll and PeopleSoft payroll can’t do Chrysler's payroll.
There are too many weird things in a real big corporation's payroll, like the 15 guys that have different union dues from all the other guys because of some deal that was made back in 1945 and then PeopleSoft says "huh, we cannot do this". We would need better enterprise level tools, we need to understand a lot of stuff we don't do, which means we need very skilled people to do that stuff and we need organizations, companies that are focused on that. If somebody today said "I would like to solve payroll" and put a crack Agile team together to do that, you'd get something that would compete with the likes of a PeopleSoft in a very effective way because we understand things that were not understood back when they started.
There may be this separation when we look at what Scott Ambler is doing at IBM and be as Agile as you want to be. Regarding being as Agile as you want to be, the better idea would be to be as effective as you want to be. If I were IBM, if I were Microsoft, I would want to be very effective. Even if I had tens of thousands of people, I would still want to be very effective and maybe they're not in ways that some of these ideas can help. Those are organizations that are focused on this sort of work. You are General Motors or Ford or Saab, maybe you shouldn't be doing so much programming at all, maybe you shouldn't be doing so much IT. Maybe those are things that you should begin to acquire.
The products we're talking about would be things custom built for them, but by experts, not by inexperienced offshore teams; it might be better. It was an interesting thought. If I'm your inexperienced offshore team, you give me this framework and make me build my products on it, I know that my product owner will immediately come to me and say "That's really cool. I want this" and I'll put that in and maybe the framework will handle it but two or three requests down the line - eventually the framework cannot do it. If that framework is a solid sphere beyond which I cannot go, I'm doomed. I have to go back to the framework guys and say "Give me this feature" and they won't because they have 20 million people requesting features and maybe they don't know how anyway.
What one likes in a framework world is a system like Smalltalk where you can have your framework, but you can always reach right through it and change the way anything works if you have to. But you need people who know how to do that. The premise with the inexperienced offshore team is that you don't have these people on the teams, I'm worried that if we encapsulate people inside of their little tool we have actually made important things worse.
As one example, last night Dave and I were talking about HyperCard as an example of a tool that everyone can use. I said, but HyperCard runs out of gas. And he says "Yes", but they'll be doing it themselves and they will look at it and they will say "I can't make it do this" and they will stop! When we have a programming team, we don't feel the pain and stop. Instead, we pound on the programmers who have got that same problem in their legacy code and say "Put the feature in anyway." When it's your own choice to put the feature in or not and it's hard to do, you look at it and you say "I'm not going to do this. It's not worth it". We probably get better decisions that way.
Whereas if I ask you to put the feature in and you said "It's not worth it", I go "No, you're lazy. You're just a lazy slug. Get in there and work overtime." That changes the whole equation and that's an interesting idea. Maybe for these people, giving them frameworks and tools might change the shape of things but I'm more concerned that no, that what it really is, no, we really need this feature and now our HyperCard, the framework won't do it and then it just starts all over again. We have a bunch of incompetents generating legacy code. From both angles, I want to work on the side of helping people get more competent and there are some areas where I can do that and I'm pretty good at it. So, to me that's where the fun is: sitting down with teams that do that.
11. You want to work with the people who really want to learn, the people up here.
Yes. An interesting example of that is that next week, Chet [Hendrickson] and I are going to the University of Nebraska-Lincoln. They have a school they call the Reichs School, which is a residential college for people who get a degree in software development or business or both. In the junior and the senior years students of this school actually take in real-live applications from real-live companies. Microsoft is a customer there, they have entrepreneurs from around the area as customers and they build a real-live application over the course of a school year to their specification. These guys have been doing Agile for a few years now and we go in, we teach them CSM courses, and we’re teaching them an Agile skills course next weekend and there you have a room full of people who are basically enthusiastic because they are students and they are good at learning.
It's a little difficult to give them what they wanted - we’re trying to help with their curriculum. If you think of what happens is how do you get your 10,000 hours when you've only got one contact hour a week or three contact hours a week? So it's a long time, nine months, to get stuff into these guys' heads. I'd rather have two straight weeks.
12. At least that is contiguous, they are not forgetting.
They are not forgetting, they can get the spirit of it, they can get the feeling of it. You're in here for a contact hour in the morning and then you go off to business graphics class or you go off to whatever you are doing and you do all your other homework and so you don't have that concentration and focus. That is what really makes for skill. If you are going to be good at something, you have to spend many hours a day at it. But the school’s kind of neat because we get many hours with these kids and that is just delightful. They certainly have plenty of preconceptions (we usually reach the age of 20 with plenty of preconceptions), but they are also open and vibrant and they haven't lost it by being burnt out yet. So they will say "That's impossible" and then we're like, "Watch this: that's not impossible." "Cool!"
13. So they are a lot of fun to work with.
They are a lot of fun to work with and we make a fortune. They pay 200 dollars a day for the two of us.
14. Without travel?
No, they cover the travel. So we're really in a good shape. The 200 dollars will just pay for the food. But it is fun and to me that's where the joy is: just hanging with the people that want to do something and the other people who want to help people do things. Other people like other stuff; I'm glad that Scott and other people are trying to transition giant organizations. I think that can only help. I'm glad I don't have to do it.