Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Roy van de Water discuss:

• What is more important, principles or practices?

Transcript

Jade Meskill:  Hello welcome to another episode of Agile weekly podcast. I am Jade Meskill.

Roy van de Water:  I am Roy van de Water.

Derek Neighbors:  I am Derek Neighbors.

Clayton Lengel‑Zigich:  I am Clayton Lengel‑Zigich.

Jade:  Guys, I wanted to talk today on what is more important, principles or practices?

Roy:  Explain?

Derek:  Or use it in a sentence.

[laughter]

Jade:  What is more important, principles or practices? Dealing with a lot of teams, I’ve seen Agile presented in many different ways.

Sometimes it is very process focused and practice focused, sometimes it’s about the principles without a lot of either prescriptive ideas of how process or practices would work like how do you get the best results from a team? What’s more important focusing on the principles or focusing on the practices?

Derek:  This is a faith versus works question ‑‑ and loaded.

Jade:  It sure is.

Clayton:  I view myself as a principles kind of guy. In this context, the practices are something that you could do probably quick, but for them to have long‑lasting impact or to make more sense so people understand why they might be doing these practices, you do need the principles.

To answer your question, you need both of them.

Jade:  It depends. Is that right? [laughs]

Roy:  Yes. It depends on the level of team you’re applying them to. It is extremely important to have principles from the very beginning. If you rely only on principles, it’s very difficult for novices to be able to do much with raw principles.

If I say, “Lying is bad. Don’t lie.” But you have no experience with what lying even is. Is a white lie OK? ‑‑ all of these nuanced things. You might be able to say, ”I know lying’s bad, but I got put in this situation. I don’t know what to do with it.”

I do the wrong thing even though I have the principle, because I don’t understand how the principle works. I tend to find that principles are very short, concrete things that have a lot of nuance.

The only way to develop the skill of what is in that nuance is to have a whole lot of practice. With novices, it’s very important to put the guide rails on. To say like do this thing, almost cargo cult it to a certain degree like do this thing, but reinforce the principle behind why you’re doing that thing.

Once you understand the classic Miyagi’s son like wax the car, wax on, wax off. I don’t know why I’m waxing on. I don’t know why I wax off. I don’t know why I’m painting the fence. It seems kind of frustrating.

You tell me that I’m going to be this really great karate fighter someday but I don’t get it because it doesn’t make a whole lot of sense. Then at that one moment that you know that I have enough practice under my boat, you can show me how it relates to the principle in a meaningful way and it kind of clicks.

From that point forward, I can let the practice be more dynamic to the situation. I think a lot of it depends of what level you’re at. It’s very difficult to teach principles without introducing some form of practice. It’s very dangerous to only focus on practice and not have people understand the principles behind the practices.

Jade:  It sounds to me like you’re describing a balance or attention between those two. How do you know when is the right…what’s the right balance for the right team? How do you gauge that?

Derek:  Let me give you the answer that will work for everybody. I don’t have it.

[laughter]

Derek:  That’s going to be something that is worn out of experience, but that’s the troubles. You don’t have the experience to make that call yet.

Jade:  If you’re a coach or you’re a score master, you’re performing some role with that team and expected to guide them in some way. How do you figure out where to push and where to pull?

Derek:  One of the metrics that we’ve used is kind of what we have mentioned in the past. We’ve always said like a team should always insist on pairing on production code. We’d be prescriptive to say that all code is paired.

As soon as you stop getting pushed back from the team when they are insisting that all coach to be prepared and they want to do it that way. It’s like when they’re ready to start breaking the rules.

It’s when they don’t want to break the rules anymore is an indicator that they may be mature enough to start thinking about the rules.

Clayton:  In that example…I had this exact scenario where there was some problem with the team where some people maybe new something about the system or someone broke something about the system and never understood. The principle there might be collective code ownership. You can’t just say that and say “OK, you now collectively own the code.”

Jade:  We all own the code, what are you talking about?

Clayton:  Yes, exactly. It’s just that doesn’t make sense. I think pretty easy go to like a great way to get that, to apply that principle is pair‑programming.

That’s a practice. The way that I’ve seen pairing and to be introduced without the principles behind it, if the people in the team aren’t very open to try new things or maybe change in the way they work or not used to that sort of thing then they want to throw it away.

I feel once they throw their practices away even if you come back with the principle and say, “No, you don’t understand. See this is why we’re doing this.” It’s kind of like, “Yeah I don’t want to do that anymore.”

