047: Communicating Across Boundaries with Declan Whelan

Panelists:

Janelle Klein | Sam Livingston-Gray | Jessica Kerr | Coraline Ada Ehmke

Guest Starring:

Declan Whelan: @dwhelan | Leanintuit

Show Notes:

00:16 – Welcome to “I Rolled a Natural 20 For My Agility Check” …we mean, “Greater Than Code!”

01:31 – Background and Superpower; Empathy

09:08 – Cross-Cultural Communication Dynamics

Women in Agile

15:48 – Biases, Understanding Dynamics, and Facilitating as an Ally

21:02 – Being Authentic

25:31 – Is Agile something that you are or something that you do?

35:37 – Adopting Practices Across Teams

A foolish consistency is the hobgoblin of little minds.” – Ralph Waldo Emerson

41:57 – Technical Debt and Technical Health: How do we amplify what we want?

Code Climate

Reflections:

Jessica: Strive for common outcomes; not common practices.

Coraline: Some situations should be taken as a promise for a conversation.

Janelle: Ask for permission.

Sam: Identifying and clarifying outcomes that we want.

Declan: Figure out how you can have effective conversations with your teams.

Want to help make us a weekly show, buy and ship you swag,
and bring us to conferences near you?
Support us via Patreon!

Thank you Declan Whelan for your patronage!

Also, tell your organization to send sponsorship inquiries to mandy@greaterthancode.com.

Are you Greater Than Code?
Submit guest blog posts to mandy@greaterthancode.com

Please leave us a review on iTunes!

Transcript:

JANELLE:  Hi, everyone. I’m Janelle Klein and this is Episode 47 of ‘I Rolled a Natural 20 For My Agility Check’ and I’d like to introduce my fabulous co-host, Sam Livingston-Gray.

SAM:  Why, thank you, Janelle and because you called me fabulous, I will gently point out that this is, in fact Greater Than Code. I am also very pleased to introduce my recent birthday-having friend, Jessica Kerr.

JESSICA:  Thank you, Sam. Yesterday, I got to hold three snakes, a scorpion, a tarantula and an alligator. But today, I get to hang out with you all, especially Coraline Ada Ehmke.

CORALINE:  Hey, everybody. We have a special guest today, Declan Whelan. Declan has been fascinated with technology for a very long time. He hand-soldered his first computer, graduated with the first computer engineering cohort at the University of Waterloo and has been immersed in software ever since. Along the way, he got a new extreme programming in the broader agile movement, where he does coaching, speaking and thought-leadering. Declan is a board member of the Agile Alliance who is particularly proud of co-chairing on agile, the Agile Alliance Online Conference and for helping bring and deliver agile to life. Welcome Declan.

DECLAN:  Hello. Welcome everyone.

CORALINE:  Declan, your bio is very interesting. I’m particularly interested in the fact that you hand-soldered your first computer but what we always like to do when we start out is to get a sense of who you are as a person and we start out by asking, what is your superpower and how did you discover it?

DECLAN:  That’s a really great one. I sort of have this Canadian modesty thing going where I’m thinking, “Do I have any superpowers?” Maybe I have a lot of strong powers, I think and probably one of them would be around empathy. For various reasons, I tend to be quite good at picking up on where people are at in interactions and looking to make outcomes for training and work be more productive because I’d feel I can engage people and meet them where they are.

CORALINE:  You’re Canadian. That’s really interesting. Does that mean you’re going to be answering all the questions in both English and French?

DECLAN:  No, it just means I’ll preface every response with, “I’m sorry, but.”

CORALINE:  Nice. Our fabulous editor will have to edit these ‘sorrys’ out.

DECLAN:  And how thankful I am that we have the prime minister that we do right now.

CORALINE:  I’ll trade you.

SAM:  Yes, please.

DECLAN:  Join the list. You’re about 20 up on that list that had said the same thing. But trying times for sure for everyone.

CORALINE:  Do you think you’re always empathetic person or is that something that you developed over the course of your career?

DECLAN:  Oh, I think it’s something that was in our family. I remember having that as far back as I can remember. I don’t know if that’s innate or whether it was something that was fostered growing up when I was very young but I feel it’s something that I carry with me.

JESSICA:  Interesting. It’s easy for me to see empathy as something that’s fostered. Is there an innate empathetic ability?

SAM:  There’s certainly a lack of it, right? Witness sociopaths?

JESSICA:  That’s true.

CORALINE:  I like to think that empathy isn’t something that you have but something that you do. I think you have to practice empathy and as you practice empathy, you get better at empathy. It has been demonstrated that empathy can be learned.

DECLAN:  Certainly, empathy can be learned although I have not studied it but that makes sense to me. I think it might be, in my case with my family, we weren’t super expressive so to understand and interact with the family, it was a matter of really picking up on a lot of non-visual cues and so on because we were very low conflict family. I think it was a good breeding ground for empathy because you have to read between the lines on a lot of things.

JANELLE:  I had a question here about this because I’m listening to this and we have semantics of words like a word has a certain meaning attached to it. When you talk to different people and they’re describing something they experience and attributing a word to it, I feel like the meaning of what you’re saying is valid in terms of pointing out this quality that is innate. It’s just that empathy has this secondary meaning that it’s more skill-oriented, I think in addition to the innate thing because I’m thinking like my past and I used to be really hyper sensitive to emotional energy in the room. I felt like going around the school, it feel like there were thousand eyeballs on me and I can feel everything.

Then after going through this super tragic experience in my life and getting traumatized and shoving all the stuff down, essentially I spent half my life trying to be who everyone else wanted me to be because I was so focused on what everyone else was thinking that I couldn’t feel myself. Then I made this transition in life where I flipped and I shut all that stuff down so that I couldn’t feel stuff anymore and that innate ability thing kind of went away. But it’s very much attached to empathy. I guess what I’m wondering is if you were to come up with a different words to describe this thing in your experience, what kind of words or definition would you use to describe the thing you’re talking about?

