eXtreme Programming (XP) Is Really Hard To Do

Episode 116

August 07, 2013



The Agile Weekly Crew discuss eXtreme Programming. How optimizing for efficiency can kill innovation.

Jade Meskill: Hello, and welcome to another episode of the Agile Weekly Podcast, I’m Jade Meskill.

Derek Neighbors: I’m Derek Neighbors.

Roy vandeWater: And I’m Roy vandeWater.

What Happened to Extreme Programming (XP)

Jade: We were sitting around, trying to decide what to talk about, and the topic of eXtreme Programming came up. Hey Derek, what happened to XP?

Derek: [laughs] I think what we were talking about it is, we were laughing, making fun of some other industrial frameworks and enterprise things.

Roy: With trademarks.

Derek: You can infer what you want to infer, and we were laughing, but we do get a lot of our clients that for right or wrong, call what we do the Integrum right way. I made a comment that I was doing a lot of research on some of the elements of process, and trying to dissect things, and find commonalities, and deep dive into it.

That I was…I don’t want to say appalled, but amazed at how almost identical the Integrum way is to traditional XP in almost every way, shape and form.

Roy: We never claim to be original. [laughs] That’s right.

Derek: Right, which is hilarious, but it’s funny because we don’t sell that really do XP even though we firmly believe in XP. There is no marketability for…

Roy: Right.

Derek: …extreme programming.

Roy: You probably don’t sell the Integrum way either.

Extreme Programming Is Really Hard To Do

Derek: We don’t sell the Integrum way either, right? It’s just part of what we do, but I think the conversation started to diverge into, “Well, yeah, people stopped doing XP because XP is like really fuck hard to do.”

Roy: How much does XP speak about the organization around the actual development team?

Jade: Not much, I mean, it demands on on‑site customer which is very, very difficult to do. It’s even more difficult, I think, than having the product owner from Scrum.

I’ve been talking a lot about XP at the company that I’m working on right now. A lot of the engineers get excited about it, until they actually go to implement it.

It looks really great when you read the book. It’s really easy to get excited about the values and the principles and all those things, but doing it, is very, very difficult.

Agile Our Silos So We Can Keep Our Efficiencies

Derek: When I look at it, I mean, I think one of the things I find interesting is, I think, XP tends to say, “Stop the silos and everything you need to be successful, pull that into your team,” which, I think, honestly is probably the most scalable way to think about the world. I think what happens is all of these enterprise frameworks that are coming out, for lack of better word, or the agile scaling frameworks. What they try to do is say, “How do we build our silos back up in an agile way”?

We’ve got these independent agile teams that are doing things, but we are not allowing them to actually deliver things end‑to‑end. When we put some sort of ceiling or some roof on them where they have to interface back with the organization, which generally becomes the limiter that stops them from actually being hyper‑forming and it’s says like, “We need to have all those control valves to deal with it.”

Where, I think, maybe more of the XP way and I certainly don’t want address it, so I’m projecting here. But, I think, they’re kind of saying, “Hey, if you’ve got your customer and everything is self contained. It’s almost like every team is its own start‑up.”

I think if you look at what’s most scalable, that is probably the most scalable to do high performance. It might not be the most scalable for, “I want everything to be uniform. I want the most efficiency.”

That’s the problem. Big companies want efficiency, so they’re like, “Well, you want to implement Scrum the same way for everybody, so that it’s easy for somebody to go from one team to another team.” They know what they are doing. There is no cost to have to switch. Everybody is doing the same thing. We’re reporting the same way. We are all using the same tool.

Autonomy Leads To Chaos and Rework

Jade: We’re all making sure we’re not accidentally doing rework.

Derek: Right.

Roy: Because I feel like that’s kind of the problem with having a start‑up idea is that you could have one start‑up over here building some minimal viable product from something over here and then have another start‑up all the way across the company doing the exact same thing and essentially wasting resources.

Derek: OK, and the way I look at that is let the free market decide. If you’ve got two or three teams that are all trying to solve a similar problem, they are probably going to solve it slightly different and when they do that, the best one is going to rise to the top.

I think what happens is we get so concerned about, “Well, let’s not waste money allowing three different teams to do it.” That we add so much crap that none of the three teams deliver anything because they are quagmired in, “We have to have the perfect architecture or the perfect answer to this. Or it’s got to be the end all for all three of us.”

When in reality, a small part of it is really the same for all of us, but for the rest of us, it’s not.

Roy: So are we talking about an organization or the head of an organization like the parent entity, or whatever, who really acts more like a venture capitalist…

