ºÚÁÏÃÅ

Full transcript

Ìý

Neal Ford: Hello, welcome to the ºÚÁÏÃÅ Technology Podcast. I am one of your regular hosts, Neal Ford, and I'm joined by another of our regular host today, Scott Shaw.

Ìý

Scott Shaw: Hi, I'm Scott Shaw. I'm the head of technology in Australia for ºÚÁÏÃÅ, despite my American accent. We all happen to be together here in a room in New York City for the first time in a long time.

Ìý

Neal: Which is an exciting opportunity for us as podcasters. When we gather as a Doppler group to put together the Radar, lots of topics come up that are just too nuanced for us to talk about on our Radar and so we generate podcasts from them. That's exactly what we're opportunistically doing here today. We finally met together for the first time in a couple of years and lots of interesting topics came up today. Today's topic is exactly about what we've been dealing with the past couple of years, is how has coding changed during the pandemic? I am joined today by a couple of our colleagues. I'll let them introduce themselves, starting with Cassie.

Ìý

Cassie Shum: Hi, everyone. I'm Cassie Shum. I am a senior technologist here at ºÚÁÏÃÅ, based out of New York, so everybody's in my hometown today.

Ìý

Punit Lad: Hi, and I'm Punit. I'm a lead consultant with ºÚÁÏÃÅ based out of New York as well. I've been at ºÚÁÏÃÅ for around eight and a half years.

Ìý

Neal: The thing that spawn the idea for this podcast were a couple of blips that came up on our Radar and one of them was called meandering. Was it meandering around instead of stand-up? What was the phrasing that we didn't care for?

Ìý

Cassie: It was meandering team sinks instead of the typical stand-ups.

Ìý

Scott: I think it came from a blog on the honeycomb website, that said, stand-ups are dead, what do you do? Which was news to me. Do you think stand-ups are dead?

Ìý

Cassie: Well, I'm going to defer to a Punit over here because I think my version of stand-ups is just many, many meetings throughout the day.

Ìý

Punit: It's interesting to think about like our team right now is still doing what we call daily syncs, which are really just like we walk the wall, look through the cards, see what people are doing and try to collaborate as a team. If there's topics on-- Problems with a card or people are stuck, that's where we'll collaborate and that's where we communicate. I do think that we still do that ritual of collaboration around what we've done yesterday or what we're currently working on, but maybe stand-ups themselves aren't necessarily like in the traditional sense anymore.

Ìý

Scott: I think part of what that article was saying was there's no time during the day opportunistically for chit-chat and building rapport and finding out what people are doing as people. You need to set aside some time and the traditional stand-up doesn't really allow that. It's too disciplined.

Ìý

Cassie: I think pre-pandemic, I remember when we traditionally did stand-ups, we would actually try to be as quick as possible, which is the root of why everybody needed to stand up because people did get a little bit antsy if you were standing for too long and people carried on too long. What traditionally happened after that is some topics would come up during the stand-up and then people would break off and go grab a coffee and have more discussions about what they were working on and things like that.

Ìý

Come the remote time now, I think some of this idea of having more touch bases and not as strict stand-up things came about.

Punit: To your point about those stand-ups in person, there is still like the you gather around maybe the TV or stand up in front of each other and people chit-chat for a quick second, and then they get right into the stand-up. That's harder to do when you're remote.

Ìý

Scott: Has either of you tried the async stand-up? Where you just put a chat, but every morning, everybody puts in chat what they're doing.

Ìý

Punit: We've done that when we can't have our traditional stand-up and someone will put a message in chat and say, "Hey, put your updates here," and then we'll do that. Those are good but they don't allow for any of the post-collaboration. People are struggling on like, oh, what kind of tech decisions should we make on this particular work? That doesn't really happen and traditionally then people just end up getting on a call later on in the day.

Ìý

Cassie: I actually found that, in the beginning of the pandemic, we started doing a lot more asynchronous communication because people were starting to get that Zoom fatigue. What was interesting is I believe the pendulum swung a little bit too far because all of a sudden, either on Slack or on chat, I was getting too many messages and I couldn't catch up to it.

Ìý

