Jade Meskill, Drew LeSueur, Roy van de Water, and Woody Zuill discuss:

• Agile Success
• Questioning the Agile Manifesto
• 3 new Agile mantras
• The importance of clean code
• Agile Open SoCal

Transcript

Roy van de Water:  Hello, and welcome to another episode of the Agile Weekly podcast. I’m Roy van de Water.

Drew LeSueur:  I’m Drew LeSueur.

Jade Meskill:  I’m Jade Meskill.

Roy:  Joining us today is today is Woody Zuill. How’s it going, Woody?

Woody Zuill:  Real good.

Roy:  You’re currently at the Agile 2012 conference, right?

Woody:  Yeah, I sure am in Grapevine, Texas. It’s really, really nice here.

Roy:  Have you seen anything totally awesome there in the last few days?

Woody:  Yeah, I’ve gone to a lot of sessions, and they’ve been great. As a matter of fact, it’s really nice to see, in person, some of the people that I’ve read books and followed for so many years. A few of them are old friends now, but some of them I’d never seen before. I think the top thing for me, so far, has been a little one hour session by Robert Martin on clean code. As you can imagine, he’s always good with that stuff.

Mary Poppendieck, who her and her husband, I guess, wrote that Lean software development book, which I’ve put to great use over the years and completely worn out several copies. Eric Meade, I just saw a session by him just a few minutes ago on decision making. It’s a lot of eye opening stuff.

Overall, I think what I’m seeing is that people are really moving forward beyond just the simple Agile ideas, and trying to figure out some bigger problems. I’m enjoying that a lot.

Roy:  We had talked to a previous guest, I think that was helping to organize the event, was telling us that there was going to be a much bigger focus on the technical side of things. Have you been seeing that a lot or is it…?

Woody:  Yeah, there’s a development stage. I think it’s called development practices stage, and I’ve gone to several of those sessions. But I haven’t been able to go to all of them. They were doing like a code retreat today, and so that’s kind of interesting. I wasn’t able to stop in on that, but those are very code and coding practices focused sessions. That’s sort of my focus. That’s where I think I bring the most value is knowing about that stuff and bringing that to my team and things like that.

Jade:  You wanted to talk about Agile success.

Woody:  Yes, Agile success.

Jade:  What does that mean for you?

Woody:  Over the years, I’ve been doing what you might now call Agile since 1998. You add up the years, and when I was first introduced to it the TMI was on. I knew nothing about it except for what I had read, but the TMI was on, what I would consider ultimately successful. They were extremely good at cranking stuff out of extremely high value.

As I watched what they did, I said, “I just want more of this.” Then I went out into the real world, and looked for projects that either people were saying they were doing agile or wanted to do agile. I very rarely found anybody being effective. They were either hoping to do agile or wanting to do agile, but they just hadn’t gotten there. I’ve been through a lot of those things.

Going to these conferences, and these things like the open agile and all the user groups, I’ve talked to a lot of people who are still trying to figure out, “How do I get this working for me?” I put together a little talk just on what I would consider the main things, which is the agile values and principles. It always seemed to surprise people that these things existed, which really bothered me.

That’s sort of where you should start, that’s what you gives you a way to judge, “Is this practice I’m doing helping me? Am I thinking in the right way to get where I want to go?” It’s kind of like something I think I learned when I was a young man, or actually a teenager, and this very, very old guy that I knew, he was in his 80s when I met him, and he was really, really genuinely good. He was good to everybody, he treated everybody nicely.

Then I knew some other old people who were pretty crabby all the time. I started noticing they either leaned towards being crabby or leaned towards being good. Not too many in the middle, who were sort of half‑crabby/half‑good. It dawned on me that you kind of gravitate toward what you allow yourself to be, and so I’ve held that through my life. I want to always lean towards the good if possibly can, so, when I’m old people can say, “You know, he’s a nice old man.”

That’s my goal in life. That’s sort of what the agile success talk was about, if we lean toward the agile principles, then whatever we decide to do for practices are going to hopefully be agile. If they’re not, we’re going to hopefully, more than anything else, adopt that idea of retrospectives or reinventing ourselves continuously. If you really adopt at least that one principle, you’ll hopefully get better as long as you do it in a somewhat consistent manner.

Jade:  What were people’s reactions to that proposition?