Derek: Sure.

The Budget Already Belongs To The Group

Roy: …in all of these little sub organizations that essentially get a budget? You have to figure out what they do want to do with it and it’s up to them to figure out the best way that they can add value back to the organization.

Derek: All big enterprises I know already do that. They already have organizational pieces. They already have the ability that they are putting budget by group by something, right?

The only difference is they are trying to squeeze efficiency between groups, or they try to say, “How can we make it so that we can communicate everything to everybody”? It’s unrealistic.


Optimizing for Efficiency, Stifles Innovation

Roy: Is the ironic part that by trying to maximize efficiency, they generate a ton of waste?

Derek: I don’t think they generate a ton of waste as much as they stifle innovation.

Roy: I guess what I mean in terms of waste is the bureaucratic overhead of dealing with the organization hierarchy, so you end up with a ton of middle managers and middle managers between managers and you end up with all of that type of waste that…

Derek: But to them it’s not waste because they are getting the value of being able to know what everybody is doing.

Roy: I see.

Conway’s Law Applies to Software Development

Jade: This is where Conway’s Law starts to play in, right? The software that is developed is a direct reflection of the communication processes over the organization itself, right?

If you have this very complex, very highly controlling, very convoluted communication environment, your software is going to be a direct reflection of that. I think that also plays into the XP principle of self‑similarity.

That was a hard one for me to comprehend for a long time. I had to really think about how self‑similarity really works. It’s based on the same idea, right?

That if you have team that is functioning in this way, it’s going to generate software that functions in this way. If the organization is functioning that way, it’s going to generate teams that work that way.

Team Equals Product

Derek: It’s a classic Jim and Michele McCarthy’sTeam equals Product.” I think that there is so much truism to that, but we don’t want to admit it, right?

Jade: Right.

Roy: Especially as a management team where the product is a development team.

Derek: We want our products to be nimble and light and clean and simple and all of these words, but we build our organizations the exact opposite of the traits that we’re actually looking for. I think I read an article on Medium or one of these.

There are companies trying to do “no management structure,” right?

Jade: Yeah.

Derek: I think there are some other examples. I think this is…

Jade: The whole aristocracy.

Organizational Innovation

Derek: Yeah, I think there’s problems with this stuff. I don’t want to sound too idealistic or like happy‑hippie. I don’t think anybody is saying that it’s the magic pill and that everything works and that people have it done, but I think the next real innovation is going to be organizational innovation.

Meaning we’ve squeezed the crap out of efficiency for technology for the most part. I think our next big wave where we’re going to get real innovation, innovation where we’re going to see like leaps and bounds and technology advancement, not efficiency is going to be when we can figure out how to optimize how we behave as human beings into organizational structure, like work structure.

Jade: How does XP play into that? If we think that the ideas, the core principles and values of XP are fundamental to the way that we work, how do they play into that next revolution of organization?

Revolution In The Organization

Derek: I think some of it is they are just like they were revolutionary and radical ideas for software teams. I think they’re revolutionary and radical ideas for managers and organizations meaning, think about it if you said, “We need to keep all organizations simple.”

A good example of this, to me, would be Netflix’s vacation policy. “Our vacation policy is you can have as much vacation as you want. We don’t really care. Check with your team. Make sure that your team says that you’re providing value and as a team, you guys figure that out. We’re not going to have a policy.”

I’ve seen three and four person companies that will go to war over what their vacation policy is going to be. Which is just, to me, insane, but it’s like that institutional, but like you have to have a policy. There is no way.

We’re not talking a 30,000 person company switching from like, “Well, we’ve got regulation and we’ve got history and we’ve got accrued hours and we can’t just flip the switch and go to this like really simple vacation policy of, ‘Don’t be an idiot. Do what’s right.’”

We’re seeing brand new companies that form that have so much organizational baggage from the people starting those companies. That they are saying, “We can’t do this.”

Roy: I wonder how much of that though is people trying to avoid personal conflict. For example, with their vacation policy and only having a four person organization. If you instill this policy and you break the policy by taking three months of vacation in the year or whatever, now I can point at a policy and it’s not me accusing you.

It’s me pointing to the policy and it’s you versus the policy. Whereas, if you’re being a jerk, but we don’t have an agreement ahead of time, then all of sudden I have to bring it up with you. I have to take responsibility for how I feel.

Jade: I think that plays a lot into it. When we started Integrum, a lot of people who were mentoring me were freaking out because we wouldn’t define those things like vacation policy, like some of things, because we didn’t want policy.