For those modes of communication, it was supposed to be a bit more real-time. "I have a question right now, how do we figure that out?" We are seeing a delay and a lag in answering in collaboration. We had to bring it back and introduce more smaller touchpoints throughout the day as opposed to bigger meetings. I'm not sure if that's working or not, it's just something.

Ìý

Neal: That in many ways to me is the crunchy center of this podcast because we developed all these things like stand-up exactly like you say because we need a quick status check and we need a way to quickly huddle all of our problems. Then constraints come in that prevent us from doing that. It sounds like what has happened is that you split those two activities now, that you do either async stand-up or very quick Zoomy stand-up, but then the meandering thing allows you to do a sync-up between small groups.

Ìý

That begs the question, how do you keep the meandering thing from spiraling out of control because now you don't have the constraint of everybody standing up and waiting for you to finish talking?

Scott: Have you ever done the always-on channel or always-on Zoom channel? That's worked for me in certain circumstances in the past.

Ìý

Cassie: I have actually found that to be quite healthy and important if you set the ground rules beforehand. I think what's interesting about that is I've had another computer, another screen off to the side, usually my iPad or something, where I would go on mute and turn my video off, but the minute I needed to talk to someone, I would turn the video on. That worked in some circumstances, but not others when we didn't set the expectations beforehand. As long as you set those ground rules and say, "Hey, if someone pops up, then somebody wants to talk," and just being aware of that and getting that.

Ìý

Punit: We haven't really done it as a full team, but during certain pairing sessions with some colleagues, I'll just say, "Hey, I'm just going to stay on." We're doing different work or different pieces of work. We're just going to stay on together. It's nice to have that little background noise there or the fact that you could just say something and someone is there mimicking that room feel, which once you go on mute or you go off Zoom, you get none of that.

Ìý

Scott: I really miss that.

Ìý

Punit: Totally. [chuckles]

Ìý

Neal: This goes back to there used to be many years ago, there was a very standard setup for projects. It was pairing stations. I had Yahoo Messenger on it and every pairing session was named and that was the communication from the project. You get the stand-up in the morning and messenger was that asynchronous communication amongst the group if you didn't want to disturb the whole group.

Ìý

Now, it sounds like it's a lot more à la carte per project, per group, per working style, per what's effective for this group, and it's not nearly as homogeneous across the works anymore. Is that hypothesis correct, do you think?

Ìý

Cassie: I believe so, actually. I think we are more proactively setting the expectations and ways of working in the beginning of any group that we're working with, just because there needs to be an increased sense of empathy across all of the different groups where people are, what kind of internet connection they have, and what kind of home living that they have. I think traditionally when we had pairing stations, it'd be in the office where the environment around you was actually quite set.

Ìý

Whereas, now, all of the different environments are just variable. There is folks that have kids working from home as well. There's others that actually have different partners in other rooms also having Zoom calls and internet bandwidth and things like that. Being able to just keep that empathy open and actually try to figure out what works for a team to just best collaborate and communicate, I think is the best advice right now.

Ìý

Punit: Actually, I think there's a balance. In order to get some of that empathy, I think there's a balance of keeping your video on and off. The empathy being if your video's on, you can understand that person's surrounding a little bit better. Sometimes you can see a person has a really good camera, which means maybe they have a better setup, whereas someone using their own MacBook's camera is not going to look as visually-- It won't be nearly as in focus. I think that provides a bit of empathy for people to understand, "Oh, this is the living-working situation that you have at home. I'm going to be able to pair or work with you better because I understand that better."

Ìý

Scott: It's true. In some ways I know my colleagues better because I see their kids and their pets every day. [chuckles]

Punit: I've always told folks that have kids and pets, "Yes, it's fine, you're at home, you're on camera. That's your situation." I also understand that other folks may not be comfortable with their kids showing up on camera or their dog showing on camera. Allowing them to keep that balance helps.

Ìý

Cassie: Actually one thing that I know I've explicitly done personally, is the different types of meetings that you have. When we're in meetings that we are collaborating together and actually presenting things in front of people, then I would probably set up my workstation a bit more I think professionally may not be the right were, but like with more structure.

Ìý

