Dr. Charles Suscheck is a nationally recognized agile leader who specializes in agile software development adoption at the enterprise level. In this interview, Charles discusses enterprise-level agile and Scrum, convincing management to take to agile, and what the new year will bring us.

Jonathan Vanian: We are on, and this is Charles Suscheck. Thank you very much for taking the time for chatting with me. Charles, you've been writing with us for quite a while now, and so why don't you give a little background on yourself for some of the readers who might not be familiar?

CS: I've been in the computer industry since the '80s. That's when I got out of high school; went right into the college after that. I've got a bachelor's, master's, and doctor's in computer science, and I just love the industry. I used to work at Colorado State University for a good four years as a professor, teaching all sorts of great programming languages. I used to do Cobol programming. I used to do dot.net programming, but the important part is I had a really hard childhood.

I knew I had a hard childhood because my family didn't like kids. The way I knew that is, everybody else had a sandbox except me. I had a quicksand box. Eventually, I was an only child.

Other things of importance: My dad was a discount exterminator. He'd run around the house with a rolled-up newspaper. That's what's important about me.

JV: He was a bug finder.

CS: Yeah, a bug finder.

I'm been working in agile for quite a number of years. Started out in about 2001 and applied it very naively, just like everybody else. I've learned a lot over the years. Worked with a lot of really big companies, some large companies that had over 100 projects, fifteen agile coaches on staff. Right now, I'm taking to a company that has 2000 people, firing up a project using a scaled-agile framework. It's a horrifying thought, scary, that much work at once.

I've worked with some small companies with some really smart and great people. In fact, a lot of your writers, too.

JV: What got you into agile in the first place, and why did you make that leap?

CS: I used to be a rational unified process coach, just like everybody else that was in agile at that point. I found that it made life horrifying for developers and a lot of other folks in the industry. Not the process itself, but the predictive nature of it. People would be backed into the wall on delivering software in a certain timeframe, which didn't make any sense, and I started to find out about agile and understanding the empirical, emergent nature of it, and it really makes life better for people. It's a humanistic type of approach.

That's really what got me into it is it helps people. It's not so much about the making money but about being honest and helping folks.

JV: When you first started, what sort of stumbling blocks did you experience, and what lessons did you learn from doing those first transitions?

CS: I'd rather not talk about those first times and sound foolish, but I can tell you that the biggest changes I've had over the last few years is just understanding how it really flows from the Deming approach of "Plan, do, inspect, and adapt," and how that kind of an approach makes so much sense.

Really, honestly, I think a lot of the work that I do is giving people permission to work together rather than have the worker-bee mentality where management tells you what to do and you come back and say, "Yes, sir. I will do that," even though it doesn't make any sense. It's the collaboration. That was the biggest learning I've had.

One of my friends said something interesting about the difference between Scrum and XP. I always thought of Scrum as you're doing little time boxes, plan, do, inspect, adapt. He said, "You know, that's really good, but XP is more about the feedback and getting feedback going quickly," so there's a difference in the two. That was an interesting way of looking at it.

JV: It's that stream of communication. It's almost like keeping everyone in the loop and always being on top of things.

CS: Being honest about it, too, as you work together.

JV: Right. Actually, why don't you explain a little bit about the honesty aspect of it?

CS: I'll give you a great example. I worked with an insurance company recently, and I asked them, "You have an insurance rate change that's coming, and it has to make that date, right?"

"Oh, yeah. We've got to make that date."

"Why do you have to make the date?"

"Because it went through a government regulatory body, and if we don't make that date…We always make the date, so we've got to make the date."

I asked them, "What happens if you don't make the date?" It was like sticking a hot coal in their eye. I couldn't believe me, and eventually, I got to the point where I talked to them and said, "What happens if you don't?"

"Well, we get a fine."

That was, right there, honesty. Yes, you can miss the date but you'll get a fine, so you've got to weigh that.

What about not making the date and processing the returns manually, or stopping those kinds of returns for a while, those kind of insurance policies, or not having the quality and not testing it all; letting it go and fixing the bugs later?

That's another thing. That's what management does is weigh the different options. It's not that they come down and say, "You will make that date by going … that's it." The honesty is working together with management to say, "Man, I don't know if we can make it. We have to be considering different options at this point and what we can do about that."