DECLAN:  Maybe in terms of interactions, which is where empathy would clearly show because you’re interacting with people, it would be just being in tune. Being in sync with the dynamics that are going on around me in terms of where people are and what they want to accomplish and reading between the lines, that’s a lot of words. It might not even be ’empathy.’ It’s an interesting point now maybe it’s not quite the right word.

JESSICA:  Declan, you talked about how in your low-conflict family, you are acquired to learn to read between the lines on a lot of things. That’s a great skill to have but can you really ask other people to do that? Is that a good expectation to have for people you work with?

DECLAN:  There are some downsides to that. For example, I find it difficult to be in high conflict situations but when I talk to other people, they say, everyone does so I have no idea. On my meter scale, is it more difficult for me? I think it’s neither good nor bad to some extent. I think it just was the way I was raised. I think a higher level would be having the courage and directness to have open and frank conversations when needed. That’s something that I definitely had to work at, rather than not being sort of anywhere nurtured in my youth.

JESSICA:  Yeah. Those explicit conversations that are open and frank but not aggressive, not attack-y, those are something that we can fall back to because we’re from different cultures and we didn’t all grow up living together all the time. We don’t have to seem interpretations of those subtle cues or lack thereof.

SAM:  Well, there’s a segue here into cross-cultural communication dynamics where as Americans, we value direct forthright communication and we also interact in a very egalitarian way, where we prefer to be called by our first names and other cultures have more highly contextual communication, where somebody will say something that hints at something else and you’re supposed to have all of this context in your head to be able to interpret that comment correctly. Those cultures can often also be more hierarchical, more formal as well. There’s a lot of different axes that this goes along.

JESSICA:  What do you do when you’re not naturally in sync with someone else or with other people on the team?

SAM:  Empathy?

JESSICA:  But that’s totally different from guessing. You don’t guess with people you don’t share a ton of contexts with.

SAM:  Right and that’s why I wanted to point that out. It’s because everybody tends to think that everybody else thinks the way they do right. But as Americans, we are often totally unaware that there are these other layers of conversation going on, especially when we interact with people who did not grow up in our culture. It’s incumbent upon us, as Americans, to be aware that there are different cultural communication styles and try to have, at least some idea first that there are different ones and secondly, what they are and how to adapt your own communication style to deal with that, which is why I said, “Empathy?”

CORALINE:  Declan, have you been into that in your work where you’re working with teams, consisting of people from different cultures and how to adapt a communication style that’s more inclusive of different ways of thinking?

DECLAN:  Oh, yeah, for sure. I think it’s becoming more prevalent. I live in Toronto so it’s a very high multicultural element to the makeup of society. That happens a lot and it can cut, not only on culture lines but gender lines and power status with any organizations. But specifically about culture, for example, where I have the challenges more with cultures that are more direct, where it’s expected to say what you really think. That direct conversation is I find to be somewhat challenging, especially if there’s a lot of people in the room because those people can tend to dominate.

I was a thinking that what I strive to be is just authentic. Just showing up as me and cross culturally, I think people get when you’re being authentic and if people trust you that you don’t have a hidden agenda, that you’re being honest and frank, then I think that really helps cut through a lot of cultural barriers. I am not an expert in this by any stretch but I think, a lot of non-verbal cues tend to be more consistent across cultures.

It doesn’t always work. I noticed when I worked with people from India, they’ll often shake their head, they’ll put their head sideways, going side to side when they mean yes. That’s the signal that they’re following you. It’s a subtle yes. I don’t know if you’ve encountered that. That took a while because they’re saying yes but your brain is seeing no. That can be interesting.

SAM:  Right.

JESSICA:  As Americans, do we have a greater privilege to be ourselves, to express ourselves and be understood because of basically Hollywood. I feel like, especially being from the Midwest, freaking everybody can understand my accent because it’s the accent that’s used in television and movies.

SAM:  Yes, we absolutely benefit from cultural hegemony.

DECLAN:  Especially, I think with English as a first language. To me, English first would be huge. I always have tremendous respect for people that are having deep conversations in their second or third language.

CORALINE:  I grow up with a Swedish and she puns multilingually which is very impressive.

DECLAN:  I have a Swedish friend and he practices by doing my cryptic crosswords in English. I can’t do a cryptic crossword in my own language.

CORALINE:  Sort of go back to talking about with trying to read between the lines, trying to put yourself in someone else’s position and trying to be aware of the power dynamics that are inherent in some languages, how does that relate to the practice of agile methodologies, which are very rigid and very terse, at least in my experience.

DECLAN:  That’s interesting. I wouldn’t have been term them that way. I think maybe because things like stand ups had to be terse. Is that what you mean, Coraline?

CORALINE:  Yeah, in terms of stand ups, where your communication style is very terse but you have very important things to communicate. How can you ensure that you’re being respectful of your audience and also, how can your audience assure you that they’re hearing what you’re saying?

DECLAN:  I actually think of agile as being the opposite. To me, you do have the stand ups but they’re really just nothing of substance of any depth should be happening there. It’s just more of like, what are you doing today, here’s what I’m going to do, what are you going to do and then it’s like, “Oh, we’re having an issue with X. Okay, Well let’s take that off line.” The empathetic conversations are likely to happen outside of that terse event. Maybe we’re into some things like retrospective, which I feel like if we’re going to do one agile practice, it should be about respective. If you’re facilitating retrospectives, which I often do, then you’re really have a responsibility to make sure all of the voices in the room are heard and now, you’re into a wide variety of facilitation techniques. I think agile actually provides for much deeper conversations because things like user story or a promise for a conversation. My experiences that agile done well is actually a very rich dynamic context for interaction.

JESSICA:  I think pairing does that for me.

DECLAN:  Yeah, or mob programming even to a wider extent with teams.

JESSICA:  We talked about trying to be explicit and having room for larger conversations in order to convey across cultures but those cultures, as Janelle and Sam are pointing out in the chat aren’t just the cultures you grow up in. They’re also the cultures you worked in like are you a tester? Are you a manager? Are you frontend developer?