I actually tend to use a lot of my one-on-ones with folks to be a lot more casual to show that human side. For example, I would actually switch to my laptop and go make coffee with them and they can actually see a little bit of my routine and I encourage them to do the same, so it feels a lot more comfortable than sitting in the same spot every day from meeting to meeting, to meeting, and it encourages people to actually walk around and get up and do something slightly different.

Ìý

Scott: I would think being a tech lead in this environment would be really hard because you can't just get a feel for how people are going or look over their shoulder.

Ìý

Punit: When you think about it in an environment where we're all together as a tech lead, you're not necessarily pairing with folks all the time and you're in and out of meeting. The nice thing of being all together is you come around and you can just hear what other people are saying. That perks up your ear and you're like, "Oh, okay, let me chime into this pairing over here and then I'll go over and do something else and then go back to a meeting or whatever."

Ìý

Being remote makes it quite a bit more difficult. You don't really know, you have zero sound of the other developers on the team. You can't really hear them. I found that I will still pair with people even though I'm in different meetings. That way, at least I get you're with a pair and then try to keep myself open. If people have questions, I'll just ask them to jump in the Zoom room with my pair so that we can all be together rather than I hop off, go into their room, try to keep that collaboration, but it is definitely difficult. Early on in the pandemic, I had a hard time. I was like, I don't know what's going on. [laughs]

Ìý

Neal: That ambient information is really critical. It's impossible to get when everybody's remote. That's really tough. One of the good piece of advice that [unintelligible 00:12:43] give is, you often hear don't repeat yourself. His advice is repeat yourself early and often, particularly when you don't have that ambient understanding of the project. You have to, as a tech lead, repeat yourself over and over and over again, to make sure that every single person has heard it because they can't just overhear it. That's a change in management style for some people to get accustomed to.

Ìý

Punit: It actually ladders into a little bit of just side, of in terms of communication during remote work, over-communicating is actually be more beneficial than under-communicating even on Slack, repeat yourself. Exactly, it's so much more helpful to have that over-communication and have that environment to be able to over-communicate.

Ìý

Neal: Let's talk about over-communication for a second. How many information feeds are you normally plugged into as you're working during the day? [laughs]

Ìý

Scott: Just Google chat channels because that's what we use in ThoughtWorks that is overwhelming. I'm always pinning a new one to try and bring the top and then the others push down to the bottom.

Ìý

Cassie: I would say quite a few. I'm usually on Zooms throughout the day. The Zoom chats come out as well and I have to remember to switch over if I need to keep any information. Yes, at ThoughtWorks we use Google Chat, and then of course on my clients, I have Slack. Switching between all of those things have been interesting. I have multiple clients that I'm a part of as well. I actually had to introduce Teams into one of them at one point. At that point, I think that was my break.

[laughter]

Ìý

Punit: On my current project outside just ThoughtWorks communication on my current project, we have Slack as well as multiple instances of Slack. We have three different ones that you'll have to join as well as Teams, as well as your own email. Your head does sometimes get a little bit split up around all the different communications. What I've learned is my focus is going to be mostly on the team and the surrounding channels around that team with the stakeholders and that external communication. For the most part, I've never really dove into those other conversations unless I really needed to.

Neal: I've always joked that on every project, there's always someplace where information goes to die. Now the problem is there are a dozen places where information can go to die. I need that piece of information. Oh, man, where is that across all these different ecosystems? That's a problem that hasn't gotten any better from the pandemic and multimodal communication. What else has changed from a development standpoint during the last two years?

Ìý

Cassie: I can start off with I think my workday has just elongated quite a bit. I think I'll be honest, when the pandemic first started, I thought to myself, "Wow, I'm going to be really saving time on travel and going into the office and things like that." I don't actually believe I'm saving that much time. I think I'm actually a little bit more fatigued right now because I'll wake up and I'll go straight to my computer and then that my day starts at 6:00 AM.

Ìý

Normally, if that happens pre-pandemic, I would've said, "All right, I had an early day, let's stop at 5:00. Let's break, go home, and then detach," but I'll have days that go on much longer because it's that easy to continue your day. I would say after two years, I started putting really strong structures in place to say, this is how I'm going to detach from my work environment. One of that was essentially rearranging my apartment to where my workstation was and to where my recreational areas like my couch and my TV and things are.

