(almost) All shades of leading agile teams

I love sports analogies. I have one for almost every occasion and to be honest it really gets to people even if they don’t follow particular discipline. Here’s one:

There is no “I” in “Team”

said Shaquille O’Neal to Kobe Bryant accusing him of being selfish on the court.

No, but there is a M-E in that, mother%&#@er

replied prematurely deceased Bryant (R.I.P.).

Both of them are considered great players and have led their teams to multiple championships. At the same time, both of them dominated the game absolutely, beating individual records in the league. So yes, it is possible to do both leading and playing for the team. If they could do it, we can at least try, right?

Last one (I promise) basketball reference: “You can’t teach height” sais old dictum. In my opinion it’s a bit similar to leadership skills. Some have it naturally and no matter what they do, others follow. Some don’t have it at all and you can’t just teach them doing it. But what you can do, is to teach them responsibility. And that’s where it all starts.

Because being a leader means taking responsibility for the cause and for the team. It doesn’t really matter how. There are many ways to do it, for sure. It depends on what environment you’re in and what your goals are. For example if you’re a member of the Scrum Development Team, your goal is usually pretty simple: deliver a working piece of product. But is it really that simple? Let’s not get into technical or business challenges. Let’s focus on effectively working teams of developers which is a necessity for any successful organization. There are only devs in that team, no other roles or positions. Scrum guide sais it very clearly. But there are always leaders, believe me! I’ve been scrum master for many years now, so I know. And many times these leaders are devs with the biggest technical knowledge or experience. Not necessarily the ones with leadership skills. And that’s perfectly fine. But especially as a Scrum Master, you should work with them to make sure they understand what does it really mean, to lead others.

Responsibility is the key. When you grow older, have kids, a sense of responsibility for others comes naturally. In the Polish IT sector, there are not so many programmers over 40 years old. At least not as many as in other countries like Germany, the UK or Canada. One of the reports I’ve read says that only India’s programmers are younger than polish (average age 25.9 and 28.4 accordingly). I’ve worked with many seniors before their 30’s which proves that data right (from my experience at least).

Hero

The most common anti-pattern I’ve come across (let’s call it a hero type) is that being a leader means taking all the heavyweight tasks on your shoulders. Maybe in the short-term it makes things go quicker but in the long-term it makes no sense, because other guys need to challenge themselves as well. That’s the only way to get better at whatever you do. Also it doesn’t help with sharing knowledge across the team which is crucial for long-lasting teams.

Shot caller

Another one I know from experience is the shot caller. So this one will tell everyone else what to do and how to do it. His solution is the only right one and he will make sure, everyone gets that. It’s against all Scrum principles, so let’s just skip to the next one.

Frontman

This one is tricky. He’s the face of the project. He makes sure he is present at every meeting and usually tries to conduct those. Doing demonstration sessions (including Review meeting) for the client and volunteers for pretty much everything. Speaks a lot during Retrospective (usually for others as well). In general not as debilitating as hero type, but leaves no space for others. And that’s bad. There’s so much more to do besides writing code. All members need to take part in that.

Silent type

Similar to shot-caller but with no need to rule others. Focuses on technicalities, doesn’t care about anything else. Usually very good at what he does. Estimates tasks by himself, tells everyone what solution team is going to implement (with no explanation) and goes to his cave (with a headset on) for the rest of the day. It’s hard to learn anything from such person whilst leading people (in this case anyway) is to let them grow.

Summary

True leaders make everyone around them better. That’s how I see it. And that’s what I try to teach others. Sometimes it means pushing people to their limits, sometimes all it takes is to tell them “good job!”.  You don’t have to be any of the types I described earlier to be perceived as a leader, to have an influence on others. Au contraire! You can do it from the back seat. You can be the voice of reason who everybody’s listening to. Your teammates will know your intentions soon enough. And that’s when they’ll start to follow. In their own interest and in the interest of the cause.

I’ve had a conversation with one of our senior developers recently about leadership in a scrum team. My advice to him was the following: help the team to set up everything in a way, that when you’re gone (from the team), it doesn’t make that big of a difference.

Being a leader is not something you can learn from the internet. But you still can become one. By doing the best you can. By helping others. By being patient and paying attention to details. By respecting other opinions. By getting things done. By stepping up for yourself or the team when it’s needed. By following scrum values in day-to-day work. And finally: by being yourself!

By the way, it’s also good advice for all scrum masters, who by definition are servant leaders.

If you agree, disagree or have any other thoughts on leadership in an agile environment, do not hesitate. Write to me!