7 Agile Best Practices that You Don’t Need to Follow

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich.

Derek Neighbors: I’m Derek Neighbors.

Roy vandeWater: I’m Roy vandeWater.

1. Test Driven Development

Clayton: Today, we will be talking about the much talked about Seven Agile Best Practices That You Don’t Necessarily Need To Do article. If you haven’t read it, it’s on the Agile DZone. It’s called Seven Agile Best Practices That You Don’t Need To Follow by Jim Bird.

We’re going to talk a few minutes on each of these. First one is test‑driven development. That’s one that somehow became synonymous with Agile teams, that Agile teams do TDD. What do you guys think? Do you have to do TDD?

Derek: No.

Roy: Yeah, I’m going to say that.

Clayton: [laughs] Next. Let’s explore a little bit why that became so pervasive. Why does everyone thing that you have to do TDD if you’re doing Agile?

Derek: Because there is a difference between Agile and good. So it’s like if you want to be good, you have to do TDD. If you just want to be Agile, like, “Hey, you don’t need to do TDD.”

Roy: Also, there’s a huge feedback component to Agile, right? It’s all about quick iterations and getting feedback early. I think test driven development is the programming embodiment of that. It’s the idea of asking for feedback before you even start coding and then, gaining feedback as you code towards the failing test.

Clayton: Do you think it would be fair to say that you would have to do TDD if you were doing extreme programming?

Roy: Yeah.

Derek: Yes. I would say you would. I don’t remember his full arguments on this, but I think it comes down to studies say TDD is not as good. If you know what you’re doing, then TDD is good, but if you don’t know. The only time that I really say that TDD should be super optional would be if your start‑up, you’ve got a limited amount of money and you have to meet the next date and slow at TDD because you don’t know how to do it.

If you are competent with TDD, there is no reason not to do it. If you are going to be long‑term with a project, then there’s no reason not to do it.

Roy: So part of the argument also talks about that statistically there’s an increase in complexity with TDD, oftentimes in terms of design, which I’d have to make assumptions, but I’m assuming it’s based off of probably not knowing how to do TDD properly, like abusing the crap out of mocks and spies and all of those patterns, and creating tests that are really brutally coupled to the specific implementation.

Derek: It doubles the lines of code, so therefore, it’s got to be twice as complex.

Roy: Right, when people, when teams get…

2. Pair Programming

Clayton: Speaking of doubling, pair programming. Do you have to have two people working, do you have to do pairing if you’re on an Agile team?

Roy: No. I feel like you have to be doing some form of pairing, like it may not necessarily be pair programming. But like people working by themselves, that’s not a team. Like leave Agile alone. Like I feel like a bunch of people working by themselves in isolation is not a team. So I almost feel like there has to be a pairing component in terms of like pair‑planning or pair design or pair…

[crosstalk]

Clayton: So the only way you can do that is by pairing?

Roy: No. I suppose not. And I suppose they very specifically mean pair programming.

Derek: Yeah, because I go to a whole lot of planning meetings that aren’t paired but I think that the people there are co‑creating solutions together.

Roy: Sure.

Derek: Again that’s one to me just like TDDing. If you want to be good, you probably should pair. If you want to be Agile, you don’t have to pair.

Roy: Right. Some of the arguments are for the idea like, that some people don’t like to pair and some people will be slowed down by other people like that.

If I’m really good and Clayton sucks, [sarcastic] using a realistic example, [laughing] then what we would have is like Clayton would be slowing me down all of the time, which I think is kind of the wrong way to think of that, it’s like I’d be teaching Clayton some awesome new stuff that he doesn’t know yet… [crosstalk] …and that’s more important in the long run.

Clayton: They hit on or he hits on some of other common arguments about introverts versus extroverts and like smashing creativity and you won’t have time to be innovative and all that kind of thing.

Roy: Like you won’t have the opportunity to go heads down and really solve complex problems but arguably, if you’re pairing properly, you’re turning all your complex problems into simple ones and you don’t end up with those types of huge complex Rube Goldberg solutions.

Derek: I keep saying that you know the problem with exercising for me is that it leaves less time for eating ice cream and clearly this is a problem.

3. Emerging Design & Using Metaphors

Clayton: OK the next one is emerging design and metaphor. One thing I don’t think a lot of people especially kind of the new Agile crowd I don’t think they really have embraced metaphor at all. I don’t ever hear people talking about the importance of metaphor not now at least.

Derek: So I can’t speak without using metaphors, like I think you have to have metaphors to be Agile.

[crosstalk]

Roy: They have to be sports metaphors.

Derek: Not always but usually, just because sexual ones aren’t very you know reasonable to do at work. I will remember a conversation with Chet, I believe about this, and I think they kind of said that XP dropped the metaphor at some point, and I want to say that the reason they dropped it is because it’s too fucking hard to do. Which speaks volumes for the shit that’s really good is hard to do. I think that people throw away the stuff that’s hard to do first.

