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.

[crosstalk]

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’s “Team 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