Agile Success with Woody Zuill

Episode Special

August 15, 2012




The Agile Weekly Crew and Woody Zuill discuss Agile success, the Agile manifesto, new Agile mantras and clean code.

Episode Notes

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


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 cod