Roy van de Water, Clayton Lengel-Zigich, Derek Neighbors, and Jade Meskill discuss standardization and the effect it has on innovation.

Jade Meskill: Welcome to the Agile Weekly Podcast. My name is Jade Meskill.

Derek Neighbors: I’m Derek Neighbors.

Roy van de Water: I’m Roy van de Water.

Clayton Lengel-Zigich: I am Clayton Lengel-Zigich.

Jade: Derek you had a topic that you wanted to talk about today. What is it?

Derek: Yeah, something I’ve seen a lot lately is when teams start to really get agility they really start to get high performing. One of the things they tend to do is go around roadblocks. They tend to start to basically, maybe choose some things that the higher powers in a large organization aren’t comfortable with them choosing. There becomes this divide that starts to say, how come you’re not following standards?

Whether those standards are set or whether they’re not set. Whether it’s an architecture thing. Whether it’s a language choice thing. Whether it’s a process thing. You name it. At what point does being agile in supporting the best ideas, and moving forward, and having the people closest to the work make the decisions about the work start to compete with centralization and efficiency?

The problem is if everybody uses .NET, then we get the benefit of people can jump from team to team, or we get all the benefit of being experts in .NET. But if you’re doing Ruby and I’m doing Java and you’re doing .NET and you’re doing C# and you’re doing whatever, now we lose all of this efficiency.

There’s this tension between “We’re trying to be innovative and just go as fast as possible” versus “Don’t you want to be efficient, and have standards that we get benefit, or this economies of scale?”

What have you guys seen in that area? Where do you sit on that sort of thing?

Jade: When you started talking about this I remember a time when our team had started to deal with some of this, our Integrum team, and tried to standardize on certain libraries, and certain techniques, and things like that.

We kind of went through this phase, exactly what you were talking about. From what I recall it was a total disaster. We were even using the same language at that point in time.

Derek: If you guys would all just use Emacs I wouldn’t have been such a [inaudible 02:19] about it.

Jade: [laughs] It really hampered the ability for teams to make the right decisions that were right for the project that they were working on. It became this whole committee situation, and in the end we completely abandoned it, because it was not functional for what we needed.

Derek: I see a couple of benefits and problems with it. I think that it’s nice to have things standardized. The thing I can remember at the time was, everybody was setting up servers a different way. When I had to deal with a problem with some client, and I went to go log into the server, shit was all over in different directories. People were using different stuff. When you really talked to them, there was no like, “Oh, we did it this way, because of this.” It was just, “Oh, I don’t know. I liked Apache, so I used Apache even though everybody else was using Ngnix.

Great. Add in an extra four hours to me, figuring out what the problem was, because everything was non-standardized. I think one of the things that we started to do that worked really well, was to treat things more like an open source project. If somebody had a good idea, people would support that. If people wanted to fork it or do something else, there wasn’t a whole lot of, “No, you can’t do that.”

But if it bit somebody else in the ass, people were not nice to you about it. It’s like, “Hey. If you weren’t going with the best idea that everybody had, fine, that’s great. Do your own thing. But don’t expect a whole lot of support when you’re out on the island all by yourself, and you’ve gotten yourself into trouble.” I remember one distinct incidence where we were talking about moving, I think, to Home Brew or something. Nobody really wanted to move to that. We were a little concerned.

Somebody said, “No, I tell this is the best thing ever,” and somebody said, “OK. Well, if something goes wrong, I can punch you in the nuts if it’s problem.” The person said, “Yes, it’s fine with me. I believe in it that strongly.” I think sometimes to me it’s not about having standards in the sense of written rules and policy. I think that’s when you get in trouble.

But I think when you have — I won’t say, best practices — but when you have some consensus and some alignment about trying to be good, as long as you have the door open to explore, and try new things, you’re OK. It’s the minute that it’s like, “Well this is the way we do it, and you can’t do it any other way, no matter what.” That’s when it gets really dangerous.

Roy: I think the idea of standards — I don’t really like the idea of standards. I think that if you have a particular way that you want something done, and you want to have everybody do it that way, you need to make that the easiest path for everybody. In your example, if I want somebody to use Apache, I’m going to make it really freaking easy to set up an Apache installed the way I want it set up.

It’s going to be so easy, that you choose Injenix, but it’s going to mean a lot more work for you. That way I’m not forcing my standard down on you, but I’m giving you a lot of incentives to use my standard.

Derek: I think that tends to be the open source model. Which is, if I fork it and make it easier, people will use my stuff instead of your stuff.

Jade: It’s technical Darwinism.

Derek: Right. But it’s a lot different than saying, “Hey. Use mine, or if you don’t use mine, I’m not going to help you.”

