Agile Fashion

Aaron: How did winning the award help your efforts with Agile?

Kenji: Being honest, actually nobody in Japan knows that award. Some Japanese colleagues really congratulated me about winning and that made me cry. But, no other business effect.

Aaron: Why was it emotional for you?

Kenji: I have been long trying to introduce Agile to Japan, to change engineers’ lives for the better. That effort was acknowledged outside Japan. My colleagues and friends also helped me with the effort together.

Aaron: So winning the award was a collaborative effort?

Kenji: Yes. Along the way of introducing Agile to Japan, they came and formed a good community. Do you know that my speech of Gordon Pask Award is on YouTube? The last part I spoke in Japanese was acknowledgment to the community.

Aaron: Excellent! What would you say is the best way the lives of engineers changed with Agile? Is it the community? Something else?

Kenji: To me engineers themselves changed after Agile. They now know they can change, in other words. They know now that they no longer have to be just sheep. Agile is an anti-bureaucrat, anti-formalism, anti-establishment… I don’t know the right word. Something that says “no!” to the old way of thinking, and that often makes conflicts in organizations the engineer belongs to. I was lucky to have had a good boss.

Aaron: That always helps, to have the support. In your speech, you say it almost got you fired. Why was that?

Kenji: Many of us (Japanese engineers in the community) experienced conflict. So what I wanted to say was in the speech, as to “get fired”, was that we have experienced a long and unhappy, not-well-treated era up to that day.

Aaron: Different direction. How have you been applying mind mapping lately?

Kenji: 1) When I explore new features in the product. I do this a lot before writing user stories. 2) When we have a meeting to get a whole picture of the agenda together via projector, and 3) when I organize an article what to say in it.

Aaron: What else are you working on these days?

Kenji: Giving talks on how to make a good “informative workspace”, how to be a good facilitator. I have been giving that talk (“Project Facilitation: tools that improve productivity and motivation of collaborative work at Gemba” is the title) for 5 years, over 100 times!

Aaron: I bet you hardly need notes!

Kenji: I can automatically talk. I’ve been invited to give that talk to PM, QA, management, leadership and other communities, too.

Aaron: What do you like best about that talk?

Kenji: It includes a lot of pictures and it says “you can change” and you can help others. I think it has been invited to a lot of conferences because I hid Agile behind the talk.

Aaron: How do you mean that? I would guess that it means you introduce ideas about Agile in the talk? But don’t mention it ‘out loud’ or advertise it before the talk?

Kenji: The ideas are from Agile, TPS, and Facilitation. Mostly Agile. I don’t say Agile out loud on purpose.

Aaron: What kind of ideas come from Agile that help facilitation? Is it about letting people know they have the power to change their own situation?

Kenji: Agile is anti-establishment, so not many managers like it at the first look.

Aaron: So you cannot say the word or they will not let you talk (or not listen), right?

Kenji: Yes. Visualization using the wall, including Kanban, task board, burndown-charts with synchronization technique (stand-up) and self-process improvement (retrospectives) and a lot more.

Aaron: Since we all have to work with our managers, how do you include them in feeling comfortable with these ideas?

Kenji: I show them an example of a team in two separate places communicating with Kanban (or task board), but not much. Japanese managers, actually like Deming, PDCA, and Quality things a lot. So, when I say “Agile is PDCA”, they suddenly understand and start to like it. There still is a culture of QC circle.

Aaron: PDCA seems a lot like inspect and adapt, doesn’t it? Perhaps more formal?

Kenji: Yes that’s it.

Aaron: Does the QC circle help with continuous improvement and change for good?

Kenji: Yes, but old QC circles are getting “just-do-it”. or what to say, formal non practical and younger engineers don’t like them.

Aaron: Too rigid?

Kenji: No, ineffective. Empty. They do it because they are told to do so. No soul or motivation in them. A “let’s get this over with” kind of event. So QC circles remains its “shape” but not working effectively these days. And managers who saw my slides (not knowing it is about Agile) recognize it as a new articulation of self-improving process. And managers and engineers start to talk. They haven’t talked with each other… talk about not Agile, but improving Gemba. And that is fine for me. It doesn’t matter how it is called… Agile, TPS, or QC. What matters is the fact that they started talking to one another and changing their way to improve their engineering life.