Woody:  What happened is the people that were trying to do agile, but hadn’t even caught on to the idea that values and principles are what should be guiding us, although that seems fundamental to me. Once I started doing math talk then people come up and say, “We’re already trying to do all these, but we’re having these other problems.” I ended up, eventually anyways, adding some of my own principles and values. That sort of an important thing is there is the agile values and principles were kind of locked down quite a while ago. We might…

Roy:  That doesn’t sound very agile.

Woody:  Exactly. We got to be ready also to sort of adapt. We’re the inventors. We’re the innovators. No less soul than anyone else. We have to take responsibility for our own process where we are headed. I kind of gave myself what I would consider three new maxims.

I had to come up with something, because they already were using values, and they’re using principles. I figured I will use some other terms for the moment anyways I’m calling a maxims. But one of them is this. It’s in the doing of the work that we discovered the work we must do.

If we trick ourselves into thinking we can figure out what we are going to do before we actually do the work, we’re always going to fail. That to me is a critical maxim, and that is my focus every day as we do the work. We are going to discover the things we didn’t or couldn’t figure out before we started doing the work.

Jade:  I really like that. Do you have a good story where that maxim came true for you?

Woody:  Sure. I’ve got tons of them, so don’t get me started. A good example is in a very simple little project I was working on, there was a couple of features that we wanted to do, and they’ve written out exactly what they wanted. I should change it what I just said.

Their requirements for this project were dozens of pages. That’s none of my rules. I don’t like to call things projects. We’re doing development let’s say we’re doing software development not software projects. Projects is like making a deck or making a model airplane. All the instructions are there, and you got all the parts, put it together. See, now I’m going on and on. But here is the thing, they put together these huge documents, and the team kind of got blocked on actually getting any work done.

They got to the point where they were making no progress, and they were starting to break the already working project that was in production. They weren’t keeping very good control of their source code, so they were really getting into a mess.

What we did is we just sliced off ‑‑ I like the term sliced off ‑‑ a little bit of function that will give them some value today. If they could have it today they could be making more money with this little built functionality. I said, “Well, let’s make a little prototype of that.” That’s another thing. You always have to call things a prototype because nobody understands that we’re working on a real project little bit at a time. But if we make a prototype, that makes sense.

We made a little prototype. They took a look at it. They said, “We want to change this, and we like to change that.” We have written a little bit of functionality based on their nice instruction in their requirements document. It should have been correct, but this proved to them, I think, real quickly, without of saying anything that those document really weren’t the final say on what this was supposed to be. It was in the making of this little feature, it wasn’t much.

I can’t tell you what it was. It’s kind of a proprietary thing, but this little feature that they start discovering what they really wanted to do. But bottom line of that story is after we got about the first five or six really top features all the rest to that thick document went away. They didn’t even ask for even ask for any more it. They switched to another chunk of functionality they wanted to work on. That’s the real value of agile. Maximizing the amount of work that we don’t do, that’s really a wonderful saying. There we go. You want another maxim or…?

Drew:  Yeah.

Roy:  Let’s go to the next one.

Woody:  The next one, I think, what I’ve been seeing a lot is projects, and I hate to use that term, but these are projects where they want the promise of agile. The big part of that is responding to change, but you can’t really do that unless you really have easy to read codes that easy to maintain and easy to grow. My next thing is embracing the change is impossible if your code is not easy to read, easy to maintain, easy to grow and easy to change.

I learned that stuff from my little brother, who is also a programmer. Everything else is secondary. If you don’t get that in there, you’re not going to be able to do agile. It’s got to be easy. Because, you know, when somebody comes in and says, “Wait, wait, we’ve got to change this thing.” Have you ever heard this one, where they say, “Well, you should have told me that in the first place, because now we can’t really change it without pushing the deadlines out.” We don’t ever want to have to use that excuse. Does that make sense?

Jade:  Yeah, that’s great.

Woody:  I always ask that. Does that make sense? It’s probably kind of a faulty thing to ask, because if you didn’t understand, I couldn’t tell.

The third maxim is really a simple thing. Remember, this is the advanced part of the course. This is not the basics, this is really advanced for people who are really trying to do this, and this is the maxim. Question everything. The main thing I question is the things that I think are the most true. Whenever I catch myself going, “No, this is the way things is,” that’s the thing I start questioning.