It’s amazing when you create a policy, how everyone becomes a lawyer in the company. I’ve seen it in many different companies that I’ve been in where as soon as the policy comes up, everyone is figuring out the loopholes, the ways around it, all of those things. Where if you don’t have a policy, it does force you to deal it with on a human, person‑to‑person basis.

Hiring People You Don’t Trust

Derek: That’s not scalable. What starts happening is A ‑‑ we don’t trust people, so that might work really well for this little group, but I can’t imagine doing it for…It’s like, “Why are you hiring people you don’t trust”?

This goes back to the core things. To me, when we talk about some of the simplicity, some of this empowerment, some of the self‑organization and self‑direction, you have to get to a point where you have such vulnerability and such courage as a leader and as a manager or an owner or CEO that you just unlock the awesome.

The minute that you take good people and you start to put things around that start to show that you’re not vulnerable or that you’re not trusting, like Jade was saying, they start to build walls around that almost instantly not even knowing. Just like a self‑defense mechanism, it turns into justification.

You cut out all the ability to be the best human being you can be. I think when we can get to a state on teams where we’re cutting through all the crap, and we’re just being the most raw that we can be together as people and not having to deal with all the other crap, we unlock all sorts of potential. But that’s so hard to do.

Roy: Some of that too is that by trusting the people to make the decisions what ends up happening is they probably make better decisions than if you instill the rules on.

Going back to your vacation idea, if you instill a two or three week vacation policy on somebody, they’re going to make sure they use up every single day. But if the rule is “don’t be an asshole,” I would not be surprise if people all of a sudden took one week instead of three or whatever. And I bet that extends way beyond vacation policies.

Derek: Our number one complaint through hundred employees over time, the number one complaint with, say, vacation or lack of vacation policy is “I don’t like this because I don’t know how much time I can take. So I think you guys are being mean to me because you’re trying to get me to not take vacation by not telling me how much vacation I can take,” which to me is just, boom, mind blowing.

How does saying, “Take as much as you is feel necessary and as much as the team can” gets turned around into, “This is an evil Jedi mind trick that’s getting me to not take vacation.”

Jade: We’re not that smart [laughs] .

The Right Amount of Flairs

Roy: There’s an infamous scene from “Office Space” where the guy is like, “You need to have 17 pieces of flairs.” He’s like, “OK. So I need to get 17 pieces of flairs.” He said, “Well, you don’t need 17 pieces of flairs. You just need to have enough.” He’s like, “OK. Well, I think 3 is enough.” He said, “Well, 3 isn’t really enough. We were thinking more like 17,” or whatever.

I think that’s the case in most organizations is I bet people are suspicious and think that there’s a hidden number behind the scenes, and they are just not allowed to know what that number is.

Derek: What’s funny is we even had some people that asked the question. I don’t know. What do you guys see [inaudible 13:09] ? I don’t know. In most places, two or four weeks, but it depends on what your project is. I think we’re pretty open about that. I don’t think we were saying, “Well, we’re not going to tell you what the magic number is.”

Jade: Or we’ll get mad if you go over the secret number.

Roy: Right, exactly. We have secret meetings about the fact that you went over, and when you come back from vacation, your ass is fired.

Derek: [laughs] What’s crazy is we would have some people that would take a little more vacation, and you’d have other people almost get mad at them. It’s like, “They’re following the same thing that you’re following. You just have [inaudible 13:40] hang up that you don’t want to do it.”

Roy: Although them getting mad is how the system self‑corrects too. If somebody’s obviously abusing the system, then everybody else gets mad. That’s how you deal with that organizationally.

The Zen Of Extreme Programming, Value Is What You Like

Derek: I think that it’s just difficult for people to do. I think when I look at the XP stuff, the reason XP stuff is so hard is because it is so, so simple and so liberating. It’s like Zen.

If you listen to us, Ron…I love our conversation about value and argument, and as much as it sucks to say, “Value is what you like,” at the end of the day, that’s what value is.

It seems too simplistic and too easy and too raw, but I think that’s how a lot of these things tend to be. If you break them down to their bare essence and be human and be simple about it, then you get pretty tremendous results.

Jade: I remember the first time I came across XP in the late ’90s, I saw it, and I said, “This will never work. This is insane.” We just couldn’t apply it. I was working at a small place that had a very tight‑knit team.

Roy: I was still in elementary school.

Jade: Shut up.


Jade: And still rejected it. Because it is. It’s beautifully simple, but very, very hard to live by.

And on that note, thanks for listening to the Agile Weekly Podcast. We’ll catch you next week.

Roy: Goodbye.

Related episodes