JV: You have experience working in regulated environments. How do you use in these regulated environments?

CS: I worked with a company that was doing FAA work. They want to talk about a regulated crew of guys.

Of course, we couldn't deliver the documentation without a Big Bang approach, but we started to invite them to our bi-weekly sprint review sessions, and they liked that. We started to give them documentation two weeks at a time, and while they couldn't review it and approve it all, they could look at it and get caught up so that at the end, after several months of working on the project, they were able to understand what we were up to and not get a 600-page regulatory document and have to read it from scratch.

They were merging their understanding of it, too, so we were coming up with potentially releasable products every two weeks. That doesn't mean "released." That means as doggone close as we can get.

JV: Potentially released.

CS: As close as we could get to the edge of that cliff or as the regulatory to get them in there to talk to us. It was still using plan, do, inspect, adapt to inspect the product we were developing and to give some planning to the poor souls in the FAA.

JV: Speaking of those tight regulations, how about dealing with agile in a healthcare environment? That's obviously a big regulatory field. Can you explain a little bit about how that fits in with healthcare?

CS: Let's not talk about the government debacle that's going on right now, but with other regulatory environments, I can see this being used in firmware. I can see this being used in life-critical systems, too, especially in-life critical systems.

JV: Can you elaborate a little bit more into that?

CS: You don't want to develop the software based on something that is only conjecture at the beginning. You're designing the software, sure enough, but what if you run into problems with the software or with the hardware interface or the way that it's working? Do you want to then keep going down that path? I don't know. I think you need to be able to change, based on what you're learning.

I'm not saying don't have a plan. That'd be foolish. Anybody in agile that says you don't have a plan is selling snake oil, but having that plan at the fidelity that you possibly can at this point, that's the way to do it.

With regulatory environments, highly regulatory, there's a lot of risk. A lot of risk; is it going to work right? Am I going in the right direction? Even more so with those environments. You want to look at what you're doing. You want to adapt where you're going. You want to inspect what you're up to. You want to test it frequently. Those are all things that fall into the agile environment. You don't want to test it at the end.

JV: How's it been working with some government agencies with agile? How are they taking to any of the techniques?

CS: To be honest, I haven't worked with a lot of government regulatory environments in the last couple of years, so I don't think I can answer that one very well.

JV: Okay. That's fair enough. Let's talk a little bit about the past year and the continuing growth of agile.  What have you noticed as far as the rise of agile since you first started doing your first implementations, the big trends you saw?

CS: I'll tell you what I'd like to talk about over the next coming year. There's a lot of interest in enterprise-level Scrum, enterprise-level agile. That's a tough nugget to crack.

JV: Why is that a tough nugget?

CS: It's an organizational change. There's no doubt about that. Implementing Scrum or even XP at a team level, that's not so bad, but then you start worrying about, "How do I interact with a business," because I'm either outpacing what they're doing or they want to do a predictive-planning model. That starts to go up into a higher level.

Then you start talking about multiple teams, a bunch of teams, planning out for a couple of years, doing financing. That's the hard part. I worked with scrum.org. One of the things that I've read into is their agility path, which is kind of cool. It's a way to do organizational transformation using plan, do, inspect, and adapt. How do you change your organization to adopt more agile practices where you can use this same type of plan, do, inspect, adapt?

The way they're approaching it is, "What do we inspect?" I think the first thing they said was, "Let's get some metrics we can measure so we have something to inspect, and then we can come up with our adaption, our own plan for changing the organization." That's a really empirical way of growing out gradual to an enterprise level.

Now, you take that and compare it to a scaled agile framework. I went to the class on that. I've seen a couple planning sessions where they had 150 people in the room. It's kind of cool. In fact, it's really cool to see something like that going on.

The way they're doing it, though, is quite different than scrum.org. They're giving you a turnkey process. "Here it is. Here's the starting point," and they're not so wound into adapting that plan.

Now, is that good or bad? I think the organizations have to make that determination themselves. Maybe some kind of a hybrid between the scaled agile framework and Scrum's path to agility on top of that. I'm not sure.

JV: Obviously, the big dilemma everyone faces is getting management to accept agile. Is there any sort of suggestions you can give people when they're having the conversation with business leaders?

CS: I have a couple great stories that I tell about that.