Ìý

Punit: I think that's super important because, for me, my dining table is my workspace. [chuckles] After work and I'm ready to eat while I'm going to eat where I work now, [laughs] effectively. It's really important to have that distinction and that split. Another thing that I think has changed I think for developers particularly is, the engagement with other people probably has been much more limited.

Ìý

As a developer at ºÚÁÏÃÅ, we pair a lot and so you're probably going to get a lot of interaction with your pair. That's about it. You probably won't get to see other stakeholders. You won't get to see maybe your other developers other than that sync that happens, but that just doesn't happen nearly as often. As a tech lead, you get a little bit more of that, a little bit more spread out, but as a developer, you're probably not going to get nearly as much engagement from your other fellow developers.

Ìý

Neal: Do you find that you do more aggressive pair rotation cause of that or is it easier just to leave like pairs together because we haven't mentioned yet the horribleness of time zones yet.

[laughter]

Ìý

Punit: We have not done aggressive pair swapping and that I think it more ladders into the fact that maybe the stories just need a little bit more time to get started on and people need the ability to stay on it for a longer period of time. We do a weekly rotation, which the team feels has gone really well for them. To your point is like, if we do a little bit more aggressive, you'll get more interaction. Maybe that might help in some other areas rather than maybe staying on a story for longer and getting all that context.

Ìý

Neal: I have another hypothesis too that when you do aggressive pair rotation and you pair so we have to walk over and chat with whoever was working it before. If you're all in the same room, that's a fairly low ceremony thing, but if you've got set up a Zoom meeting and check their calendars and it's just-- Does the friction creates inertia that makes it harder and harder to do that?

Ìý

Scott: I'm curious how you're doing pairing. Talk about pairing a bunch, but that's not necessarily easy when you're separated.

Ìý

Punit: For our team, we do the rotations every week, and then honestly, it's up to the pair to decide how they really want a pair, whether they split doing work, whether they're on Zoom together. When I pair with some of the developers, I like to stay on Zoom with them so that I could just hear the conversation. We do the rotations and try to do things together.

Ìý

At the end of the day, as a tech lead, we want to pair so we have that context sharing that's happening. As a pair, you're going to figure out what works best for you and your pair. If that means you're able to split up the work and do them separately, if that works better for you, or you want to stay on the call together or whatever else might work, then left up to the pair.

Ìý

Scott: Do you find that Zoom by itself with screen sharing is enough or do you use the IDE sharing features?

Punit: Oh, yes. I've definitely tried Visual Studio Code and sharing through that means, but I haven't done that much. Usually, it's watch someone else while they're working. I think it's good to have practices around committing frequently and having a good pipeline because that allows you to swap who's driving and who's not because when you don't have that, then you're like looking at a screen for an hour or two hours. There hasn't been a commit, I can't do any work.

Ìý

For me, as a developer, I get antsy. I really want to type, so let's commit, let's go, so I can start typing.

Neal: The pandemic has changed a lot about the way we do development, but as the pandemic hopefully wraps up and we get to move back into the same spaces, what do you think we will keep from the changes that we've made during the pandemic as a genuine improvements to what we were doing before that we were forced to adopt, but now we've realized that, oh, this is actually way better than what we're doing before?

Cassie: I think there's been some really great improvements to, we did talk about the avenues of communicating, like Chat and Slack and Zoom and things but I think because of the pandemic, using tools Mural or Miro and things like that, have really improved because by pair constraint, they had to improve. I think still utilizing a lot of those features, I think it's going to be really, really great.

Ìý

I also think the empathy since everybody has to be distributed, we have so many distributed partners that will continue remote from team to team. I'd love to keep that empathy up in terms of when you're actually working, when we're working with our counterparts in India or in China or in Latin America, that empathy is actually is still there after the pandemic because even though we're going back into the offices, I like the ideas of keeping the screens up and making sure that we have the ways of working, of communicating asynchronously and over Zoom and things like that.

Ìý

Punit: I feel like people will probably revert back really quickly in some level and just, I don't know. I find it much more engaging to be in a room with people and I will happily turn my laptop off and Zoom.

