This is a transcript. For the full video, see The human side of agile software development: Managing diverse remote teams: Pts. 3 & 4 - Tag1 TeamTalk #025-26.
Preston So: [00:00:00] Hello. And welcome back to the fourth and final episode of our mini series with our special guest Janie Ledet. This is our Tag1 TeamTalk episode on Managing Diverse Remote Teams. The final installment of our four part series on diverse remote teams. I'm Preston So and I'm the editor in chief at Tag1. I'll be the host of today's episode and I'm joined today by our special guest Janie Ledet. Based out of Fort Collins, Colorado, my home state, project manager and scrum lead at Tag1, volunteers for nonprofit organizations that teach girls to code, and also has a very long and fascinating background as a software developer, project manager and program manager on all sides of the equation at HP for over a decade, working on customized Linux distros and 3D graphics card integrations for high end workstations.
We're also joined today by our dear colleague, Michael Meyers, managing director at Tag1 currently based in the Berkshires in Massachusetts. And without further ado, let's go ahead and get started. So, Janie, I mean, talked over these last three episodes about really diverse topics.
You know, first we got to know you. Then we got to know about a little bit about why experienced project managers are so important to software development teams. And then we talked about the CARE philosophy and how that figures into managing high functioning, remote teams. I want to talk a little bit more today about kind of the practical applications.
We've talked a lot about the theory about the methodologies, but let's talk a little bit today about tools and lessons learned and best practices. So from, from your background and from your, long and storied expertise, as a, as a project manager, what are some really great best practices that you would recommend for folks who are interested in getting more involved in things like scrum or things like the CARE philosophy or, or a lot of the other things that you mentioned around, really focusing on diverse remote teams?
Janie Ledet: [00:01:53] Well, Preston, let me start with giving a little context for how we at Tag1 do, how we work as a consultant company to give people a little bit of a context for how I'm applying these different terms. So we, we develop websites and web applications, largely using. Drupal, but also using various other technologies.
And so the way that we work is we have global teams, people from all over the world, working together, we don't have a physical office. What we do is we work with various companies all the way from small, very small groups, to huge enterprises and small nonprofits. So there's lots of different folks that we work with.
It's always different and exciting. but our typical process is we have a contract that we set out with a client. We do some discovery to really understand what it is that they need. And then we form a development team with the skills needed to implement it. And then we launch by a deadline and we keep track of billable hours as we go so that we then charge that back to the client.
Some projects are different, but this is typically, often the way we work. so then the next layer of that, I often have my teams use agile and scrum practices. so we focus very much on having a growth mindset and quickly providing a functioning software that provides value to end users.
And then also having self organizing teams who are empowered to figure out how they're going to solve the problems on their own. And then I just kind of stand back and support. Something that we do a little bit differently, since we're not in person teams is, we've developed a practice call that we call scrum light and scrum light is that same traditional, agile and scrum mindset, but done in ways that are a little bit more asynchronous. So, so we, for instance, do Slack standup meetings, instead of having a phone call where everybody's there, sometimes that doesn't work because I've got maybe a team member in Europe and another one in Taiwan and another one on the East Coast and another one on the West Coast.
So we can't necessarily every day have a stand up call at the same time. So what we do is we just post in our Slack instant message board. Here's what I worked on today. Here's what I'm working on today. Here's what I did yesterday. Reach out for some, collaboration, you know, I need team input on A,B and C.
I'm going to be out of the office on Friday, so please contact me, those sorts of things. and then another thing that we do is we, when we do have teleconference calls, we document everything. We use Yjs or Google drive docs to have everyone participate in typing in content, real time, as we're collaborating, we limit meetings to small groups so that we don't spend a lot of billable hours having meetings.
We have short meetings, you know, if the purpose of the meeting is to make a decision or have a group discussion, we have it quickly. Everyone comes prepared to contribute. And, we have really fast meetings. This works well for folks who know the process. Well, I wouldn't necessarily recommend it for teams who haven't worked together before, because we shortcut a lot.
But it is a really efficient way to get work done. Another practice that we found to be really helpful is to use icebreaker and humor to get to know each other quickly, because we only have a few minutes at the top of meetings or asynchronously through our instant messenger to really get to know each other.
So having people, maybe post a picture of their pets or answer questions like, what is the most, what is your favorite thing that you've purchased this year helps people to get to know each other and really make that personal connection. Another of my favorite practices is including kudos, during our scrum sessions.
So having team members recognize each other when they notice that someone else has done something really amazing or gone above and beyond. Another practice that we use is, two weeks sprints and having demos every two weeks. but we tend to like to start on Thursdays, start and end on Thursdays instead of Fridays, just because Fridays tend to be days that people take off. And, it's helpful to have some time before next Monday to really get into the flow of what steps are we going to do next? What do we need to do as far as planning our goals for the following week? Along those same lines. We have kind of an unspoken rule for a lot of the projects that are run, where we have no meeting Fridays, so that developers have a chance to really have some focus time instead of having their day, context switching between meetings and development time.
And then I've mentioned previously, we always have the mindset of sharing back with open, open source communities, leveraging what's out there and then sharing back so that others that have the same problem can build upon it and help maintain that code.
Preston So: [00:08:31] Well, I can certainly, you know, see, see myself thinking back to a lot of the project teams I've worked with and, and thinking, wow, it would have been really nice to have something like kudos or no meeting Fridays.
So, you know, great inspirational, you know, suggestions and ideas that a lot of teams I think would benefit from, around the world who are. Especially for the first time, as we mentioned before, dealing with remote work in a way that they might not have a lot of experience. So to that end, yeah, actually about remote work and about, distributed teams in particular, you know, in the midst of this COVID-19 pandemic and in the midst, you know, the fact that all of us are in our separate homes, You know, it's not just about building up those best practices and about those procedures and processes, but also about the tools and the, and the various technologies that we use to collaborate.
I'm kind of curious, you know, from your perspective, Janie, what are some of the most important tools that any high functioning, remote team should have?
Janie Ledet: [00:09:28] So there are lots. Yeah, so I've talked to a bit about soft skills, but the scientists and developers want you to figure out, okay, what are the tools we use?
How does that, how do I actually make that happen? So, one of the things I like to do at the beginning of every project is create a team charter and have agreement on what is the definition of done. The team charter really helps the team come to a consensus about how they collaborate and in that document is where we decide which tools we're going to use.
[00:10:07] Some of the ones that I would recommend, especially if your primary communication method is asynchronous are Slack. As I've mentioned before, for every day, conversations, everyday collaboration, And that helps to kind of follow the sun. Right. I might suggest something in Slack and, I wake up the next morning and not only has someone else listed ideas, but another team member further down the timeline has already put the process into place.
[00:10:41] So I wake up and, Oh, the seed that I planted before I went to bed is already happening when I wake up in the morning, And then another thing is if it's possible to send an email and instead of having a meeting, send email or use the document, I try to minimize the number of meetings that we have, but there are some times when a meeting is essential, it's maybe quicker to hash out.
Or have a brainstorming session and decide how we're going to tackle some things as a team. If you have a quick phone call, So just, really, using discretion for when you do that. and then some of the, instead of doing phone calls, we often use Zoom, but I always have a backup plan so that if.
[00:11:29] For some reason, the primary tool fails, then maybe we'll use a different tool. Maybe we'll use WebEx or maybe we'll use Hangouts. always have a backup plan for if the meeting gets cut off, where do we jump to as the alternative? Some other tools for communication are having a stakeholders list.
A contact information list where, where everyone says, here are my normal working hours, here are the best ways to contact me. Also having an issues and decisions list, so that it's really clear. We have a record of, what, what did we decide so that when there's conflict within the team or there's, we're trying to decide, how to move forward. We can reflect back on, wait, what did we decide around that topic? And there's a record of it and that's been really helpful. Also there are so many different, project management productivity tools. There are really complex ones like Atlassian tools or really simple free ones like, using a Trello Kanban board.
[00:12:46] I think it doesn't matter so much the tool that you use, as being consistent and making sure that everyone in your group has access to it. and I'll share in the links, several different tools. That can be used for that. one of my favorites that I've been using a lot recently is the GitHub project management tools.
They've got a really slick agile board that connects to your GitHub tickets. And my teams like that a lot. So some other tools I've been using, the status clock app. I put that on my Mac iOS taskbar and it shows me what time it is in UTC. And that just helps me kind of zone back to, okay, what time zone is it when I'm setting meetings? There's also www.timeanddate.com world clock converter, which helps me make sure that I choose times for meetings or collaboration sessions that work for everybody. No matter what time zone they're in. Another thing that I do is instead of using traditional retrospective meetings, sometimes I will just send out a poll.
Now here's the, here's the feedback I've heard, team take 60 seconds to vote for the thing that you want to improve during the next process. And that's a really super efficient way to make sure that we have continuous improvement, but not spend a lot of meeting time on retrospectives. Another thing that we do, another practice that we have, we use weekly zoom meetings, sometimes, or sometimes we do, Recordings.
[00:14:37] So not everybody can necessarily make it to every meeting. So what we do is we record the call so that people can listen to it afterwards, if they just need to be informed of what the team was talking about versus, being part of the. The decisions or discussion that happened at that meeting. so we share the recording and then we also make sure that we share back to the Slack channel.
Here were the key takeaways. So instead of sitting through an entire hour long meeting, someone could just look at the quick takeaways and know what was discussed or what was decided that is pertinent to them. Yeah.
Preston So: [00:15:16] No, I was going to say, you know, I think those are all really, really good, wonderful tools. And, you know, we've obviously discussed a lot of the collaboration tools. You mentioned GitHub projects, which I think is a great project management tool as well. There's also plenty of prioritization tools out there in the interest of time though, because we are running out of, out of our time today.
I wanted to jump just a little bit ahead to a little bit more of a reflective topic, which is, you know, beyond the practices and the processes and the tools and technologies. there's definitely a running thread throughout all of this, this, this kind of mini series that we've been doing, which is the human aspect of software development projects.
[00:15:54] And so I'm curious, you know, as we revisit it, This duality between the humanity and the mechanical nature of software engineering. I'm curious, what lessons learned. You have Janie as a human working in this very machine oriented world. What are some of the lessons that you would share with our audience today?
Janie Ledet: [00:16:14] Sure. Happy to share so that people can learn from my experiences. One of them is to include QA, right from the beginning. Always have a QA folks and start thinking about testing right from the beginning of the project. Another thing that comes up is over-communicate a lot of times when projects go sideways.
[00:16:36] It's because of a misunderstanding. So I always try to share information, set expectations with everybody, and just really make sure that everybody's updated, and included in decision making processes. It's also really important to set boundaries for when and how we communicate with each other.
So around work life balance, just making sure that, It's one thing for me to say to my developers, you're not required to work late. You're not required to respond to messages immediately, please, you know, stick to your normal working hours of we respect your schedule. But if I, as a manager, am responding to every message, like at 11:00 PM or super early in the morning, That model is a different behavior than what I'm saying.
[00:17:30] So I think it's important for leaders to model what they want, others to behaviors that they want others to reflect. Another thing is to end meetings five to 10 minutes before the hour to allow for breaks and transition times. Sometimes we over-schedule ourselves and that has been something that is really helpful.
Another thing is to be aware of your partner, your partner's security policies. So we work with clients who are very, very, security conscious, just making sure that we're using secure tools, using things like two factor authentication, and just really, Adhering to those policies, to make sure that we protect information.
Another key takeaway, a key learning for me has been to really focus on the team's flow. This is the number one thing to me that helps improve a team's ability to be a high functioning team. make sure that they have clear goals. Everyone knows their role on the team. we've got tickets in the backlog that have really clear success criteria so that a team member can know.
[00:18:59] Always what's the highest priority thing that I can pull from the list and start working on right away and then have time to focus on that and not be overloaded, make sure that they understand, that you balance well, how many things you're working on at the same time. and, then the other thing, kind of on that same theme is.
[00:19:25] Clearing blockers working as a team together when there are things that you're slowing us down, often not just me is the scrum leader, but also my team leads or other developers will have ideas for how to, to make things flow more smoothly and just always, listen, listen, listen, listen, and take input from the team on how can we collectively improve as a group.
Preston So: [00:19:56] So, and, you know, as, as somebody who, who really, you know, you know, I try to optimize very often for a flow. So, you know, the notion of flow and a notion of clearing blockers and the notion of, of, of, of really managing those smaller sources of friction really resonates with me. And I think it does with our audience as well.
Well, Janie, thanks so much. You know, we do, have, only a little bit of time left. And in that time, I do want to say once again, that we're going to have all of these resources that Janie mentioned, she's got a big list of books, the big list of resources for our audience. there'll be posted online with this episode.
And if you like this episode, please remember to upvote, subscribe, share it with your friends and family. Check out our history of past talks at tag1.com/tagteamtalks . We'd love your feedback and any suggestions for guests or for topics. Write to us at tagteamtalks@tag1consulting.com.
Thank you to all of our viewers, our listeners today for joining us. And also thank you to Janie Ledet and Michael Meyers for joining us on this four part series about managing diverse teams. Thank you so much.