Aaron: Why do you think that is? I mean, that something as simple as the “information workspace” helps this?

Kenji: Not only that, I should add retro, standup meeting. I talk about how you can do the job together and how you can improve the job at the same time.

Aaron: I see… Are you still using niko-niko? I find the concept fascinating and wonder how the information may be used.

Kenji: Yes. It is used to exchange conversation. I’m not sure you can understand. Japanese engineers don’t talk so much. I mean, culturally, they don’t talk about themselves a lot.

Aaron: So it is like indirect conversation about how they feel?

Kenji: Yes, indirect conversation, AND it is a good trigger to start talking. Culture of shame. As Ruth Benedict called it in “The Chrysanthemum and the Sword”.

Aaron: So they are embarrassed, or find it … rude?

Kenji: Yes, embarrassed. Or uncomfortable to start talking loudly about themselves.

Aaron: So it is a nice tool to help them overcome that shyness…

Kenji: Yes that is one and the other is, for the manager to notice like “everyone seems like they’re happy but there is one who is unhappy for the whole week. I should talk with him in person”.

Aaron: An invitation to a conversation, almost like a story card!

Kenji: Yes. you can say that.

Aaron: We’re about out of time, is there anything else you would like to mention?

Kenji: I’d like to say that the Gordon Pask Award helped us (Japanese community) start a phase II Agile movement in Japan. As a concrete result, we successfully held “Agile Japan, 2009”, the first Agile Alliance sponsored conference in Tokyo, on April 22nd, 2009 with over 200 attendees.

In that conference, we prepared “Pair discount” pricing and strongly recommended the attendees to come with their boss or clients. The result was 75% of them came in pairs! I believe it is a sign that engineers, managers, and clients have started talking to one another to make this software development world better with Agile (or whatever they call it.) I think this is the greatest effect of my winning the Gordon Pask Award.

Thank you very much.

Aaron: Thank you so much, Kenji.

Aaron: What one thing was most important for you to mention in your acceptance speech?

Jim: When Brian told me the main thought that came to my mind was, “Oh, boy… what am I going to do with this?” It is the only award that the Agile community gives. I had this overwhelming sense of responsibility, “How can I live up to this?” For the acceptance speech itself, I felt it important to mention the other people out there who are also contributing.

Aaron: How did you get involved in Agile and why is it important to you?

Jim: In 1999 I was asked to lead a team and in looking at options for methods to use on this team I decided on Feature Driven Development. Software process is something I had been interested in for a while. One of the people on the team said to me, “Let’s use XP.’ and I said, “What? What is this?” and he said, “Well you can read about it on Ward Cunningham’s Wiki” and I said, “The what??? Well, you know we’ve already got this established so I’d like to keep on going in the direction we’re going if that’s all right.”

We delivered that project. It actually got canceled part way through. Someone wasn’t paying attention to the budget. Which was one of the learning experiences for me about how much is involved in just getting a software project out the door. It was canceled but since we were doing iterative development we delivered the software anyway.

I started looking in to Extreme Programming and reading the stuff on the Wiki and it looked really interesting. Some of it looked absolutely ridiculous like pair programming was obviously stupid and incremental design, another idea that could not possibly work. It was proposed by people who I had a lot of respect for; whose language and thoughts resonated with me and what I know about software development. So I had to try it. Even though it was obviously dumb and couldn’t possibly work.

Aaron: How do you learn most effectively?

Jim: By trying things and seeing if they work. The next project I was on I tried a few things, like test-driven development. They worked really well. That company called me back and said, “We figured out what happened to the budget, come back.” They had misplaced their budget. I said, “I’d like to finish this up using Extreme Programming.” We did all of XP by the book as close as we knew how. I wrote about it on Ward’s Wiki. At that time it was fairly rare. There were a lot of people interested in Extreme Programming, but not a lot of people actually doing it.

I tend to write about my experiences. Shared experiences are the best way to learn. You know, direct experiences are the best way to learn and then the second-best way is to learn through other people’s experiences. Simply declaring an opinion doesn’t do much for me.