SAM:  Yeah, the classic cross cultural barrier there, of course is tech versus management, which is often very much framed as a versus.

DECLAN:  Yes. What might be interesting is I had the good fortune of agile in 2017. I’m going to an event, which was called Women in Agile. Before the conference, they had a half-day session. They had a keynote, which was sounded awesome. Unfortunately, I missed the keynote and then they had some open space sessions, followed by some lightning talks that were mentor talks. It was really interesting as a man being present there and the dynamic that puts for saving me as the ‘privilege’ one in that context. To some extent, I think there were mirrors with that and the tech management role or the cross cultural one where you sit in a privileged position, you’re working with people that may, for whatever reasons not feel as empowered as you might.

I hosted an open space work session really on how men could become better allies. I think some of those things that emerged from that session would be good insights to human nature that would support, not only gender of diversity but other forms of differences across people.

JESSICA:  What are some of those?

DECLAN:  I guess — and I’m repeating back what I learned — one of them was — and it was sort of an insight to me — just to recognize that we all have biases and to have biases, to be human. It’s not emphatic. It’s just is. If you’re a human, you have biases and being aware as an individual that you may carry those biases. For example, when we started the session, it was named, ‘How men can become better allies,’ and then we quickly change the title, ‘How everyone can become better allies,’ because it was pointed out that some of the biases that I might hold around, say women in technology, women would might have those very same biases. There could well be a societal bias. That was insightful for me to realize that the biases that I carry might actually be shared by others, including the people that I might feel are in a ‘less powerful’ situation here. That was insightful for me to glean that.

But there’s a lots of little things that came up. Some of them just boiled down to good facilitation like have everyone speak as soon as you can in some organized session. Like within the first few minutes, just make sure everyone has had an opportunity to have a voice and to say something with us in a single word or a complete thought and giving room for people to speak soon and early. One that I noticed in the conference, I don’t know if you’ve ever seen this, I ended up being at a table with a woman who I knew quite well and this very nice guy sat between us and then the three of us worked together on this exercise. I noticed that this guy who I didn’t know, would actually direct most of his attention and interest to me and what I was saying, rather than the woman. He had no reason to do that because we were complete strangers to him.

I was aware he was probably making some unconscious bias towards somehow treating me as a more credible voice or something, than the woman. What I would continually do in those as interactions is I would look at her, I would ask her for her opinion. If she said something, I’d say, “Oh, that’s a really good insight. Can you tell us more?” I really try to dial up and try to focus this other individual on the other voice in the room. I think some of this across cultural and perhaps gender diversity is really about being present and watching and understanding, whether dynamic are going and trying to pull other people in and redirect other people to be aware of those other people.

JESSICA:  Because if you’re present in the moment, then you can notice your own bias and that of other people and here’s to direct your attention and to compensate.

SAM:  Like you were talking about you also a modeled the behavior that you wanted to see, which I thought was really interesting.

JESSICA:  It does take extra brain power to do that. Yeah, thanks.

JANELLE:  It seems to go back to the initial point to about empathy and authenticity in creating bridges between people. It seems like you could put the same ideas and principles in terms of the things that you learned with your superpowers. do you have any thoughts with regards to how do you see the skills and things that you brought into the table and how you see yourself using these superpower abilities that you learned? Can you relate those things back together again?

DECLAN:  I’m not sure. I guess I would say, as I got to my career, I don’t know if you’ve experienced this but when I was younger, I would be always tried to be the person that people wanted me to be and I want to be the expert in this or I’m not good at that or whatever it might be. But primarily, it’s about trying to look the way that people are expecting you to behave. What I’ve noticed in my career is that the more truly authentic I can be and pulling those skills in so it’s truly me showing up, then those generally lead to better outcomes.

One thing that I have really learned that has worked really well for me is just asking for permission when unsure. Would you be open to some feedback right about now or would you mind if I jump in on that point because when one challenges an ally, I think often as a male say in gender diversity, “I don’t want to be sticking up for people that are more than happy to stick up for themselves. Thank you very much.” When I feel like the situation demands and I feel like I might want to interject or redirect because of some cultural or diversity, I’ll often find a way to ask permission from that person because ultimately, I’m trying to support them.

JESSICA:  That’s beautiful. That elevates them into a position of respect just by our example. We talk about authenticity but that it’s so abstract. What’s something that you do or say differently when you’re being authentic versus when you’re not?

DECLAN:  That’s a good question. One thing that I find works well for me is to really show vulnerability because I think people put up a facade and if you’re able to show, “I’m quite technical,” and if I screw up with some technical thing like I mistype something or made coding error, I just make a joke of it. “Oh, silly me. Look at that.” You’re showing that I’m not trying to have a facade of being the expert but we’re all human and we just all here doing our best. I think showing vulnerability, to me has been really effective for people to then and say, “It’s okay for me to just be who I am and show up how I choose to show up.” That would be one example of a practical authenticity.

JESSICA:  Okay, so pointing out your own mistakes and not freaking out over them. That’s one example of authenticity and vulnerability?

DECLAN:  Yup. I’m really good at having really bad jokes so I don’t hesitate to have really bad jokes that people grown over and then my lack of humor becomes another joke and it then becomes infectious and people find it, “It’s okay if I say that joke,” and then a lot of barriers are just dropped and people just acted as humans, rather than fulfilling a role that they perceive a need to in the context.

CORALINE:  It seems to me that both of those ways of being authentic are a way of addressing a power imbalance or a power dynamic that you might have. I find that if I’m pairing with someone with less experience than I have, I actually will intentionally make mistakes to prove to them, to show them that I’m not infallible and everyone makes a mistakes and they shouldn’t feel ashamed of making mistakes themselves. I think it’s important to demonstrate that kind of vulnerability, to demonstrate that it’s okay not to know everything and it’s okay to make mistakes and it’s okay to get things wrong and no matter where you are in your career, those things are going to continue to happen to you.

