Situation: Team lead graduated from the company and previous team practices, i.e. scrum and retrospectives, are also discontinued since no one stood up to the position. Now, team is less enthusiastic and juniors feel helpless at work. I figure this is the time to act but is clueless on what or how to.
What practices can you advice to improve team work?
Revamp scrum and retrospectives? Truth is, I am not a fan of scrums since I am not good at interruptions. Gotta confess that one day, I proclaimed, "Let's not have scrum today" and so it was set on stone. I am thinking that maybe we are losing the true essence of these practices. Its not just a group of devs waiting in turn to say their tasks for the day, isn't it? Please enlighten us on these.
I'm also thinking of mentoring sessions, though I suck at that, but I strongly think it will help the team. Its a hurdle. So please can you also advice on mentoring, pair programming and such.
Leadership sure is hard.
Thanks in advance!
Top comments (6)
Congratulations/condolences. I've been there; it does get better 😃
Standups are ideally a bunch of devs -- and QAs, and UX/designers, and someone representing the client you're working on the thing you're working on for -- waiting in turn to say what they did yesterday, what they're going to do today, and if there's anything preventing them from making progress. As team lead, it's your finger on the pulse of the group's activity. There are other ways to get that information, but most of them in most circumstances will be less efficient than spending fifteen minutes in the morning having it out. If someone is blocked, not only do you know about it within 24 hours, the rest of the team hears it too, and can help address the problem. I'm afraid there is no getting around being assertive: if someone starts getting into the weeds, it's your job to prevent them from wasting the entire team's time and making everyone hate standups. Figure out who they need to talk to and make that happen outside the meeting.
The former lead's departure has disrupted your process and, if they knew the codebase well, more. Expect some instability and less getting done while you all adjust. Your #1 goal is to keep everyone moving. Make sure your developers have clear requirements and designs and as few interruptions as you can manage, nudge people to pair up to get them familiar with different parts of the codebase, deploy regularly so QA and UX can stay on top of things, and work with the client to plan out the future: features may have to be cut and dates may slip in the short term, but you need to know what's coming further in the future as well.
Kent Beck's eXtreme Programming Explained is a very good resource even if you don't do XP. Expect not to write much code for the next little bit. You'll be tempted -- I'm guessing you (like me) aren't exactly a social butterfly -- but the most important work you do over the next few months is going to be on people and teams, not bits and bytes.
Once you've gotten things more or less back on track, or if the company wants to make the team lead position official (whichever happens first), gun for a substantial raise.
Wow thanks! Gonna look into that reference. Yes, I'm not really into people. That's why I avoided the position for so long but now can't. This is a problem I have to face. As much as I want to code, I have to help the team funtion or there will be no team. I really hope it does get better.
To get scrum to work stay focused on immediate tasks and roadblocks. The only topics should be what was done, what will be done and what roadblocks there are to getting stuff done. Anything else is off mission so nip it in the bud. Some teams have "safe words", like "Squirrel!", to indicate when someone is going off topic or rambling.
Don't get bogged down in technical details. If someone needs some help, assign someone to help/mentor them and move on. Don't use the scrum to do that. If the majority of the team is need to work out a problem, schedule a separate meeting to work on it.
Keep it short as possible. Just because you blocked out 15 minutes doesn't mean that you have to use every minute of it. There is the temptation to fill in the space so don't give into it.
Hold the scrum away from desks, offices meeting rooms and even white boards. This will keep you standing to keep the meeting short and avoid distractions like "let me just show you on my screen" or "let me draw it out" or "does the projector work?". For example, at one company we held our scrum in the break/coffee room or on an outdoor patio (weather permitting). One big drag I've seen on these meetings are ones where the lead brings up the project management software on their PC and walks through the sprint.
If people don't show up, which can happen due to unavoidable things like traffic and so forth, just keep going. Don't wait around, just get it done. They can fill in the team later via email if they need to. If people are intentionally tardy/absent frequently, then some additional measures may needed to get better cooperation.
Don't waste time doing a recap email or the like. I've had some managers insist on this kind of thing and it is a micromanaging waste of time.
Don't do scrum if there's no purpose in it. For example, a team that's primarily maintaining and supporting deployed applications may not need a daily scrum since they really aren't in a focused development sprint where tight team collaboration is needed. Everyone may be working on mostly unrelated tasks. A simple emailing of roadblocks to the team may suffice in this situation.
Thanks! I love the safe word. We just had a scrum today but was more like a project status update. And since not all are working in an active project, like me, some are less cooperative. It's hard to lead when you're one of the uncooperatives really. I will discuss with my fellow seniors on this. Obviously we have different definitions and intentions on this scrum. Thanks for the input.
Definitely keep up pair programming. From my experience, it's very effective.
That said, there are some gotchas:
Pairing around 60% to 80% of the time works pretty well, from what I can tell.
For you personally, it will be much less, but make sure that you don't separate completely from coding for a prolonged time. You could focus on pairing with juniors.
Besides that, some general ideas:
Have (regular) 1on1s with every single person in your team. Talk about their expectations, wishes and most importantly, listen. This will allow team members that are less vocal to get a voice
Get someone to organize a team event. Maybe an escape room, some other activity or just a plain dinner.
Thanks for the advice. I am always wary of spoon feeding solutions to others that sometimes I think I end up being unhelpful at all. Former team lead once said to me that if she's going to answer me better if she'll do task instead. In which I agreed, than spending both of our efforts in it. I always go back to this thought whenever. I wonder if its a good thought to bag.