Clayton: Like BDD. If you look at that, and you talk about “Let’s have ubiquitous language, and let’s have a shared language.” That’s really difficult. And there are a lot of times where people can’t even think of a way to describe some part of the system, so they just throw it away. [crosstalk] They give it up.

Roy: Exactly. You almost put it in the box of the metaphor: “Well this doesn’t fit our metaphor, so I guess we can’t do it.”

Clayton: Right. One thing that he talks about in the article is changing the metaphor, or having to get rid of it, or being pigeonholed by it. If the metaphor is meaningful, I think you can make it work most of the time. If you need to change it, I think you can have a good reason to change it.

Roy: It’s interesting to pair this up with emergent design because I don’t necessarily put those two in the same box in my head. Emergent design, the idea being “I’m not going to design this entire thing up front. I’m going to be able to build on top of it as it goes on.”

Clayton: Then that’s some of the fallacy that in Agile you never talk about design. This is, in practice, not true. I think if you go to high‑performing Agile teams, they’re talking a lot about design. They just don’t do the huge design up front stuff. But, they don’t not talk about it.

Roy: And, it stays flexible the entire time, so nobody’s totally stuck on a particular interpretation…

Derek: [sarcastically] How are you going to grow your architecture e‑peen if you have emergent design? Now, come on.

Clayton: There you go.

[crosstalk]

Derek: I want to back on this one a little bit. Look at some of the most prolific onboarding applications of computer history. If you look at Twitter, if you look at Facebook, if you look at some of these companies that have gone from zero users to several hundred million users in a very short period of time, all of their architecture was created using emergent design from a standpoint of they didn’t know what they didn’t know.

I believe there’s an article on this. We’ll try to see if we can get it in the show notes. Twitter had done a ton of performance testing. They had done a ton of load. They had done a ton of stuff where they could deal with literally hundreds of thousands of follows per second happening on the system. What do you know? Ashton Kutcher goes on “David Letterman” and says, “I want to be the first person to a million followers. Everybody go follow me right now.”

Total edge case in, “Yes, we support a hundred thousand users following another user, but we don’t support a hundred thousand people following the same user in a one second time frame.”

How do you deal with those things that come up? You can’t cover every edge case, and I think continuous deployment has moved us to a point where what you’re really doing is saying, “We discover by the feedback the system gets us.” And, we’re able to adapt and deploy so continuously and so quickly, that it doesn’t feel like we have architecture problems. I think this is something that the old‑school, old guard just can’t deal with. It’s like, “No, but we have to get it right the first time!”

Roy: I kind of feel like if you don’t have some form of emergent design you are, by definition, not doing Agile.

Derek: You’re screwed!

Roy: Right? Because, other than the human relationship and that component of it, I feel like the ability to pivot and change your mind as you gain new information is the fundamental core.

4. Daily Stand-ups

Clayton: What about daily stand‑ups? Roy, you just mentioned the human component. Getting together and talking to other people on the team on a daily basis. Is that something you have to do?

Derek: Is that what they said? I don’t know the wording. To me, if they said “daily stand‑ups,” no, I don’t think daily stand‑ups are mandatory. Do I think the people on the team need to talk to each other at least one time throughout the day? Yes. I think that is necessary.

Clayton: To really nit‑pick, I think what they’re really getting at is, “Does everyone have to stand up?”

Roy: We didn’t. We did an entire episode on whether or not you should stand up during a stand‑up. We came to determine that yes, you should.

Derek: I think it goes back to “Do you want to be good, or do you want to be Agile?” I think you could be totally Agile without doing any kind of formal stand‑up. I think if you want to be good, it’s just like using a white board versus using a tool. Can you do things without using white board? Sure. But, you get some benefits from the other one that you don’t.

Roy: I’m guessing that part of this is driven through experiencing bad stand‑ups that are a waste of your time. Because just like any other meeting, you can screw this one up, and make it a total waste of everyone’s time. Where it’s just like a status report, and I go, “Yesterday, I did X, today I’m going to do Y, no blockers.” Nobody is listening to each other. You’re totally defeating the purpose.

Derek: I see another one too with a lot of teams that are co‑located and within the zone proximity. “We sit next to each other all day long and we pair, so why do we need a stand up? We’ve got a physical board. We sit next to each other. We talk to each other every day. Everybody already knows what everybody is doing. Why the hell do we need to do a stand up every day?”

Clayton: I think what’s funny is that most the time those people don’t actually know what is happening.

Derek: No, they don’t. I see that too.

5. Collective Code Ownership

Clayton: Speaking of everybody knowing everything, what about collective code ownership? Is the idea that everyone can work on any part of the system and everybody knows the system to some degree? Is that a reasonable thing? Or should you say, “It’s OK that Derek doesn’t know how to do this right.”