SAM:  It sounds like something that [inaudible] said once where he was talking about when he joins a new team, he will try as quickly as possible to force the team into a failure mode to make something go wrong because he finds that making something presumably small and trivial go wrong is a good way to build trust in each other and in everybody’s abilities to pull themselves back out of that failure.

JESSICA:  Yeah. Being able to deal with failure is so much more important than preventing it.

CORALINE:  Failure is inevitable, right?

JESSICA:  Right, and Declan just pointed out that failure is also a tool.

DECLAN:  Yeah, Coraline. I really resonate with what you’re saying there about showing vulnerability. I must say, I’ve done that too. I have manufactured failures to show vulnerability. I prefer not to force it because people might sense that you’ve actually constructed this scenario. Maybe it’s ironic. I prefer just to be authentic and if something goes wrong, just deal with it in a moment.

Another example that happened to me a while ago, which was interesting. I was working with a management team and I was explaining something to them and they say, “How are we going to do this?” I have no idea, and they were very stunned. “I thought, you were the agile expert?” I said, “No. We’re cutting some new ground here. No one’s ever done exactly what we’re doing so we’re going to figure this out together. I have some ideas but let’s figure this out together.” That’s another way to show vulnerability is you don’t have to have the answers to everything.

JESSICA:  Oh, say, “I don’t know.” Yeah, that is a good example.

DECLAN:  Especially, if you’re in a situation where you’re brought in as an ‘expert.’ Early on in the conversation, you say, “I don’t know,” that I think opens up and models that we’re going to figure this out together.

CORALINE:  It seems to me that this sign of expertise is a willingness to collaborate and learn it and experiment, not expertise being always knowing the answer.

JESSICA:  Yeah, part of our job is to be not afraid to fail.

SAM:  We talked earlier about empathy and the way I put it in the chat was that there’s a verb and a noun. I know, empathize is the verb form or whatever. But as I was trying to sketch out my question, I realized that empathy and ally are both words that people think of not necessarily as nouns but as attributes of a person. Rather than verbs, I think we should push people towards viewing empathy and ally as a behavior. I’m wondering, is the word agile is another one of those that falls into that pattern? Is agile something that you are or something that you do?

DECLAN:  I think a lot of agile where it does not work well is because it is doing in the sense of following the practices and the cargo cult of agile. I’m in the US, I can say ‘agile.’ in Canada of course, I would say ‘agile.’ Certainly, my experience is much more about, maybe it is a lot about mindset in terms of agile, which I do think of as more noun, like present, like the way that you act. But I think going down the superficiality of implementing practice, the acts that would occur in terms of conversations and the way that you plan and interact and pair from that behavioral perspective, I would agree that agile should be more of ‘here’s what we do around here to succeed,’ rather than a set of practices just to distinguish those two different levels of doing, if you see what I mean.

SAM:  Yeah, that makes sense so there’s the behaviors that people think that performing them makes them agile, which are completely distinct from the actual behaviors like learning and adapting to feedback.

JANELLE:  I’m just listening to this and my feathers are ruffling a little bit here because I think one of the problems with agile is the name agile and fundamentally, there’s this idea from a systems thinking level of this emergent behavior that we’re trying to describe of agility. If we are agile, if we do the agile things, then there’s an expectation that these emergence system level properties will un-exist. I see people trying to map this description of the system into a first person dynamic, then they’re doing all the things and they’re being all things and agility is an emergent from that particular system. There’s a huge disconnect.

If you think about how most organizations run, it’s more of like a barge that can’t steer whatsoever than agile. I feel like there’s a huge disconnect, not only between the being, doing and as you’re saying, the two different types of doing but just a problem with a lack of words and ways to describe the system that we’re trying to create. I don’t know if that’s a question. I’m curious if you have any thoughts on that if that jump in your head.

DECLAN:  Maybe, a key part of truly being agile and I say truly with air quotes, is the notion of what is a system that can work for us. Rather than following an agile system, what is the system that we can construct together that’s going to achieve what we mutually want to get done. The system is in effect ours to build. I think maybe being agile is really being intentional about understanding the system that is and the system that you want and learning and iterating your way to that future state.

JANELLE:  I love that. That was beautiful.

JESSICA:  I like to think of us not a system builders anymore but system movers.

DECLAN:  That’s really true because there’s always an ‘as-is.’ It’s where we are now and how do we steer towards what we really want.

CORALINE:  I’ve heard a distinction made at different companies I worked for where people are kind of apologetic about their agile methodology and they’ll say something like, “We’re not ‘capital a’ agile. We’re a ‘lowercase a’ agile.” I wonder if that’s an attempt to say, “We’re not rigid practitioners. We’re not cargo culting. We’re actually trying to adapt to real working conditions,” although none of those companies actually, I would say demonstrated agility. Why do people make that distinction, do you think?

DECLAN:  That’s a great question. Maybe it’s the same what you’ve heard, Coraline but I also heard like, “We’re not true agile.” I know if you’ve heard that. Maybe ‘big a’ agile to me is like the doing in the sense of we are doing these practices and to me, ‘small a’ agile means we’re really adapting and the way that we work aligned with the principles of the agile manifesto, like we’re living and breathing that way. That’s what I think people mean by ‘big a’ versus ‘little a.’ To me, for example, start with new team and just do Kanban, rather than say, Scrum and say, “We’re just going to put up a Kanban board here to reflect the system that we have and the way that we just want to reflect where we currently are.”

We don’t need to do all of the agile practices but let’s just start to think of what is our purpose, where we’re trying to go and how can we improve as we go. To me, that would might be the distinction between ‘little a’ agile and ‘big a’ agile. Is that what you’ve noticed, Coraline? Something like that?

CORALINE:  Yeah and Kanban is a great example of that because in my experience, when you do Kanban, you’re not doing sprints anymore. I just remember this one company I worked for that I think was treating agile methodologies as it was a scar that it grown over in an organizational wound. They had development practices in place that were actually harmful. Their remedy for it was, “We’ll adapt agile and all of our organizational problems will go away,” and they were so rigid about it and they did all of the recommended practices for agile methodology and they didn’t try to adapt their practices to the organizational culture or more importantly, the organizational culture to their practices. That made a really awful working environment because all these things that we were doing, just felt like an unnecessary process.