Jade: Right. Mine was approved by the architectural control group.

Roy: One of the things I’ll say that I see on a lot of new teams too is the opposite of that. What happens when somebody says, “I think that we should have 80 percent coverage, or 100 percent unit tests.” Or, “We should do this instead,” and now you don’t allow anything to come into this source tree that doesn’t have those. Isn’t that a standard?

Clayton: Yeah, but that’s a lot different all of a sudden.

Derek: Oh, so your standards are OK, but my standards aren’t.

[laughter]

Derek: Oh, I see you’d think, so I am maintaining a project, and you’re trying to contribute to it, I want to say that I have a standard that says, at least 80 percent source coverage, before I will take your request? That I totally agree with. I think that’s fine. I just disagree with the idea of me enforcing my standards on you, on your project.

Jade: I think Darwinism also comes into play there. If your standards are unreasonable, and nobody can give back to you, well people are going to stop working with you, and you’re going to die and wither on the vine.

Derek: Right.

Clayton: I think it’s one thing for a team to be principled, and have certain values to say, “We want to be technically excellent,” or something, and that means that we’re going to really value test driven development. Or, “We really care about testing,” or something like that. I think that’s fine to have standards like that, because I don’t think those are so much like rule standards as they the values of the team.

Do you want people in the team to live the values? I think those are a little easier pill to swallow. I am personally a fan of having things more standardized on it at the team level. I think there’s so much time wasted and dumb on purpose stuff that goes on, around people trying to use different things in their little pet project and [inaudible 07:13] work.

Derek: Why is it OK at the team level but not at the org. level, or at the company level?

Jade: I think that at the org. or company level, the values or the influence those have, I think those just get more and more abstract.

Clayton: Yeah, they’re too far removed from the problem that’s being solved.

Jade: Yeah, I think if you were to say, “We have to use Java for everything,” that might not be the right thing for everything. If your biggest problem is that you have people that work for you, that can’t work on your Java project, and then go work on the Ruby project, you don’t want those people working for you, right? You’re not losing efficiency because there are two languages.

Derek: Why would I not want the expert? Why would I not want the guy that wrote Java to work for me, and he doesn’t want to work on Ruby. He’s got 20 years invested in that. He is the absolute best person ever at that.

Jade: Right, but you’re going to get the person that’s the best person at Java, but that’s not really where you’re going to get value out of using some particular technology. It’s not like if you took that person that’s a 20 year Java expert, that’s all they’ve ever done, and you put them on some project, they’re going to instantly make it better.

Derek: But what if I believe that the person that knows 20 years’ worth of Java is better than the person who knows six months’ worth of Ruby? To me, even though Java might not be the right tool for the job, this guy knows so much about Java. This girl knows so much about Java, that they’re going to do it better anyways, a better tool to do it, just because they’re more experienced.

Roy: I would challenge your beliefs and say that maybe your beliefs are wrong.

Clayton: I don’t doubt that that’s possible. I think if you took someone who’s an expert chef and you give them a bunch of crappy ingredients, and a crappy situation, they could pull it off, because they have that expertise, and they have all that stuff. I think that’s fine, but I would question how frequently that scenario comes up, where the biggest gain you get would be out of having the [inaudible 09:01] expert.

Derek: I only hired experts clay.

Clayton: Yeah, and I think a lot of people have that mindset, where they think they only hired the best people. Most of the people that I’ve talked to that think that they hired the best people, they really can never tell who the 10 times programmers are, anyway. I think that they’re chasing unicorns at that point.

Derek: The unicorns that they do find tend not to actually be the best people, in my experience.

Derek: Let’s say it’s not language. Let’s say it’s desktop operating system, or let’s say it’s server operating system. You name it.

Jade: I think it comes down to conventions are very handy things to have. It’s when they become policies that it can become inflexible, and ruin some of your creativity, and your ability to adapt to the situation at hand.

Derek: I think for me, where I get uncomfortable is the minute that somebody says, “We can’t do that because…and the answer is…”

Jade: The policy blah, blah, blah.

Derek: Or some standardization. “We can’t do that because Windows Server doesn’t do that.” Or, “We can’t do that because Ubuntu doesn’t do that,” or, “We can’t do that, because Apache won’t do that.” “We can’t do that…” The minute that I hear that it’s, “OK, so you’re not willing to innovate.” You were willing to sacrifice being able to do something you can’t do right now that somebody wants you to do, to hold on to some standard.

Roy: I think a team can have standards for itself. Why a team and why not an organization? I think a team can have standards for itself, because it is being held responsible for the problem that it’s trying to solve, and everybody is present. If they want to change the standard, they can do so expeditiously. An organization cannot, because they’re solving a whole bunch of different problems, and they can’t dictate a universal solution for all of them, and they’re not being held responsible for any of them.