Aaron: Who are some of the funnest people that you’ve collaborated with?

Jim: I have enormous respect for a lot of people in the Agile space. Alistair Cockburn saw some of the things I was writing. He saw that I was located in Salt Lake City so he invited me to join his Round Table. I’d bring in my problems and we’d talk about them and I’d say, “That can’t possibly work” and I would go away and try it and come back and say, “Well, you know… that worked. Here’s what I did and now here’s the problem I’m having.” Which I wish more people would do. I wish people would say, “That can’t possibly work” and try it and find out. It seems like the mode is, that can’t possibly work and turn off brain.

That project gave me the opportunity to see how Extreme Programming works over the long term with a fairly large team. It was 8 programmers on this team, on average. We had a substantial code base by the time I was done with it. We delivered every three weeks from the beginning. Never missed a commitment.

Part way through this project I was hired to create a new team here in Portland. I hired Rob Myers to work with me who has been an XP coach for years. I really enjoy working with Rob. Diana Larsen and I do a lot of collaboration and she’s just fantastic.

I think the thing you’ll see in common with everyone I work with is they are all passionate about doing a great job. They are all passionate about seeing the industry improve. The people I’ve mentioned and others too, are about making life better for software developers and projects first.

Aaron: Is that what you find important to you about Agile methods?

Jim: In 1999 there was absolutely no monetary benefit in doing this stuff what so ever. I did it then for the same reason I do it today. It is the best way I know of for doing software development. After you’ve worked on an XP project for a year and a half that was really successful, working in any other way is like licking sand paper. It’s just really not fun. Doesn’t taste very good, either.

Aaron: What are some of the approaches that you used that allowed people to really pick this stuff up and run with it?

Jim: The biggest thing that I’ve always found is total immersion. It is my preferred way of working with people. There is enough of a mind set change involved in this work. The most effective way I’ve seen of conveying that; is to simply work with somebody who really knows what they’re doing.

Training some times works. It can inspire somebody who has got the idea. You can pick this stuff up from books. I didn’t learn this from anybody. I learned by trying and asking for help and talking about my experiences. And reading about it. I know it can be learned that way. What I’ve found in the ten years I’ve been helping people do this is following a leader who has done it before; having them work with you directly is by far the most effective way of getting it in to place quickly.

Aaron: Since winning the award, how do you feel your opinion or perspective on Agile has evolved?

Jim: I think it’s deepened. I’ve come to have a broader understanding of it. I’ve certainly seen the community change in that time. It’s now a moneymaker and so we’re seeing opportunists come in. We have a lot of people who don’t know what they’re doing. There’s a huge amount of marketing rhetoric out there combined with some fairly incompetent people. Even the competent people, the ones more interested in making a buck, are selling what sells rather than selling what works. That really bothers me. I do want to see the state of the art improve.

Aaron: How do we highlight these incompetent people and weed them out?

I don’t think naming and shaming is necessarily a good idea. Any publicity is good, as the saying goes. I think talking about the problem and establishing a culture in which certain things are respected and others are not is possibly one way to go. My hope and dream is that in the Agile industry we become synonymous with excellence.

Aaron: How do we get to that place where Agile is synonymous with excellence?

Jim: It’s a matter of culture. The more people who talk and write about Agile, who take the attitude that we’ve got to compromise on doing good work because nobody will accept it, the more Agile is going to become synonymous with mediocrity, for not working. We want to avoid the situation where we say, “Yes you’re all in the same building but no, we’re not going to take down the walls because that will make too many people uncomfortable. You don’t want to put people together, that’s ok. You don’t want to assign a product owner, OK. No worries. Your testers need to be in a different division? OK, no problem. We’ll make it work for you. We’ll take this thing and just have the domain experts write up a requirements document and hand them to the developers. They’ll do development in “Sprints”. We’ll call it “Sprints” so that way it’s Scrum, right? They’ll hand it to the testers and the testers will follow one “Sprint” behind and when it’s ready will show it back to…” That is the type of attitude that sells because it’s easy.

If we go the other direction, if we as a community say there are some situations in which Agile is simply not appropriate then we will sell Agile less often. We will have fewer people using Agile. By doing that we’ll have more successes. I would much rather have the Agile community being known as a community that is a little up tight, a little exclusionary, that always does great work.