DECLAN:  I’ve seen that too. I think people draw a big equal sign between agile and Scrum. They think, “We’re doing agile and that’s because we’re doing all the scrums stuff.” I like to point out people, “Go look at the manifesto. What specific practices are recommended from the agile manifesto?” I don’t think that there are any other than statements like business and developers should work together daily and things like that but there’s no specific dogma, if you will around practice.

Then if you go look at, say Scrum, then you can ask people, “What the Scrum say about our engineering practices?” Well, it says nothing. If you actually want to go down the dogma route and you go to the original material around that, you find that there’s very little around specific practice and that’s more around the principles and the values in how we work. But I think that’s hard for people to potentially see in the larger context because they’ve installed the agile. They have their plan and their training program and I think that’s a problem.

CORALINE:  Where did that even come from? How do these practices get associated with agile when as you pointed, the agile manifesto doesn’t dictate practices?

DECLAN:  I think it’s very natural because Day 1, you guys are going to be — you folks, I’ll try to get some more gender diverse terms in here — you folks are now at agile team and you could ask them, “Start to think and behave and act in a collaborative way,” and people would look at you, probably with glazed eyes and you say, “I wish you’d have a stand up every morning for 15 minutes. We’re going ask these questions.” Oh, that’s sounds a lot simpler. Let’s do that.

I think in terms of starting down the agile road, I think practices are good because at least, it gets people starting to interact and behave. I think it’s important that they expose to values and principles but when they actually start, I think people need to start to do. Having guidance around good practice, I think is helpful. I’m an agile coach. I think maybe the difference might be, if you have good coaching and those coaches don’t need to be people that have that title, but people who’ve been there before and are able to guide and so on, if you have those people on your team, then I think your fine just to start with the road practices because in between those practices is where the real agility is going to bear, which you are giving people a frame to work in.

The danger is when people start with those frames but they haven’t had the experience or the insights to really make it work within those teams, then it becomes cargo cults. Especially, if that’s [inaudible], like all the teams need to behave in the same way, now you are really constraining behavior. I’m just trying to say, a lot of the road practices can be good to, at least start the teams working in a certain way, hopefully as a stepping stone to something better. The danger is people get trapped into that step one.

CORALINE:  I really think what you said there about adopting a practice across teams being a warning sign. That’s what I heard you say, at least. It’s a very important point because every team develops its own culture, every team has its own challenges and how you respond to this challenges, in a way that makes you productive is going to necessarily be different.

DECLAN:  Yeah, and people really love consistency. If you have 12 teams, it would just be awesome if they all had the same leg sprints and they all measure progress in the same way so people will feel that there’s a lot of benefit from being consistent. I think there can be and then I say, “If that’s true, what are those benefits? Let’s talk about those,” and then, if you can move people away from the practice that you want to be consistent and shift the conversation to the outcomes that you want to be consistent, then you can have sort of consistent outcomes. You’ll say, “Let’s try for that,” and then ask each team, how are they going to achieve those common set of outcomes that we want. For example, reduce time to market or quality or whatever it is. But simply saying, “We’re all going to use Jira for tracking our work and that consistency will lead to something,” then explore that something. I find that that’s a good way to attempt to cut through that fallacy about common practice.

CORALINE:  I love that. I have to do the obligatory reference quote. Emerson said, “A foolish consistency is the hobgoblin of little minds.” The important word there is foolish consistency. I love what you said about consistency being centered on the outcomes, rather than the process. I think that makes a lot of sense. I wonder if lots of failure on the part of agile proponents of selling agile to management, are they setting unrealistic expectations or are they not going far enough to explain the focus on the outcome, rather than on the process?

DECLAN:  I think you’re probably right. I don’t have a lot of experience at the executive level or with large agile rollouts, if you will. I don’t have a lot of experience to understand how to do that better. I worked with a consultancy called ‘LeanIntuit’ and Chris Chapman, one of my cohorts there keep saying, “Management goes first,” which I love, “Leadership goes first,” so if you want these teams to be agile, then we are going to start as a leadership team to work in an agile way. Let’s make our work visible. Let’s have daily stand ups, etcetera.

I think, there’s dangers on these agile rollouts where, “Oh, we’ll fix up those teams and those people will do the agile and we’ll just see faster time to market.” Getting their leadership much more engaged of the purpose and the outcomes and having them demonstrate the behaviors that they want, I think that’s what is undervalued or missed in some of the larger agile rollouts that I’ve experienced myself.

JESSICA:  I love this drive for common outcomes, not common practices. I’m so going to tweet that. What you said about locality about each team having its own culture, that’s also important. If you had 12 teams and you took the one that you personally find the most productive and want the other teams to be liked and you take their practices and impose them on other teams, then you’ve just magnified the disparity because those practices work for that team. If you force the other teams to use those practices, it’s actually a disadvantage for those teams, compared to being able to develop the practices that work for them personally. To me, it works.

DECLAN:  Yeah, my brother is an architect, not a software architect but a real architect and they had —

CORALINE:  Nice.

DECLAN:  — A bricks and mortar kind of a guy and they were doing an exercise around teamwork and they basically had a large group broken up into small teams. Each team had this puzzle. Their instructions were to get everyone back safely and they had to build this lunar thing with Lego and then bring an astronaut who was a little Lego stick figure back and they couldn’t move their ship until it was completely assembled according to some specifications. There’s some complexity in this.

Interesting thing was, his group turned out to be the only group that ever successfully completed the mission. The reason was when they divided people up into teams, people just focused on their team and they said, “We won,” but the instructions was everyone gets back safely so the exercise was not around trying to complete the task. It was about how you are going to share your information with the other teams so that everyone in the room wins.