Derek: Some people are too dumb to work on parts of the system.

Roy: Right, they shouldn’t be allowed to work on parts of the system.

Derek: People won’t say that, but that’s what they’re saying when they say that. “Not everybody is as knowledgeable, not everybody is a god like me.”

Roy: Actually this article does say something specifically along those lines and not everybody should be allowed to modify parts of the system.

Clayton: I think what they’re getting at is it’s not realistic that that is the case. It isn’t realistic that everybody on the team can work on any part of the system. To me that sounds like, why is your system so complex?

Derek: What it sounds to me is why do you hire stupid fucking people? If you have people that you hired to code and you don’t let them go to certain parts of the code because they’re not competent to go to the code, why are they employed by you?

Clayton: That’s a good point.

Roy: Or if you don’t let them go into the code because the person that owns that code is extremely territorial over it, then why do you have that territorial person employed, and why are you letting them boss you around?

Derek: I don’t know if you could be Agile without having collective code ownership. The first time you have to say, “Sorry, Clayton is on vacation, I can’t really deal with this problem.” By default, you are not able to respond.

6. Writing All Requirements As User Stories

Clayton: That’s true. You couldn’t respond to that change right?

We’ve heard that user stories are a representation of a conversation. Why wouldn’t you write every requirement as a user story? Is it un‑Agile to have a requirement on the system that isn’t a user story?

Derek: This one I think they’re pretty in line with. I think that the multiple formulas that exist out there are really good. I think they help people write good, small parts of the system. I think somebody could go write one or two sentences on a board and still get stuff done just fine, if you have the conversation. I think the actual card and the conversation are far more important than the stories themselves.

Roy: One of the values of a user story is that it can’t give you enough information to substitute for a conversation. I can’t write a user story that tells you everything you need to know, so you have to come talk to me.

Clayton: They talk about using a use case, or a test case, or a wire frame, or something which they are great examples of things you can add on to a user story as you have that conversation, but I don’t think it’s an and/or. If you were to say that you didn’t write everything in user stories, I could see somebody getting a little crazy with writing too many use cases, and then you go off the deep end in that regard.

Roy: Right, and then before you know it you have a full spec outline ahead of time so that we don’t have to spend this entire time arguing with the developers and negotiating someone’s criteria.

Derek: You get off the rails pretty quick, right? If you don’t keep it nice and short then we start assume, “Oh Roy, you’ve got 80 pages of Cucumber specs for me.” So I don’t need to actually ask anything about the system.

Roy: It’s all here.

Derek: Clearly you’ve thought of everything, right?

7. Relying On a Product Owner

Clayton: The last one talks about relying a product owner. The single ringable neck and having one person that is supposed to be the gateway to the customer. If most Agile shops are doing some form of Agile are probably doing Scrum and they probably have a product owner. How did all the Agile people miss the boat on this one?

Roy: I kind of think it would be OK if there was more than one product owner. It doesn’t necessarily have to be a product owner as long as there is just one backlog. You still get into the problem of if you have this one backlog and you have two different people that are both your boss.

They’re arguing over what a specific story is supposed to be like. I can still see a ton of problems there. You have to have somebody that makes the final call. Somebody at the top of your organization has the authority to say this and not that.

Clayton: I think there’s a distinction between being the voice, the single point of contact with a customer and the person that makes decisions. Should the only person that ever talks to customers be one person and the product owner?

Probably not, and you should probably find lots of different ways to have that interaction and get that feedback. If you had more people talking to the customer and more people making decisions, I don’t think that’s what you would want.

Derek: This one is really odd for me in the sense of I’m starting to find that actually in some ways I believe that having a product owner is non Agile. Part of it is, I think that if a team, when I look at small startups and I see them do things with no product owner.

They really are doing things by committee. They really are doing things by unanimous decision. I think it’s because they have got strong vision, and they’re aligned. To me the need of having a product owner who is the one all that says, “I’m going to make the decisions so we can move forward.”

I think that’s almost a crutch that says that you’re not providing enough vision that the team is actually aligned behind the product, because if they were, you could get to a unanimous decision fairly quickly. You could be biased towards that action.

Roy: That’s a really interesting point. I hadn’t thought about it like that. The reason why we always think that you need a product owner is because you have dissenting viewpoints on which way to go.

That’s because tradition decision making is made by majority vote, in which case you have a bunch of people that aren’t happy. If you’re always unanimous, then you have a team that is acting as one anyway so it’s like it’s one single [inaudible 00:16:15] .

Derek: You probably have a much better product. To be clear, I think product ownership is very necessary is most organizations because they’re having to deal with them as a dysfunction to how they currently work. I think you could absolutely be on a highly Agile, adaptive, high performing team, and deliver great product, and not have a product owner.

Clayton: I think we’re out of time. Thanks guys!