Now I’m not saying that you have to do all those things. You don’t have to do Extreme Programming to do Agile although you do have to do some sort of XP-like engineering practices. It is possible to have a distributed team that is Agile. The further away you get from these Agile ideals of having a collocated team, of having a dedicated product owner, the harder and more expensive it gets. What I see happening in the filed is the further people get away from that, the more they water it down, the easier they try to make it.

The reason XP and Scrum say, “have a collocated team” is because we know the secret to successful software is having a cross-functional team that communicates really well. We don’t say collocation because Agile wants you to be collocated. We say collocation because that’s what leads to really good communication.

The other thing that happens when you have a collocated team is that you have unintentional communication, or unplanned communication. I’ll be working on something and if you’re sitting there, I might mention something about it to you. If I have to call you I’m not going to bother you.

If we’re going to work with an organization that does not have collocated teams, we can’t just say we won’t do that piece of Agile. We need really great communication. How are we going to solve that problem in a different way? Instead what I see people doing is saying, “That’s hard. We’re just not going to worry about that piece of it.”

Aaron: What are you working on these days?

Jim: I’ve decided to focus my business on the people who are interested in being great. Who have that desire to change their world so that they can be great. I also am working on a startup with Arlo Belshee and Kim Walmark. In my copious spare time I am noodling around with a new test framework to replace FIT.

Aaron: How do you know this team is capable of greatness?

Jim: I think every team is capable of greatness. At an organizational level I need to see real desire. In the end what is required for greatness is a willingness to try stuff. I think the ones who want to be great are willing to shake things up a little bit. I’ll hear things like, “Of course we have to fit in to the existing corporate structure and we need to go through our phase-gates.” And I’ll say, “What you really need in Agile is simultaneous phases” and they’ll say, “Absolutely, we should have that. But we need it to fit in to our lifecycle because if we don’t nobody is going to be happy and we just can’t afford to make those waves.”

Aaron: Talk a little more about these simultaneous phases, if you would.

Jim: I think simultaneous phases are the secret sauce of Agile engineering. You have all aspects of software development, which are traditionally called requirements, design, coding, testing, releasing, operations and support. Those are generally laid out as separate phases. That’s the classic waterfall lifecycle. Even people who do Agile methods like Scrum tend to take this classic phases and just sort of smoosh them down in to a shorter cycle.

Aaron: I like to call that the rapids.

Jim: Yeah. The rapids. Exactly. Simultaneous phases are having the ability to do all these things, all at once. Doing your testing at the same moment that you’re doing your requirements at the same moment you’re doing design at the same moment you’re doing your coding, at the same moment you are making sure that you are operationally capable.

It is difficult. That’s why this work does require a mind shift. Because it is difficult, it’s the thing the opportunists are ignoring entirely. It’s not something that you can just teach.

Aaron: Or sell. It’s a little hard to sell, “Hey, you know what? This is going to be incredibly difficult for you.”

Jim: Doing your design, coding testing simultaneously requires doing them in very small pieces and doing incremental design. What’s difficult about it is that you really, really need to have your requirements experts working closely with the team. Cross-functional teams and collocation are necessary to make that work and those two things I think are really important and also something nobody wants to do.

Even when I work with Scrum teams that were well trained, they often don’t do cross-functional or collocated. It requires doing things facilities doesn’t like, that the corporate structure doesn’t like. This is where the big wins are. The big wins are not in doing work in two-week Sprints. The big wins are increasing your communication, working simultaneously, because simultaneous phases are also a way of improving that communication so that you don’t have a throw-it-over-the-wall mentality.

Aaron: It sounds like not only are you talking about the walls between our traditional development and QA phases, but also between business analysis and development or design. All of these things blend together, requiring that collocation.

Is there anything else you’d like to mention or discuss?

Jim: I’d like to close by saying that the Agile community and the software development industry in general would be better served by people seeking excellence than trying to fit in.

Aaron: I was reading your old blog and found, “We in the Agile community need to do more to promote and encourage the rising stars of tomorrow”. What was happening at the time that prompted you to assert this?