I think maybe that’s what I would think about with agile at the team level, rather than saying this team is working really well, you guys should be doing that. It’s about how do you promote cross-learning across these teams so they can learn from each other. In the same way that we promote pair programming is make sure that luncheon learns or maybe guest pairing or things like that to promote cross-team learning, would be the direction that I would go. I guess it’s sharing the learning, rather than the practice.

JESSICA:  That’s cool. I love that everyone gets back safely of this is not a competition and that gets back to where we started with communication and empathy. There’s a falsehood that comes up sometimes in some groups, where I’m talking and four people understand me but two people don’t or maybe just one person doesn’t. I’m like, “They understood so clearly, it’s not me,” but that’s wrong. As a person trying to share learning, if one person doesn’t understand, that’s still on me. Just because those other four happen to be able to read between the lines, maybe we share a lot of our contexts. I’m the one who has the ability to slow down and add new ones to whatever it takes, like the people with the Legos who had to proactively go and share information.

DECLAN:  I agree.

JESSICA:  Declan, was there anything else you’d like to bring up and talk about?

DECLAN:  To take a completely orthogonal tack is this idea that technical health. I’ve been thinking a lot and working a lot around technical debt. I’ve found it to be a very powerful metaphor but a metaphor that I think has somewhat trapped us into a way of thinking and that thinking sounds something like, “I’m carrying around this big bag of technical debt. We really ought to go and fix up that crap that we built last month or last year and it’s this albatross or this ball and chain thing that we’re dragging around with us.”

I do want to make one slight distinction. I know people will always ask me and it’s always good to go into tech. There are definitely context where technical debt is good and I agree with that. I’m really talking about technical debt that’s really hampering value delivering where it’s really crushing the teams. What I’ve started to do is starts to change the conversation to technical health so how do we build an infrastructure and a way of coding and set of practices that enable us to have a technically healthy organization where we conserve and deliver on well and then technical health becomes the ability to deliver value and technical debt becomes the things in the code that are stopping you from doing that.

This is relatively recent for me. I’ve been thinking about it for a while but I’ve only been talking about it more recently. I think it’s a lot more powerful just to have a conversation. for example, rather than talking about going to a CEO and say, “We really ought to clean up that crap,” it’s more like, “If we really want to be competitive in the future, there’s some things that we can do to improve how quickly and effectively a software comes out. We should probably invest in that, just like you would invest in making sure that your assembly line is working really well,” as a as an analogy.

I think just switching the term from debt to health sort of taps into positive psychology, where if you look at intervening with mental health issues, we all have them either ourselves or within our families, it turns out that when you focus on making the things that are problematic go away be it anxiety or depression and you’re able to get people through traditional techniques to spot where, “I’m okay now. I’m okay.” But if you can actually shift to a positive psychology stance where you really trying to dial up what makes people happy, the people come up with far better clinical outcomes. I think something similar can happen within our teams. Rather than focusing on removing this bad stuff, get people thinking about how do we amplify what we want, which is in an agile context, you’re affecting value delivery.

Then it shifts the whole tone of the conversation and we don’t have to talk about past things or these other people wrote this crappy code or whatever it is. Let’s look forward and how do we build a healthy code base and a healthy deployment pipeline, etcetera. I think that sort of the level one of the difference. I’m finding that even simply just having conversations is being enabled by just using the term technical health, rather than technical debt. I think it’s leading to better conversations about what’s really going on.

JANELLE:  I’m really fascinated by this pivot that you’ve pointed out of when you focus on problems going away, your psychology shifts to this kind of avoidance pattern, this ball and chain of the technical debt that is dragging us back, versus when you focus on technical health and you shifted this positive psychology of how do we dial up what makes us happy, how do we amplify what it is we want. I love the correlation with the underlying psychological shift and how the semantics we choose in perfecting that.

Looking at the world through this lens, how do we amplify what we want? I love that question. It’s a really powerful question. If you were to answer that question yourself, looking back across all of your experiences, what are the things that you found to be core to amplifying what you want. Can you even define what it is you want? At one level, value delivery but what is it that we want in organization? What is it that we want in a culture? How do we amplify what we want?

DECLAN:  I think it would be a start with identifying what we want and just being clear about what that is. Having a clear sense of purpose and that purpose can be and it should be, a variety of things. It could be what do our customers expect of us, who are internal stakeholders? But what is just as important to me is what do I want and what do you want as individuals from this work that we’re going to do together. To some extent, I think step one is sort of having a clear understanding in open dialogue around what it is that we want.

I think the conversation gets a little bit easier than if you got clarity around that, you can ask things like how can we measure that? What I really like to put into place with teams is team happiness. How happy are we working here and where would we like to be and talk about that? Then when you see things like our happiness is at a three and we really prefer to be at a four out of five, then what can we do next week to dial up that happiness. I don’t know if there’s any prescriptive thing but I guess I would say, just be clear about what you want and retrospect regularly on how you’re doing.

JESSICA:  I like that technical health, instead technical debt. You can think of it as debt when you’re choosing whether to take it on but after that, don’t feel bad about that sloppy code. Then you don’t have to fix it just because it’s ugly. Fix only what’s getting in your way because it’s not about measuring the debt. It’s about moving forward.

DECLAN:  Exactly.

CORALINE:  That brings to mind one of the tools that a lot of companies uses, at least in the Ruby world is something called Code Climate, which assigns a letter grade code and somethings end up being an F. I think they automatically cross [inaudible] technical debt like Jessica said, it’s not in your way if it’s not code that gets executed much or gets touch much, leave it alone. That’s not really what standing in the way of progress and that’s really not withstanding the way productivity.

DECLAN:  Yeah, I couldn’t agree more. The reason why I like the health metaphor to some extent is it gets our brain thinking about it in a different way. Back to the Cold Climate example, if you’re not all A’s, then you sucked. That’s in a very superficial that some could take of those metrics. But then if you think about health and think about people, like my father who is 83, his definition of good health is going to look far different than a world-class marathon runner. They both care about health but in their context, being healthy means very different things.