Why did I allow myself to get that rigid about something? But I question everything, like we were saying earlier, even the agile manifesto. Not that I need to change it. I just want to make sure I’m on track with it. If something doesn’t bring value I want to discover that. Maybe I can’t discover it, but I can keep questioning.

Someday, if somebody brings to me something I am doing wrong, I want to hear it, I want to evaluate it, and I want to change, if it turns out I am doing something wrong. I want to deliver as much valuable software as quickly as possible in a very sustainable manner. Not all projects are that way, or not all companies are that way. I don’t like to call these things projects, because I want to see them going on forever. Let’s keep adding value to it, as long as there is value that can be added. I probably used up our whole time already.

Jade:  We’ve got four minutes.

Drew:  The question everything, I like that one. It seems to go right in line with respond to change and also respect and adapt.

Woody:  Oh, yeah. That’s the inspect and adapt right there. I just did it in different words so I could copyright it.

Drew:  That’s good though. Back to your 12 page featured document story that you told us you know, that was something that you could have questioned right from the beginning.

Woody:  Yeah. I would myself question it, but a lot of times when you get in an environment where this is the way they do business, you have to find a story that they can understand. They can’t understand the agile story often. This is the thing, Agile, although it really seems obvious to me, for whatever reason doesn’t seem obvious to a lot of other people.

What seems obvious is, “Hey, let’s make our plan and follow our plan, and we’ll get it done.” Everybody is excited about that, they think it makes sense. But I like more, from Napoleon’s rules of war or whatever he called them, the engage and see. Let’s get in there. We’ll get to wherever we’ve got to be. Let’s start a battle, and then let’s see what the enemy does. Then we can decide what we need to do.

But until we do that, you know, they’re ready to trick us with something. We don’t know what’s coming down the road. We want them to show their hand before we show ours. This isn’t really a war, but I like to engage, and then see what we get. That’s in the doing of the work.

Jade:  That’s awesome.

Roy:  I believe that you are working very closely with the group that’s organizing the Agile Open SoCal that’s coming up, right?

Woody:  Yeah. That’s a great little conference at UC Irvine, that’s coming up I think that’s September 13th or 14th, that’s coming up pretty soon. You guys were at that last year, I remember.

Roy:  Drew and I were planning to be there as well.

Drew:  Yeah, it was a whole lot of fun. That was my first open space format, and I loved it.

Woody:  Yes, that’s a good point. The first one you go to is always the best, the rest of them are pretty disappointing. I’m kidding. I think I’ve been to 10 or 12 of them now, and the very first one I went to was the scrum alliance, scrum gathering thing, and Diana Larson was the facilitator, and it just floored me at how wonderful it was.

Jade:  Yeah, she’s great.

Woody:  She’s great. The whole event was great. Then this one, I got a chance to get involved with it about three years ago, and last year I was the main host or whatever, and I jumped right on board to do it again this year. It’s a wonderful event at a very nice little venue. It’s very inexpensive right now. Through the end of August, there’s the early bird registration so you can save a little money, but it’s cheap anyway, it’s $250. Right now it’s $150 if this thing broadcasts before then. People can take advantage of that. It’s well worth going to.

It’s also small enough to really get to know everybody that’s there. I think that’s a wonderful advantage to these nice little conferences. This one here, the Agile 2012, it’s really great, but I’m just overwhelmed by the number of people. It’s huge. I don’t know how many people are here, but at least 1500 or something.

Jade:  It’s a very different kind of conference.

Woody:  For a small town guy like me, I get pretty scared.

Roy:  It sounds awesome. I’m looking forward to being there, and hanging out with you.

Woody:  This has been great guys. Anything else you want to cover?

Roy:  No, that’s it, thanks for joining us.

Woody:  I’m looking forward to hearing this and your broadcast. I guess you go out every week.

Jade:  Yep.

Woody:  Excellent. That’s why you’re called agile weekly.

Jade:  That’s right.

[laughter]

Woody:  Very cool. Thank you, guys. Thanks a lot.

[music]

Announcer:  If there is something you would like to hear in a future episode head over to integrumtech.com/podcasts, where you can suggest a topic or a guest.

Looking for an easy way to stay up to date on the latest news, techniques and events in the agile community? Sign up today at agileweekly.com. It’s the best agile content, delivered weekly for free!

The agile weekly podcast is brought to you by Integrum Technologies, and recorded in Gangplank Studios in Chandler, Arizona. For old episodes, check out integrumtech.com, or subscribe on iTunes.