Brian: I was at that time hanging around with a professor of sociology at the University of Illinois, who was writing a book on the British cyberneticians; very larger-than-life figures, but who had no effect. Eventually they retired, or died, and that was kind of the end of it. The first wave of people failed to build up the next wave. At the time I was wondering if we would have a next generation in Agile.

Aaron: How then did you feel that providing an award in Agile would help keep that community strong?

Brian: It would be a way of saying, “Look at this person. This person has things you need to hear.” So rather than tagging along behind Ward Cunningham at conferences, look up J.B. Rainsberger or James Shore. That’s essentially it. Listen to these people, give them opportunities to speak.

Aaron: What were some of the challenges in instituting the award?

Brian: There were none.

Aaron: There were none? Interesting because it says, “One day before the start of Agile2005, the Agile Alliance board voted to create the Gordon Pask Award for Contributions to Agile Practice.” Did you guys discuss it for a while? Was there something that led up to this vote?

Brian: We were at the end of a 2-day retrospective. Not much of immediate visibility was accomplished. It was more along the lines of: we will set deadlines, we will investigate the following in the future and I asked, “Well, why don’t we just do something?”.

I proposed the Gordon Pask Award and I probably ranted on about cyberneticians. Everybody said, “Hey, that sounds like a good idea!”. So somebody said, “How many people?” and we said, “Two.” and someone said, “How much should the award be?” and somebody said, “Well how about let’s make it something substantial like ten thousand dollars for the two of them?” and everybody said, “Great!”. It really went very fast.

Aaron: I was also noticing on “Luck” that there are some flaws to the Gordon Pask Award. Have you seen any of these troubles?

Brian: Yes, in the sense that at any given moment there are a bunch of deserving people. We always worried a lot that it would feel arbitrary. There was some talk that because of the issue we should maybe reward it to an idea. People like awarding it to a person over an idea, even though often that person represents an idea.

There have also been some worries that we could get locked in. The first two people who got the award were programmers. I’ve gotten complaints that it’s too much of a programming award and not enough of a management award and that could well be true.

Aaron: Are there different things you do to temper concerns people have?

Brian: The people involved in giving the award are all the past award participants plus the original three (Brian Marick, Rachel Davies and Big Dave Thomas) bring up the issue when we have the actual meeting.

Aaron: What comes to bear when you get together to discuss potential awardees?

Brian: We have basically divided it in to accomplishments and service. I remember in the first award I looked on my machine and saw that J.B. Rainsberger had contributed fully 37% of the posts on the test driven development mailing list. Looking through them a lot of it was spent answering questions. That’s contribution to the service, to the field. People who are active in user groups, for example.

Steve Freeman and Nat Pryce are both active in the Extreme Tuesday Club, which is where a lot of real good ideas have come from. That weighs in to it.

Aaron: Was there such a big pool that it was easy to draw from and has become tough over time?

Brian: The toughness is that there are multiple candidates. An issue that repeatedly comes up is that in theory we would like to believe that there is a person poised on the edge of some sort of break through and we can tip him right over the edge. One of the discussions we continually have in the meeting where we do the selection is, “Does this person actually need our help?”.

Aaron: I would assume that adds some difficulty in finding people that can really take advantage of what the award has to offer. Getting somebody’s name and their word out there.

Brian: Yeah, exposure. We’ve always had a discussion about, is handing somebody a check for $5000 the right idea? A better way to do that is to say the money is for speaking somewhere.

Aaron: And the idea was there because of cybernetics and knowing how much was lost through that. Was that somewhat of a prompt for you?

Brian: That was a prompt for me, yeah. I don’t know that any body else cared about that. I think they all thought, “Oh there he goes again with that ‘wierdo stuff’. It’s a good idea no matter what the motivation.”

Aaron: So I guess that ‘wierdo stuff’ is what got it to be called the Gordon Pask Award?

Brian: Right. The interesting thing about him is that he worked with communication. He had this notion of communication as a cooperative and competitive game. At the time it resonated with me when I thought about Alistair Cockburn’s stuff about projects as cooperative games and I think that was when I first heard of “pair programming ping pong” which has very much the style of Pask behind it. Of all the people he seemed to fit the closest to Agile.