Rather than having an absolute number, you start to think what’s health for us and the fact that we have an F on this code module, who cares if we haven’t changed it for 18 months. It’s not slowing us down. It doesn’t mean that you have to be all A’s. Maybe where your team is are because you got some legacy code. Maybe that code metrics sort of sucked. But that’s where and how do we get healthier. It’s more about the progression to health as a continuum, rather than some absolute number which is an ABCD implies.

SAM:  I really like this focus on what are the outcomes that we want and what do we need to do to get there. For me the thing that’s coming up is the idea of the campsite role, which is this practice that whenever you touch a bit of code, you leave it at least a little bit better than it was when you found it and that’s a nice incremental way of dealing with the technical debt that’s actually in your way, on your way to technical health, without really stopping and focusing on every single thing that’s wrong with it, right?

DECLAN:  Yeah, definitely, as a technical coach, that’s my number one mantra, is the Boy Scout role or the Cub Scout role. The other level that I’ve been thinking about with technical health is when I first thought of it, I am working with an issue that the Agile Alliance, by the way so this idea of technical health came out from really a group discussion. I happened to be the one that talks most about it on my group. When I first thought about it, we thought it was just being this positive psychology switch like, “Let’s just make technical health be the inverse of technical debt.” I, now think of it more nuanced. I think of it as technical debt is something that we can measure in terms of looking at the code but technical health is probably something more of our capacity to deliver value and meet our purpose.

When you start to look at things from a technical health perspective and then you’re able to look at technical debt as an artifact, you can start to say, “We have this measure and I have things in my team or my organizations that are either increasing or decreasing that technical debt and now I can apply for the systems thinking to the dynamics that’s happening in my organization.” I’ll give you a concrete example. I think that one of the biggest contributors to technical debt that I’ve seen has been project planning horizons, where you’re bringing in teams to work on code for, say three months and then they’re off and they’re no longer accountable for the code after they’ve delivered their three month deadline. but the best to the organization has to live with that code for years down the road but nothing in their system is actually taking that into account because all of the budgeting and resourcing, which is the word I hate but assigning people to work is all done with a very short horizon timeline.

The technical debt problem is not those damn coders who just keep writing crap. It’s actually a systemic issue with the way the organization plans and budgets and organizes people around the work. That’s the root cause. You can have the clean-up of the code as a go as a great practice but if the systemic issue is this project-driven mentality for building products, then you’ll never really get what you want. Unlike in the technical health, it really allows us to bring the systems thinking view to our organizations and using technical debt as a measure of the effectiveness of that system.

CORALINE:  We’re doing something pretty interesting [inaudible] right now. This is a new thing we’re trying out. We put together what’s called the sustainability and stability team and that team, every larger team within your organization devotes 20% of its people [inaudible] team and their charge is to increase the stability of systems and to make the code more sustainable. It’s not really a matter of addressing technical debt but rather, looking at what the pain points are, like one of the pet projects we’re undertaking is getting off the list-shared database.

That’s not something you can really do incrementally and it’s not something that stop the world but fix all of these things practice either. But it’s a way of addressing system health that I think is a pretty interesting approach to solving that problem. The people who are on that team rotate out. You’re on a six-week rotation so there are goals that the team sets but the people are implementing it rotates in and out. I’d be curious to hear your thoughts about an approach like that or if you’ve seen that before or if you have alternate approaches to how dev organizations could take on that kind of work.

DECLAN:  I’m going to write that down because that has not come up in my experience the way we talked about. Actually, I would expect that that would work really well. It sounds like a really powerful way to work to me from how you describe it. How this actually work, Coraline?

CORALINE:  It’s a fairly new practice so it’s too early to say whether it’s successful or not. But I think it’s a really interesting idea and I’m really hopeful that it does work out. One of my teammates [inaudible] actually pitched a proposal to RubyConf to talk about this particular approach and I’m really hoping that her talk gets accepted because I like to see some conversations around that. I’ve seen a different way of handling in the past where a team will say, “We’ll spend 15% of our sprint on fixing technical debt,” and that seems a terrible way to solve that problem.

SAM:  That just never happened.

CORALINE:  No, it really doesn’t.

DECLAN:  Yeah, I have seen things like that or we take one ticket per week or the other practice I’ve seen is we’ll take these hardening sprints or something like that. We’ll have a sprint at the end devoted to technical debt. I think each of those work. I’ve worked with a lot of smaller companies so they don’t have this issue of having multiple teams and dealing with, perhaps some common challenges but what I like about what you’re saying is whatever you’re bringing the knowledge of the real pain into that support team and then bringing it back out again. My prediction would be that you would see a lot of value from that because it’s explicit knowledge movement across those team boundaries by swapping people in and out.

SAM:  One thing I’m curious about with everybody doing six weeks stints and presumably, people rotating in and out on different timelines, I’ll be really curious to hear about how continuity gets maintained on that team. I would have imagine that there’s going to be a lot more focus on providing or building and maintaining artifacts like a ReadMe or a document of principles or some sort of project plan. I’m curious to see how that shakes itself out.

CORALINE:  There are some overarching goals that the team has in place. Getting off the shared database is a very long process and no one team of people in the six weeks stint is going to accomplish that. The team has the overarching goals but I think the interesting thing is with rotating people in and out, they’re addressing different areas of the codebase that maybe have been raised to a certain level of awareness or attention within the greater engineering organization. They’re bringing their local knowledge of particular aspects of the codebase to bear and saying, “Fixing this issue here, fixing this code here or assigning the system here,” is going to contribute to the overall health of the greater codebase.

I think that ties in to what Declan what saying about big management first. Someone in a situation like that does have to set the goals and someone does have to create the project plan and someone does have to commit to 20% of the people on the team doing an endeavor like this. That’s not going to happen from the bottom up.

DECLAN:  Yeah, I would have agree. Technical debt in larger organizations is such a huge impediment. I look for simple measures with teams like how happy are you working with the code? That’s a good measure. And how much is the code slowing down now? Then you can optimize on that. I also have other questions, how much of your time do you spend building new value versus dealing with troubleshooting or defect tickets?