Derek: But are they being held responsible? Meaning what if the team goes away and the organization still has to support that? You’ve got a team of four people, they did go off on this path and they do something completely non-standard, and it’s really awesome, and it solves the customer’s problem, and it’s really great. Then all four of them get pissed off about something or they get some great new job or they get hit by a bus.

Jade: They win the lottery.

Derek: Yeah, they win the lottery pool.

Jade: That’s the HR term.

Derek: Now you’ve got to have somebody else go support that.

Clayton: I think that’s the risk, that’s the trade-off. You can have the policies where you say, “Oh, we can’t do that because you can have that scenario,” or I think you can have that other extreme, which is, everyone can do whatever the hell they want, and there are trade-offs to both of those.

Jade: Does this come back to the inherent tension between creativity and efficiency?

Derek: Yeah. For me, I always like to explain it. I think there’s a slider button. One polar opposite is innovation or creativity, and I think that’s rooted largely in chaos. Then, if you slide the button all the way the other way, you’re basically in efficiency, which is usually rooted in standardization, policy control. I think you can slide that bar any level you want to find the balance, but what I tend to find is organizations have trouble setting that bar.

They either want to slide it all the way to the right, or they want to slide it all the way to the left.

Clayton: Usually always left.

Derek: The teams underneath, want to adjust it somewhere else. Where I think if organizations said, “We’ve got a scale of one to ten, and we’re going to say between one and three is acceptable,” or, “four and six is acceptable,” or “seven and nine is acceptable,” and then let the teams underneath them, or the organizations underneath them fine tune it for them. I think they’d get a lot better results, but instead I think it’s just this constant tension of team versus org, versus big company.

Jade: I think mature teams will have the slider closer towards the standards for most things, but when they know they could get some benefit out of being more creative or chaotic, they move the slider that way. I think teams get into a lot of trouble, immature teams especially, where they move the slider to the creative side, for the sake of being creative. It’s like “We’re going to do this thing that we could do already using the things we know, but we’re going to do it in this whole new thing that nobody knows we have to support, blah, blah, blah…” That might not be around in six months, just because it’s a cool new thing. I think that’s pretty stupid. That’s dangerous.

Derek: Right, well there’s safety in chaos, because nobody can hold us to the fire.

Jade: That’s true.

Derek: If there is no standard, nobody can say you’re doing it wrong. I think there’s a lot of immature teams that want to jump into that. It’s the classic early-adopter of technology. You probably don’t want to be bleeding edge, to the point where you’re spending all your time trying to get your technology to work. But at the same time, you don’t want to be a laggard, or a late-adopter to the point where you never get any benefit.

You want to be riding that wave right at the top of the crest where you’re probably one of the first people adopting it, but you’re adopting it just at the point where it’s mature enough that you’re having to tweak it a little bit, but you’re not spending all your time tweaking it. That’s such a hard sweet spot to find.

Jade: It’s the hardest place to stay.

Roy: But I think a mature team is really focused on delivering value, so they will try to find that sweet spot on their own.

Jade: The best people I’ve worked with are very situationally aware. They know when is the right time to move that dial. It’s not even on a whole project. It might be in this particular situation. When’s the right time to be a little bit riskier, when’s the right time to be a little more stable.

Clayton: Stick with what you know.

Derek: The blog post that’s coming in my mind right here is the big wave riders. These are the guys that go out there and they’ll sit, and they’ll paddle, and they’ll wait. People are like, “Man, that person’s dumb, they’re not taking any waves.” But then magically, they go right when the best wave of the day comes in, and they ride it in, and everyone’s like, “Oh, man! That’s so incredible! Did you see how incredible that is?”

It’s totally crazy for them. I think that really good people know every so often, you have to be patient, but when the right wave comes, you better paddle like hell to get on it, because it’s the thing that’s going to throw you above everybody else.

If you just sit there forever and don’t ride a wave, you’re screwed. But if you ride every wave, you’re going to be tired before the wave that comes that really matters hits. I think that’s just hard. In big companies especially, that’s hard because that takes serendipity to be able to jump.

Jade: Little companies as well. You might die before the big wave comes.

Derek: Or if you get on the wrong one. But individually it takes practice. You’ve got to fail a lot before you can learn.

Jade: You’ve got to know how to sense the wave.

Derek: When the big wave comes, you’ve got to know how to deal with it.

Jade: You’ve got to have the skills to ride it. On that interesting metaphor. Let’s wrap this up. Thanks for listening. Catch you next week.

Derek: Thanks.