[laughter]

Ìý

Punit: I'm not entirely sure if folks will keep certain things. I think the syncs probably change, maybe those hour syncs and they're not nearly as frequent and those collaborations still stay the same as we've been doing remote but I'm not entirely sure about some of the other parts we'd keep.

Scott: I think those collaboration boards like Mural and Miro are going to stay. We've replaced Slideware in a lot of cases with those and I think it's much for the better.

Ìý

Neal: It was the advent too, of right about the time the pandemic hit, the infinite canvas drawing tools became super popular and that's everybody started putting all their collaboration with these big infinite, doable canvases, which we can buy. Is that the plural for canvases? Because it's showing you shared collaboration around a drawing which always used to be a whiteboard, now has moved online for sure.

Ìý

One last big topic, one of the most intense in-person things that we've always had to do on projects with clients is estimation. Of course, now, all of that has moved remote too but we always, and it seems like this is a perpetual topic in Agile software development since we've been doing Agile, is how best to do estimations and precision, et cetera.

Ìý

We actually talked about a bunch of different alternate estimation techniques on our Radar this time. Now, this should go with a caveat of very often, very advanced teams can bend and break rules in ways that are more effective than the rules, which doesn't mean that everyone should throw the rules away or bend them or break them. With that caveat, we talked about several different types of estimation tricks.

Ìý

Cassie: One of the techniques that we've talked about was around the no estimates techniques. This is something that even pre-pandemic we've talked about in terms of how do you actually have stories that are of similar size, so really you don't have to put a value on it, and that teams can be a lot more loose around those things. I think one of the things that still holds true is that we talked about the maturity level of the teams to be able to do the no estimates as well.

Ìý

When we say the maturity, it's actually not even the tenure of developers or anything like that, it's more of how the team works together and how long they've been working together and how they know-- Neal, if you and I are working on a story, we know that my version of a small story is your version of a small story. Being able to do that with a no estimates type of mentality, I think does work.

Ìý

What we did talk about a little bit is, if you do no estimates from the beginning, when you're in the middle of norming and storming your team. That is actually a bit more difficult as we see because again, you don't have that standardization of what a story is and whatnot.

Ìý

Scott: I think but that people overlook one of the benefits of estimation, which is understanding things better and picking it apart and doing-- That's where the analysis or at least some of the analysis takes place, I think. I think people underestimate how much their rapport has evolved over the course of a project, that it's allowed them to maybe get away without doing that as much.

Ìý

Neal: It's one of those incremental things that you do estimates for a while and you get that synchronicity that Cassie's talking about, both with other developers, but also the problem domain to Scott's point. You can have a business analysts say a five-word sentence, and you understand what it's going to take to do that. Whereas if it's a brand new problem domain, it's all, I don't even understand four of what those five words mean yet. [chuckles]

Ìý

There's no way I can give-- Just go off and start coding on that. This is one of the tricky things is that teams get to that space very slowly and incrementally, and they don't notice it's changing. At some point they just say, "We don't need estimate. Nobody should do estimates because it's not useful," but that's not true. It's not for them anymore because they've matured slowly to that place but it's hard general advice to give. What were some of the other more entertaining estimation tricks that we heard about? [laughs]

Ìý

Scott: There was the three-letter acronyms where there was only three. If I can paraphrase, was it-- I know one was, I have no idea. We'll say that politely. The other one was way too big. Also, said politely. What was the third one?

Ìý

Neal: I think the other third one was just right or something or one day or something very small scope. Basically, this estimation technique that they were talking about, that's being used successfully apparently on at least a couple of projects I think in the UK, was that rather than this t-shirt sizes or Fibonacci or all the different things that we've done, is basically just three things. It's just right, it's too big, or it's insane. Basically.

Ìý

Punit: Actually like that approach, although we don't use it on our team. I like it because it's general, like Fibonacci can be different for every team. Like what that number means, what one means for one team is going to be one or totally different for another team. Whereas this is pretty general. It's like, that looks big, that looks too small, or this is just like-- Those are general terms that I think most people can grasp very easily and so it's easy to use those in just regular conversation.

Ìý