I’m sometimes shocked when I hear it. I worked at one team where I calculate effectively their value delivery was 4% of what their capacity was because they were spending so much time fighting production fires and they asked me if they could go five times faster if the code was well-factored. Now those are somewhat not scientific measures but it certainly it gives you a sense. If the team says the capacity basically is 4% to deliver any value, that’s a serious problem and it warrants a strong response from the organization.

CORALINE:  There is one way to measure that and I’ve done this at a company before, where you look at pull requests and if the pull request is referencing an issue, assuming you’re doing good issue tracking, you can actually say, “We got five pull requests in the sprints and three of them were no fixes for issues and measure value delivery that way.” I think that’s a really good measure as developer productivity and happiness in health and codebase health is how much value is being delivered within X period of time because probably, if your developers are frustrated, if the codebase is resisting efforts to change, that’s going to impact that metric and it’s not a developer problem. You can’t say, our developers are not being productive enough. That points to a larger system issue.

JESSICA:  Also, a few minutes ago, Janelle was asking what do we want to achieve and what will make us happy? You can look at it that way. What technical changes could I make that would make me more excited to come to work in the morning?

DECLAN:  Exactly.

SAM:  At the end of every call, we like to wrap up with reflections, which can be something that stood out to us as particularly interesting, something that we’re going to take and carry forward or it can be a call-to-action for our listeners. Anything along those lines. Since I haven’t thought of mine yet, how about Jessica, you go first.

JESSICA:  Sweet. The biggest thing for me is strive for common outcomes, not common practices. That’s so healthy. Instead of, “Use this framework,” it’s, “Support this API.”

CORALINE:  I was really struck by a side comment that you made, Declan about how some situations whether be a user story or something that someone says and stand out should be taken as a promise for a conversation. I will be thinking about how we can be more explicit about that. I often hear corporate speak of, “We’ll take that offline,” and I think that it’s just a way of deferring a conversation that maybe will never actually happen. But if we can be explicit about making a promise to have a conversation that impacts so much productivity in terms of not developing the wrong thing or developing the wrong context, as well as happiness because you get the sense that your concern is being addressed and you’re being heard. I’m going to think about how to be more explicit in promises like that.

JANELLE:  I’ve been thinking back on this conversation we had about this power imbalance and with culture and leadership through modeling. One thing that really stood out to me was this idea of asking permission. because of this power imbalance that it’s there in leadership, I’m thinking about some mistakes that I made when I probably should have ask for permission and I didn’t and I ended up causing all kind of problems and relationships blowing up because I didn’t ask those questions. That’s like dissonant blowing up in my brain right now is those regretful decisions that you wish you could go back and do things differently, if you’d do all over again.

One of the things that I’ve learned as a leader is being a leader in a way makes you blind in a way that you don’t think you’re going to be blind until you go and you make mistakes because you don’t realize that you have power in this relationship dynamic. one of the things that happens because that relationship dynamic is often disrespect on the other side of the wall, on the ‘us versus them,’ and one of the ways that you can correct that if you’re on the side of power is to ask permission and what that does is it elevates the people that you’re talking to position of respect.

SAM:  I talked earlier about the difference between attributes and behaviors and I think that’s an important one. Certainly, it’s important for me to remember in my personal life as well as development. But at the risk of copying Jessica, I do think that that focus on identifying and clarifying what are the outcomes that we want is really possibly the most important thing we’ve talked about today, at least for me. I noticed as well that this works for team practices and that’s what we were talking about. that’s the context we were talking about it in. but it’s also really one of the fundamental things that makes agile development work and be worth pursuing as well because you’re focusing on what are the outcomes that you want for your users and the value that they’re getting out of the system. I always like finding those principles that work in multiple contexts. That seems like a new one for me so thank you.

DECLAN:  Reflecting on this conversation was for me, really was because the first thing I came to mind is like my mind was expanded. I really try to listen and really understand where you were coming from. I think you’ve really enrich as a group so my understanding or help me clarify my thinking around some things and particularly around empathy and behavior. Maybe what I’m getting at is a call-to-action for teams that are out there, how could you have conversations similar to the ones that we’re having with your teams? Whether it’s around empathy or diversity or common outcomes, how can you have more effective conversations with your teams? Could you plan a retrospective to talk about common outcomes or technical health or diversity on your team? That’s really what I would like to say. How do you take these conversations and translate them into actions on your team?

SAM:  So your call to action is figure out how to do that?

DECLAN:  Yes. Can you plan a retrospective that could cover some topic that may have resonated with you on this podcast and bring that conversation back to your team and organization?

JESSICA:  Now is the time when we remind you that Greater Than Code is a listener supported podcast. We like to do a Patreon shout out. Our newest patron this month is Declan Whelan. Thank you, Declan for contributing at a $10 level. The important thing though is if you contribute to our Patreon at any level, then you get access to our Slack team. It’s my favorite Slack team. Everybody is super nice. I highly recommend. While listeners support, let us do more shows. Currently we’re doing three episodes a month. We would love to do four.

CORALINE:  Jessica, if someone wants to be a patron, how can they do that? Is there a site on the internet they can go to?

JESSICA:  Yes, it is ‘IRolledANatural20OnMyAgilityCheck.com.’

CORALINE:  I think it’s Patreon.com/GreaterThanCode but I appreciate your enthusiasm all the same. Declan, thank you so much for joining us today. We’ve had a lot of fun in what it means to be agile and I learned a lot from the conversation. Thank you so much and I look forward to continuing the conversation on Slack.

DECLAN:  Thank you very much for having me. I really enjoyed learning from all of you and I felt really welcome. Thank you.

 

This episode was brought to you by the panelists and Patrons of >Code. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode. Managed and produced by @therubyrep of DevReps, LLC.

To make a one-time donation so that we can continue to bring you more content like this, please do so at paypal.me/devreps. You will also get an invitation to our Slack community this way as well.

Amazon links may be affiliate links, which means you’re supporting the show when you purchase our recommendations. Thanks!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.