Bill Wake on Getting Started with Agile

I’m here with Bill Wake a veteran of Agile for 15 plus years and a major contributor and thought leader in the space. Thanks for being here with us, Bill. » Thanks, Alex. I’m glad to. » Well, let’s talk about why we need Agile. There’s all these stats out there about only 20% of features are used and 50 to 70% of IT projects fail and the applicability of those tallies are going to vary for people but why do you think there are so many of those kind of outcomes?

I think the tendency has been that the people who think they have the idea for what to do, they come together, pool those ideas, feed them to a development team, and they find out at the end that things weren’t really what they needed exactly. And so they’ve kind of wasted some time and money finding that out. The shift we’re looking for with Agile, a couple things make the difference. One is, if we can get the broader participation from the community involved, so the users, the business people, the developers, the testers, everybody in the whole project, that we can get better information early about who’s there and what they really need.

The second thing is I think we’re looking for faster feedback. So if we can deliver things in a more timely way, then we can get things into the users’ hands earlier, get them using it, and find out what things they really need, which things they’re not using so much of, what things should we use more of, and learn faster from that reality than we can from sitting in a room and speculating for too long. » And there’s few people who say, I don’t like the idea of Agile, it sounds terrible, and yet a lot of the actual practices and principles are kind of thinly applied.

What do you think is hard about getting started with Agile and really making the practice effective? » I think a lot of it, it’s just a shift for kind of lots of different people, so it’s not such a great thing if the programmers wake up one day and said, let’s do Agile stuff. But they don’t have any participation with the users or the business people and so on. They can make their code better but they can’t figure out that they’re addressing the wrong problem or anything like that. It really needs cooperation from lots of people to make it work.

So, that’s a hard thing, especially for bigger companies, they’ve got lots of processes and standard ways they do things and if the standard is six months before we start programming, somebody does those feasibility thing and doesn’t talk to any programmers about it and then creates a bunch of requirements then eventually passes them off, there was no chance to really influence that early on. And yet, these things are all very tied together between the capabilities we can bring from software, the needs the people involved, and so on. So I think there’s a lot of challenge there. I think any particular thing you’re doing has its own challenges.

So if I’m a programmer and I’m trying to learn test-driven development or refactoring, it’s a new skill for me and it becomes a more critical thing as we speed up delivery and so on. I’ve got a whole set of new skills to learn. Not everybody’s going to necessarily start at the same place or be on board with it, so there’s a lot variation in how people look at things and how they think about how they’re going to work together, and so on. It could feel threatening to change things. It’s a hard thing. » You’re out there with a lot of practitioners and a lot of teams, and you have been for a long time.

I’m sure you don’t want to overgeneralize, but if you had, let’s say, your top three recommendations about how to make this interdisciplinary collaboration work better, what would they be? » Well, the first thing I would definitely look for is building up that working together across everybody type thing. So really seeking out all the stakeholders is what we use, the people who are affected by it and affect you, and really get that kind of whole project community together. If you can get that together, that helps a lot.

I think if there are skills that people need that you’ve got to either help them acquire them by training or self-learning or coaching or whatever mechanism, but there are going to be skills that people have to change. And then I think, the third thing, may be just that you’re going to have to expect that there’s a transition and a little bit of chaos as you work it through and if you can focus on, here are the results we’re expecting from this and are we moving towards those and how can we get better at that, that helps. It’s hard though. The bigger the team, the harder it is.

You talked about, here are the results we’re working towards, here’s why we’re doing this. Can you talk about some of the early rewards for doing Agile for both the manager or product person, product owner let’s say, and the developer and how are they different, how are they the same, what are the first things they start to see happening where they say, hey, maybe this is worth all the difficulty and the discipline this requires and the fuss?

Yeah, I think for a lot of groups when they first are able to ship something on a quicker basis, so they have an idea and they see it come to fruition in days or weeks and not months or years even, that they can start seeing, wow, I’m really starting to drive this through and affect things and that certainly helps. I’m not in the position where I’m going to trust that two years later you send me something, it’s more I can see it. A week from now, you show me something new, and it’s working, and that’s great.

So, from the user side of things or the product manager, product owner we sometimes say, that to me, when you see those changes coming in and your changes affect the team really quickly and all those things, that helps a lot. From the programmer’s side, I think it varies for different people. For me, I kind of started in from the refactoring aspect that I noticed that certain changes I was making, that I tended to mess them up the same way every time. So Donald Knuth had an article years ago about the errors he made writing tech, and I thought, that’s a cool idea.

I’ll do the same thing for a system I was working on and took track of every defect I introduced along the way. And what I noticed was several times I had done something where I got it into an infinite loop and it turned out that as I was changing from a for loop to a while loop I would forget to increment at the bottom or something. And so it happened several times and it forced me to say, okay, you have to be systematic. Every time you move from a for loop to a while loop, move this piece first, put it down here, then move this, then do this.

And kind of that refactoring mindset to say, be very careful not to affect the changes. And so, for me, coming from that, that was an appeal. Other people I know have liked the testing aspect of things that they can say, I’ve got the test and now it passes that test, and I’ve got this big pool of them and anything that goes a little wrong over here probably breaks something over there and I can see it happen. Others, maybe a little bit towards just seeing, if we can get our defect levels down, then my pager stops ringing and my phone doesn’t go off, and all these things that can happen to you.

Just, say, there’s a problem and you have to deal with it. So, the fewer of those the better. I think when things are gelling for everybody, it gives something to each person and lets them all see the different sides that help them and hopefully builds that appeal for the whole thing. » And do you think the teams are happier working this way? » I think so. Some teams definitely are. I think where it’s more challenging is, again, the bigger companies that, if you’re changing lots and lots of teams, 100 people or 500 people or something like that, it takes a long time to get everybody aligned and working in a compatible way and so on.

So I think the benefits are a little slower there and I think, at least sometimes, organizations, they tend to push more top-down sort of thinking and try and control things more than maybe is helpful in the context of this. And if it’s used as yet another way of managed control and operate these teams, that’s not necessarily going to make them more happy about what they’re doing. If it’s used to really connect teams to the people who need things and all of that and they can see the results, at least for a lot of people that seems more appealing. » And what is it like for the engineer?

I know you guys, you and your firm, work with a lot of engineers on coaching TDD and XP practices as part of Agile. What do you think it’s like? What’s the typical engineer’s journey for getting started with these practices? What’s it like for them? » Well, I think there’s always some lag. If you’re not used to refactoring or you’re not used to test run development or setting up continuous integration, these things, it’s going to take you a little while to get used to it.

So I think just like anything you learn, there’s some bumpiness around it, you struggle a bit, all of a sudden at some point you see how it fits together and then you’re off and running at a different level, hopefully a higher level. And I think you go through that cycle with things, you go through some struggle with some people kind of getting it and some not. And this person’s kind of undoing what that one does because they don’t really see it the same way, and it takes some time to build that consensus for things. But it is a skill that comes as you use it, and a of things aren’t that hard and have kind of direct benefits.

So setting up continuous integration, you go from lots of builds not really working to a very repeatable process that’s all automated, and all of a sudden, all of these configuration things, and a lot of stuff that you might have to mess with otherwise, goes away. So you can at least see some early payback from that. During factory and testing, may be a little tricky, but they pay off pretty soon too. You can see the effects. Building the skill might take a few months for you. That’s the way a lot of things are. » That’s some great advice on the what and the how of Agile and the why. Thanks so much to you, Bill, for joining us.

Thanks for having me, Alex.