JV: All righty.

CS: The first thing on a management level, I've got to ask you: When do you know the most about a project as far as the delivery dates, at the beginning or at the end?

JV: Let's say the end.

CS: One would hope at the end.

JV: Yes.

CS: We'll know more about the schedule at the end. How about the requirements, the beginning or the end?

JV: Let’s say at the end.

CS: Probably, yeah. Why do people put all the requirements up front, do all of that and then do the planning, and lock it down when they know the least about the project?

JV: That's because “That's just the way we've been doing things.”

CS: Yeah. It's silly. We used to live in caves, too. We ought not do that anymore.

When I was young, I used to play this game … and you shouldn't do this. If you've done it, don't even tell me.

We call it a "Red-Necked Chicken." We'd get a bunch of our friends in high school, put them in our car. Tear off at night, mind you, at night, down to a dirt road, and we'd drive down that dirt road really fast. We'd turn off the lights. Everybody would get scared. Then we'd turn the lights on, and everybody's screaming, and it was great, and you'd go down a ways and turn off the lights again until people got scared and you'd turn them on. Hopefully, you're not in a ditch.

It was great fun. Great way to pick up chicks.

JV: It sounds like it.

CS: Yeah, well, that could be pretty scary, and you could make it more scary. You go faster. You go down a road with a bunch of twists and turns, an unknown road, that's scarier. Get more people in the car. That's even more scary, because everybody's screaming.

You've got bad weather conditions. That's scary. That's what we do with software development. We come into the requirements phase. We say, "We're going to do a project. Here's some funding." Then we turn off the lights, tear off down that road for a while.

Then we come up to the design. We turn on the lights, look at the requirements, go into the design. Then we turn back off the lights when we go into the design. We get to the coding phase. Right before the coding phase, we turn on the lights, look at, turn it off and go into coding for a very long time.

Now, why do we scare ourselves to death when we code, when we develop projects? It's kind of silly, isn't it? That is the way we do it, though.

JV: It is. It's a little terrifying.

CS: If you have a faster project, you want to get more things done. Do you want to turn on and off the lights more frequently? Just like driving at night. Sure you do. You've got unknown variables, external variables affecting you. You want to turn the lights off and on more often.

You've got a critical project. You're driving down a rough road. You want to turn the lights on more often.

You've got more people on the project. You want to inspect and adapt more often. That's what agile really is talking about: inspecting and adapting, and it seems silly not to do it. That's some of the ways I try and convince upper management about it.

JV: That sounds great. Hopefully, some of our readers will use that example. That's a very specific example.

CS: I don't know.

JV: Let's end things on a little look to the future for 2014. What do you see in store for 2014, as far as agile goes?

CS: I see a lot of team-level work becoming almost a commodity. People say they're agile coaches and they can come in and help a team. A lot of people can do that now. It's not rocket science like it used to be. 

I see another problem in that if scaled agile framework isn't careful, they're kicking off people that are certified scaled agile framework consultants who have just gone through a five-day class. Then they step into an organization and try and make an organizational transformation. If they're not careful, those people can bring a lot of bad words to agile just because they're not experienced.

They come in. They goof something up, not at the team level but at the organizational level. That might start to kick up its head a little bit.

I see some things with Scrum with the organizational transformation. It'll start to make a difference, I think. I'm going to stop calling myself an agile coach and call myself a business consultant, I think because everybody's an agile coach now.

JV: All right. Then we can update your bio. Let me know when that change happens, and we'll update that. Thank you so much for taking the time. Hope the holidays are going well for you.

CS: Thanks much, and I hope my stories were entertaining to you, if nothing else.

JV: Definitely. All right, Charles. Thank you.

 

Dr. Charles Suscheck is a nationally recognized agile leader who specializes in agile software development adoption at the enterprise level. He is one of only eleven trainers worldwide and three in the US certified to teach the entire Scrum.org curriculum.  With over twenty-five years of professional experience, Dr. Suscheck has held positions of process architect, director of research, principle consultant, professor, and professional trainer at some of the most recognized companies in America. He has spoken at national and international conferences such as Agile 200X, OOPSLA, and ECOOP on topics related to agile project management and is a frequent author in industry and academia. Dr. Suscheck has over thirty publications to his credit.