Steve Ropa on Three Paths to Technical Excellence

1. Good day, friends. This is Shane Hastie with InfoQ and we're here at Agile 2015. I'm with Steve Ropa. Steve is with VersionOne. Well, Steve, you and I know each other but would you mind briefly introducing yourself to the audience?

Sure. So I'm currently a Director of Services at VersionOne. My main focus is helping consultants with VersionOne. Also with their Agile transformations or Agile understanding and growing deeper. My personal focus and passion is the technical spaces, the software craftsmanship, those practices that sometimes seem to get lost while we're focusing on how to move cards around a board.

Shane: Cool. Then that leads us nicely into the topic of this interview, in fact, is you've got a talk on technical excellence and a bit on the model on how to get there.

On how to get there. Yes. I like to think of it in terms of three paths. The first path, I'm a bit of a fan of Jerry Weinberg, as many of us are, and one of the things I love in one of his books is he points out that there's always a problem and it's always a people problem. So the first path is focusing on the people problem. It's not enough to say that you have to know three languages and you have to be able to solve certain problems before you can come on to our site.

We need to develop people. We need to be developing them -- maybe it's from the very beginning from, "Hey, I've always wanted to be a programmer because they make lots of money and get all the cool swag," or maybe they've been doing it for a while. Maybe they're changing careers.

We need to develop these people. They have skills of some type that may not be the programming skills. So finding a way to help them grow the programming skills and grow them well. It's not enough just to go to school, take CS101, and learn how to write in Java five functions, and then move on. You've got to have skills. You've got to have knowledge. You have a deeper understanding.

This development needs to happen and it needs to happen on the job. You can't really learn this stuff through a book. You can start but then you've got to be on the job. So my focus, and many people's focus, is on the idea of craftsmanship. Craftsmanship, taking that metaphor all the way to its logical conclusion.

We're going to have a workshop. Our workshop is going to have some apprentices. It's going to have some journeymen. It's going to have some masters. The only way to become a master is to mentor apprentices. The only way to stay a master is to mentor a journeyman. So by using this model, we're going to find a way to help develop people. Now, one of the challenges here is developing people in this realm, how do I know I'm doing well? How do I know that my career's progressing?

Let's take a look at micro certification. It's becoming very popular in the education industry. You're seeing it in a lot of places and a lot of times, you see this described as badges, Boy Scouts being an example. By having a matrix of what are these badges? How can I earn my Database Excellence badge? How can I earn my Functional Programming badge? What does it mean to earn those? How can I have three badges in, say, refactoring? How do I get there?

By developing that matrix, by developing that codification of what it means to be excellent in those skills, we can start to really create great programmers and great software craftspeople.

The other path is the technical path. This one, you can see it sort of grows from the first path. The technical skills, we've heard of them a million times, test-driven development, refactoring, red-green refactor, all of those things, automated acceptance test. All the way through, these are hard skills and we have to have them.

It has to be in my blood that if I'm going to start something, the first thing I'll do is write a test. I have to also have some of those tougher technical skills. Those are hard enough. But some of the tougher ones like how do I get the most performance out of this database? How do I create something that's going to be able to be distributed around the whole world? How do I handle internationalization? These are things that also need to follow that same path but we do need to focus on this. We need to focus on those specific technical skills while redeveloping our people.

The third path is really sort of this synergy of the other two. It's bringing them together, the whole being greater than the sum of its parts. How do I apply those? This is where we get into the things like applying principles. We all know the values that manifest at this time. Most of us remember all of the principles in the manifesto at this time. How do we apply those?

How do I do this on a day-to-day environment? That's why it's got to be on the job. You can start in a classroom. We need to form our organization as a workshop and part of that workshop is practices, principles, and practicing the intersection of those two items. So that's the path and that's what I'm going to want to talk about tomorrow.

2. If we come back to that manifesto, one of the fundamental principles of Agile is this concept of technical excellence and good design. How do we instill technical excellence in a team?

Now, we get to the people problem again. That's a fantastic question. It always makes me sad that there's only one principle that really talks about technical excellence. It's a people issue even though it's about technology. How do we instill that is by doing, by doing together. By those who have started to get that, sharing that with others.

My hobby is woodworking, and when I work on something in my basement workshop, I make a lot of mistakes. Some of them don't matter. Some of them do. But then if I'm in a workshop with a guy who's giving a class or just he happens to be working in a collective area, he'll just glance over and go, "Oh, that's okay, son, just move that over there. You're great." By having that deep in his psyche from years of experience and sharing it with me, I can start to have that same value instilled in me and that same principle of excellence.

The other is, honestly, we have to slow down. We have to -- the project management side of this, if your will, has to be willing to slow down, something that I feel very strongly. I don't remember who I heard say it first but I've heard many leaders say “you as a developer have the right to not ship crap”. Believe that. Live that.

If you're not the developer, understand that that's one of their rights. Now, you do have to ship something. You have to ship well. You can't say, "I can't deliver this until its perfect," because perfect ain't going happen. We need to remember that mentality of sufficiency but, yes. You have the right to not ship crap, project management, leadership has to respect that.

If leadership can respect that and can embrace that, not grudgingly but truly embrace that, the technical excellence, the ability to be that great will rise. Everybody wins because then we have high quality products. They're not failing all the time. We spent less time fixing bugs and we all know that fixing bugs is way more expensive than getting it right the first time.

Shane: Instilling that in the team, in the organization.

Yes, it's a long effort. It's instilling it in the team in the organization. Change how the team is laid out. Think of it as a workshop. In a workshop, things are laid out, and I'm talking about big workshops, things are laid out for the effectiveness and efficiency of the people who are doing making, the doers, the makers. A great example honestly was Henry Ford, early on. Now, we all think of Henry Ford as the guy who invented the assembly line where all idea was full time every day. The truth is that's not what he was describing. What he really wanted was each person to have their workbench area. They choose the tools. They choose the tools that work for them. They learn from others around them. So they're close to these others.

Now, they did only work on one part of the car as it moved through the assembly but it was their workbench, their ability to choose which tools were the most effective, which tools were going to be the most efficient. We can still do that. We need to do that. Organize the space around that.

We all know the ideal is to have the open workspace where the whole team is in the room, let's make sure it's the whole team. Product owners, developers, developers who test, DevOps, the operational side of it, all in the same room, let them determine how this should be laid out for their effectiveness. That starts the process. Then live it. Live it every day.

Resist the temptation to say, "Oh my gosh! We're in the crunch time. That stuff was great, now we need to change it, for the next two weeks and then we'll go back," because you won't go back. You might try to go back but you'll have already basically said, "Okay. The workshop's not going to happen."

It's highly disciplined. It's a little risky. It's a little scary. But as you go through, just like anything, as you go through that basic change curve, things are going to start to get very fantastic very fast. It's a great place to be.

Shane: Steve, thanks very much.

Thank you.

Shane: Really good to talk to you again and enjoy the rest of the conference.

Thank you.