Roy:  Right. That worked for Danielson in the movies but that doesn’t work so well in real life.

Derek:  Like a good example, I saw even though this is weak in some interactions, pairing is good in all but we don’t feel a need to pair on the easy stuff.

It’s like that’s an easy trap to fall into. It’s not that hard so why are you pairing? We were pairing because when we’re doing hard stuff we want more than one person because two minds are better than one.

I don’t anywhere see kind of the two minds are better than one. Maybe in doing things in teams but sort of that I am not seeing the technical practice as of two people is better as one is like an over‑arching principle per say.

I think doing working teams is kind of is. Maybe there’s a false in that a bit but my question would be is it about everybody owning the code.

In which case shouldn’t everybody own the simple code too? If we start to look at what does automation look like?

If it’s so simple that anybody can do it could you automate it? I think it starts when you have a little bit more depth into the principle of like why do we pair? We pair because we want to work in teams and we pair because we want collective code ownership, we pair because and you list off five or six principals.

Then when somebody says, “Hey I don’t want to pair on the hard stuff.” It’s like, “OK.” Well maybe that solves the “We do difficult work in small teams.” Maybe that applies but then how do we still have collective code ownership if we’re doing that.

I think its understanding that there is depth to principles. It’s not one practice aligned to a single principle more often than not it’s a practice might aligned to three or four different principles. When people try to tweak them, it’s like, “Well I’m tweaking at this because I don’t really…”

Tweaking it this way doesn’t invalidate that principle but it might invalidate some other principle. I think that’s why it’s important to know those.

I think that when people know them that’s why they don’t want to throw their practices away because they know they are getting more than just the surface bang for the buck.

Jade:  How do you get teams to understand that?

We’ve seen a lot. We’ve seen a lot of people reject a lot of practices that we know are good for them but they don’t understand it yet.

Derek:  I think sometimes you have to…I don’t want to say enforce them to do the practice, but I think you have to strongly encourage them to do the practice for some length of time so that they can start to see the benefits and start to see the depth of it.

When they throw them away they come back to them because they realize what their losing. If I’m pairing all the time and I get all the benefits of pairing all the time. I decide to lax out and not pair on the hard stuff or not pair. I start to get bit by bit those other things and somebody from an outside view point can say, “Man it doesn’t look like this is working out so well for you.”

Then somebody’s like, “Oh well, that’s because so and so did that in the corner and blah blab and I didn’t like the way they implement it.”

It’s like, “How come you didn’t know the way they implemented it?” “We don’t pair on the hard stuff.” “Oh.” “In the easy stuff.” “Oh.” Tell me more about that right?

It gets to be able to re‑frame that but if you say, “I don’t like paring so I’m not going to pair.” You never are going to understand the values of the principles for that practice.

Clayton:  There’s a lot to be said for having the ability and I think a lot of it comes from experience to be able to identify some particular patters or problems that the team might be having and say, “OK, well he’s pairing again.”

If the team were doing more pairing this would be less of a problem or it would help them come to a better solution on their own.

Having that experience to be able to suggest those things and having a time boxed length of time that people could try new things. I think that goes a long way. I don’t know how that works with principles though.

Roy:  You can’t time box principles forever?

Clayton:  Well I think they are so abstract, they are too high level.

Roy:  We were going to have collective code ownership for the next two weeks and then maybe we won’t collectively own the program anymore.

Clayton:  Yeah, but that feels wired right?

Roy:  Right

Jade:  What happens if you only see the practices and you don’t understand the philosophy that is driving those things?

Clayton:  At a certain point you probably start cargo‑culting and if you don’t understand the philosophy.

I don’t know any off the top of my head, but there are times where there practices that frequently work towards a particular philosophy or principle will work against it when applied incorrectly. We see that all the time when you throw out the baby with the bath water.

Derek:  I don’t know if I fully agree with that. More often than not even when people do a fair amount of cargo culting their still way better off than they were doing nothing or doing what they were before.

What you tend to see is you either see a plateau. If I cargo‑cult something like a stand‑up or something, it’s still way better that I spend 10 minutes talking with the team rather than never ever talking to the team.

I’m going to hit a plateau that only takes me…I only get so much benefit for that and then it flattens off. It feels like I might be doing more damage even though in reality it’s still better than it was, or what you’ll see is you’ll see practices get abandoned fairly quick because they don’t understand the benefit or the reasons for it.

Jade:  We’ve dealt with some teams recently that have adopted many of the surface‑level “Agile practices” but are lacking in the philosophy of that. Agile has become their weapon to use against other people who want things from them.