Cassie: I really love this one actually, because we've talked about throughout the week is getting to root causes of why we do the things that we do. I think sometimes, especially with estimation, Fibonacci, and all of these things, we have all these processes that actually teams may forget why we have these processes. It's like I do Fibonacci and that's what I know and that's what I learned. It's like, do we ask the questions of why?

Ìý

This goes back to the root of we're actually trying to just gauge a story to see if it's too big and we need to go and collaborate and find out more information. That is the root of why we're trying to do that versus I have no idea. [chuckles] If I have no idea who are the folks, who are the domain experts that we need to go and talk to to get more of an idea. Then of course, when it gets to just write, "All right, well, we can start working on some things," which is really wonderful.

Ìý

I think I like this a lot because it gets back to the roots of why we originally started the whole process of estimation and trying to track how quickly we can get work done and things like that.

Ìý

Scott: I think part of it is the reason people look for alternatives is this endless temptation for stakeholders or customers to translate points into dollars and velocity into productivity. We know that that's not what we're doing when amongst the team, but it sure looks like it from the outside, and then that puts pressure in the wrong places.

Ìý

Punit: Probably where the numbers are. Numbers mean different things to other people. They'll just use it in whatever conversations they might be having, in whatever things that they might be doing, but they mean totally different things to both parties.

Ìý

Neal: That allows us to put a positive spin on this toward Casie's point. It's easy to fall into cargo culting stuff. It's like, "Oh, I've read about this and this seems like and we'll just do that." That seems to work, but I think the good part of the pandemic, and that's putting a positive spin on this, is it's forced us to rethink some of the root causes of why are we doing this and is there a better way to do this?

Ìý

We've come back, should we do estimations the same way or should we do collaboration the same way? One of the things I talk about is the out-of-town consultant effect which is the idea that if a consultant rides in an airplane to get to a meeting, they automatically have more credibility than people who rode in a car to get to the same meeting.

Ìý

The longer you flew, the more credibility that gives you, but there is actually a good reason for the out-of-town consultant effect. It's the boiling frog thing that everyone's familiar with that was in The Pragmatic Programmer book and which turns out to be apocryphal because the story goes, if you want to cook a frog, you put it in a-- If you just throw him in a pot of boiling water, he'll hop out. If you put him in a pot of cool water and turn the heat up slowly, it'll boil without realizing it.

Ìý

It turns out that's not true. Frogs are not that stupid, but large enterprises are that stupid. You constantly fall into this boiling frog problem of, "Oh, we're doing that because that's always the way we've done it." The real benefit of the out-of-town consultant is they come in and look around and go, "You're boiling, look, you're frog is boiling." It's like, "Hey, you're right. We didn't even realize."

Ìý

That I think is one of the benefits of coming back after the pandemic, is looking at all this with fresh eyes and saying, "Hey, what have we been doing?" That's just habit versus rethought. Come up with a much better way to do that and maybe take some beneficial things out of these two years of annoyance versus just annoyance.

Ìý

Scott: It certainly challenged us because Thoughworks co-location has always been really central, a really closely held value, I think that and people need to travel to be together to get the best outcome. Then that's what we did. We've realized, man, it's not always true. Maybe we can get away that, so much of that.

Ìý

Neal: It was very intense in the first few months of the pandemic though, trying to figure out all these things that we had since day one had done in-person, including all of the Radar stuff that we've claim could never be done remotely. Yet we've had to figure out a way to do it. Exactly at that point, there are a few things that we picked up during the Radar process that remote that we're going to keep moving forward as we start gathering again.

Ìý

I think that's a good takeaway from this is, use this as a way to look more objectively at what you're doing and incorporate the improvements and ditch the annoying requirements. Any last words, piece of advice, or observations anybody want to provide? All right.

Ìý

Scott: It was nice to travel for the first time in two and a half years.

[music]

Ìý

Neal: Yes. It was quite the relief to actually get to do a face-to-face Radar meeting. Both here and in Hamburg, we have two small pods that actually got to gather face to face and actually eat out together in a restaurant, which is quite the treat. Thank you all for joining us today. It's a great insight and a great observation of this snapshot and important time. Thanks and we enjoyed the conversation.

Ìý

Participants: Thank you.

Ìý