Derek:  I think that’s a good example of when you don’t understand the principles you can’t introspect. You can’t have self‑awareness about how effectively you are using them. You can’t improve those things. That’s a big thing.

If it’s only a practice that you know or you only know the practice, then it’s only going to take you so far. You can’t ever look and say, “The principle of why I’m doing this is to achieve some end goal or end state or whatever other philosophy.” How could I change my practice or improve my practice or alter it somehow and have a different…? You don’t have that.

Roy:  I think the big thing in the practice is that each of these practices when applied, especially initially, cause some amount of pain.

If you don’t understand the philosophy of what you are trying to accomplish with the practice, you start altering the practice and minimize the pain. You bastardize the practice to a form where it no longer delivers the value that was originally intended.

Derek:  I would say in the example you’re giving that the people having to work with that team or that organization that is adopting those practices are in as much pain as they were before that team adopted those practices. While people could make fun of the practices right now, the reality is people were not happy with the way it worked before those practices came in.

If you went to those teams, they’ve seen some benefit internally to themselves. They’ve seen a lot of detriment to themselves as well, but Roy you’re absolutely right. What happens is they adopt the practices at a base level, a cargo‑culting level. They get a minor bump in a lot of things that they didn’t have before, but it’s really painful.

Then they start to bastardize the practices in ways that violate the principles to reduce the pain. That’s the danger of not having the principles at all. When it gets painful, if you can look back to the principle and say, “Oh, I want to turn the dial back the other direction or change gears in a way that violates the principle,” the principle will tell you, “Don’t do that.”

If you don’t understand the principles at all, you end up with these crazy things. It started off with a stand‑up that looked great, and it turned into this crazy six‑hour meeting three days a week because, whatever was painful.

Clayton:  It reminds a lot. I remember taking calculus and, Roy will probably correct me, but we were doing something with differentials or integrals or something where the example…

Roy:  Because I’m a math whiz?

Clayton:  I don’t know. You know the factorials.

[laughter]

Clayton:  The examples that we did in homework and in the class, we did literally hundreds of these examples. There was always a boat living in a dock. You have to figure out where the path of the boat will be, and then we take the test.

The two things on the test, one was a finance question like price forecasting, and the other one was a physics question. I think everyone was like, “What the fuck?”

Roy:  Where’s the boat?

Clayton:  There’s no boat.

[laughter]

Roy:  I can only do calculus for boats.

Clayton:  Exactly, right?

[laughter]

Clayton:  We did all this stuff where we are practicing this thing. Even the variables turned into features of the boat. Then when it got to, “Wow. You can really apply this to anything,” it’s like, “Well, it doesn’t fit the boat requirement.” I feel like that happens a lot. We didn’t understand the principle of what we were actually trying to do. All we understood was the practice of the boat.

Peer programming, I think a lot of people that do the practice view it as like two coders writing code together side by side with a keyboard or two keyboards.

I think if you understand the principles of maybe why you’re doing that, you can expand that into other things, or maybe there’s not two coders, or maybe there’s people that aren’t doing any code whatsoever but they can still pair on something.

Roy:  Absolutely.

Jade:  Real quick, looking back on your Agile journey, what do you think was most important to you? The principles or the practices?

Clayton:  Like I said at the beginning, I am a principles person by nature, so I would say the principles.

Roy:  I think the principles are what attracted me to it but I think the practices are what kept me going long enough to stick with it.

Derek:  I think it was the opposite for me where I didn’t know about any of the principles before I started the practices. I was very interested, especially with some of the XP practices, where I only knew them by name and a basic idea of how it was supposed to work.

I was very much focused on the how and got very into that. It took me a lot of time before I started caring about the why. I would say the principles over time have become way more important.

Jade:  That’s all the time we have for today. Thanks for listening.

[music]

Announcer 1:  Is there something you’d like to hear in a future episode? Head over to integrumtech.com/podcast where you can suggest a topic or a guest.

Announcer 2:  Looking for an easy way to stay up‑to‑date with the latest news, techniques, and events in the Agile community? Sign up today at agileweekly.com. It’s the best Agile content delivered weekly for free.

Announcer 1:  The Agile Weekly Podcast is brought to you by Integrum Technologies and recorded at Gangplank Studios in Chandler, Arizona. For old episodes, check out integrumtech.com or subscribe on iTunes.

Roy:  Need help with your Agile transition? Have a question and need to phone a friend? Try calling the Agile Hotline. It’s free. Call 866‑244‑8656…