Even in what I still consider to be my infant years of being a web developer, I've been pushed into many roles that demand going beyond what I would consider a developer to do. Where I work, we employ the use of Agile Scrum, which I believe is a pretty awesome tool for getting work done in iterative steps that ultimately delivers a better product in the end. But, I'm not really here to talk up development methodologies at this time. Rather, I'd like to discuss a specific role within Agile Scrum: the Scrum Master. I often feel myself being gravitated to filling this role on my team and would like to share some of what I glean from performing duties of the role while still being primarily a developer.
What's a Scrum Master?
Scrum Masters play a pretty interesting, yet vague (and important!), role on a team that employs Agile Scrum. They're tasked with removing obstacles for the team they work with and promoting the use of other Agile Scrum practices. They're the go-to person when a team member is having trouble with team-centric issues. But while studying how other Scrum Masters [within the company] who actually bear the title use the role, I feel there's a misrepresentation of what this person is supposed to accomplish. I'm going to rattle off some scenarios that outline the items I'd like to discuss to give examples of the problems I'm seeing within my own workplace to help bridge the gap between real cases and (hopefully helpful) takeaways.
Observation
Case 1:
The first thing I occasionally see someone do is act as a filter. In theory, this sounds like a good idea. The less your team has to think about outside the actual development of a product, the more they can concentrate on...well... developing the product. The dangerous part about this is not observing where the team you're working with is at with communication between other teams and departments. Imposing a filter could hamper the progress more than help if you're interjecting an already working line of communication. I think there is room for filtering, but this can't really be done until observation of the team has been done.
Takeaway 1:
The above is just one example where not observing your team can lead to potentially harmful decisions as a Scrum Master. If you start imposing rules and patterns as soon as you jump into the role (or any role really), you're naturally going to infringe on how the team is already getting work done. This is simply unavoidable. If you've just been placed on a team looking to improve themselves, watching them should be the first item on your checklist.
Before acting on any existing pattern, see how they function without you. Find the existing communication channels, find the existing patterns, find the existing relationships and see how you can improve upon what is already working. Now, no team is doing everything right. Especially teams with nobody actually looking for their flaws. But knowing who you're working with on a micro and macro level will help you make informed decisions rather than hasty ones. After all, no team is the same, and even if the last thing you did with your last team worked perfectly, it is highly likely that it will not work in this team's case. Be patient, be observant, and work to improve, not revolutionize. I guarantee your team will be better for it.
Cross Functionally Dysfunctional
Case 2:
Agile Scrum is a proponent of team cross functionality. In short, all members are, at least to a small degree, able to perform each others' roles. A Scrum Master can take advantage of this to talk to just about anyone to get a better understanding of the current team environment. A downside here is that it can potentially open up broad communication channels with people who aren't necessarily best-suited to answering their question. For example, you may be comfortable talking with one person over another, and glean most of your knowledge from that source. While cross-functionality helps back that act as legitimate, one needs to be both fair in assessing a situation and capable of pulling together the best minds to tackle specific problems with efficiency.
Takeaway 2:
Just a shameless plug for Agile Scrum, this is one of my favorite aspects of it. I love being able to jump into conversations that don't necessarily involve programming all the time. This really helps bring out ideas from people who you normally wouldn't go to for direction. For instance, my team's QA Analyst turns out to be a fantastic UI Designer. I, coming from at least some video game development background, have an eye for User Experience that nobody really has on the team. But, every rose has its thorns as they say.
As a Scrum Master, you shouldn't limit who you talk to just because everybody can know everything. The short truth is that, while there's potential for it, most of the time the person you're comfortable talking with will not have the full understanding that the team's expert in that area has. This kind of channel can lead to miscommunication and essentially just delegates the Scrum Master job of opening effective communication channels, resulting in them doing the legwork to get the answer you're looking for on top of their role obligations. This just isn't right. Just because your team is cross-functional doesn't mean there aren't experts. Know your team and find your experts. Get the right information from the best sources and inform the team afterwards. You've done the legwork no one has time to even consider and kept information flowing as a result. You might even find some team members are very passionate about certain work that no one knew about before, ultimately helping the team better understand each other and opening potential new communication channels along the way.
Leadership vs. Management
Case 3:
At my workplace, it is actually rare for a Scrum Master to have recently come from a development role. This role is usually taken by people who are supervisors or managers. Not to say that these people are ill-suited to being a Scrum Masters. They're already good (or at least experienced if not good) at working with people. The pitfall here is that supervisors and managers are not, by definition, people who facilitate teams. This is an important distinction to make in that Scrum Masters should know how to facilitate individuals (manage) and facilitate work (supervise), but combine the two by facilitating individuals who work as a unit. Too often I see Scrum Masters who come from the aforementioned roles and concentrate too much on what they know without learning what it takes to lead a team rather than a person or a work-flow. They miss the proverbial forest for the trees.
Takeaway 3:
The title for this section might sound a little misleading, but I usually find that a Scrum Master is kind of a figurehead for the team they're on. What's interesting here is that I find the Scrum Masters I enjoy watching tend to lead from the shadows. This actually makes a lot of sense when I think about it. A Scrum Master will observe a team and find its strengths and weaknesses. They introduce small changes over time that get the team working as a more polished unit. All the while, their vague role really has nothing to do with any of the designing, coding, or testing. They never really spearhead a development effort. They only need to allow people to rise to the occasion and spearhead the initiative themselves. Ensure the team knows each other well enough to put the right team members in the right spots at the right times. Since the Scrum Master isn't actively leading these efforts, its hard to see the development they've been doing all along: team development.
When a person tries to establish themselves as the pinnacle on a team, as a manager or supervisor usually should, this gets in the way of letting the team become self-sufficient. There's the illusion that this person is the one everyone reports to, but this is not a Scrum Master's role. While needing to be an exemplary leader in their own right, the greatest Scrum Masters are, to me, the most humble. They assume a heavy responsibility of making a team the best it can be while putting the team in charge of their efforts as much as possible. The brand of leadership that Scrum Masters need to be good at is one of enablement, not one of individual growth or maximized work-flow efficiency. We already have managers and supervisors, respectively, for those parts of an organization. Lead from behind the scenes and watch your team blossom. Even though I'm not a Scrum Master in title, when I see my team succeed, it fills be with great joy to witness that. Knowing the little things I did, while largely unseen, helped them get there... that's what the role is all about.
Harvesting the Knowledge
Now, these three points are only scratch the surface of what paths and pitfalls a Scrum Master may encounter. They are just ones that I see fairly often, and have given some thought to as far as escaping the pitfall or maybe even avoiding it altogether. They're really more like principles than strict actions because every team is different. The things that I do to help my team be the best team they can be may not work for your team. I do think, however, that these guidelines can help new (or even active) Scrum Masters approach their role in new and better ways.
If you find yourself in a similar situation to mine, being the communication guy between a bunch of seasoned developers, hopefully these tips help you get the information flowing. And for any seasoned veterans, maybe there's something in their you can glean from a beginner, an outsider looking in. And for everyone, remember that growing a team takes a lot of time and unseen effort, but the pros of having someone looking out for the health of a team can truly be immeasurable when employed well. While the effort may be hard to track, it is most certainly a boon. There's a great Futurama quote that captures this quite nicely, and I'd like to end on it:
“When you do things right, people won't be sure you've done anything at all.”
What's a Scrum Master?
Scrum Masters play a pretty interesting, yet vague (and important!), role on a team that employs Agile Scrum. They're tasked with removing obstacles for the team they work with and promoting the use of other Agile Scrum practices. They're the go-to person when a team member is having trouble with team-centric issues. But while studying how other Scrum Masters [within the company] who actually bear the title use the role, I feel there's a misrepresentation of what this person is supposed to accomplish. I'm going to rattle off some scenarios that outline the items I'd like to discuss to give examples of the problems I'm seeing within my own workplace to help bridge the gap between real cases and (hopefully helpful) takeaways.
Observation
Case 1:
The first thing I occasionally see someone do is act as a filter. In theory, this sounds like a good idea. The less your team has to think about outside the actual development of a product, the more they can concentrate on...well... developing the product. The dangerous part about this is not observing where the team you're working with is at with communication between other teams and departments. Imposing a filter could hamper the progress more than help if you're interjecting an already working line of communication. I think there is room for filtering, but this can't really be done until observation of the team has been done.
Takeaway 1:
The above is just one example where not observing your team can lead to potentially harmful decisions as a Scrum Master. If you start imposing rules and patterns as soon as you jump into the role (or any role really), you're naturally going to infringe on how the team is already getting work done. This is simply unavoidable. If you've just been placed on a team looking to improve themselves, watching them should be the first item on your checklist.
Before acting on any existing pattern, see how they function without you. Find the existing communication channels, find the existing patterns, find the existing relationships and see how you can improve upon what is already working. Now, no team is doing everything right. Especially teams with nobody actually looking for their flaws. But knowing who you're working with on a micro and macro level will help you make informed decisions rather than hasty ones. After all, no team is the same, and even if the last thing you did with your last team worked perfectly, it is highly likely that it will not work in this team's case. Be patient, be observant, and work to improve, not revolutionize. I guarantee your team will be better for it.
Cross Functionally Dysfunctional
Case 2:
Agile Scrum is a proponent of team cross functionality. In short, all members are, at least to a small degree, able to perform each others' roles. A Scrum Master can take advantage of this to talk to just about anyone to get a better understanding of the current team environment. A downside here is that it can potentially open up broad communication channels with people who aren't necessarily best-suited to answering their question. For example, you may be comfortable talking with one person over another, and glean most of your knowledge from that source. While cross-functionality helps back that act as legitimate, one needs to be both fair in assessing a situation and capable of pulling together the best minds to tackle specific problems with efficiency.
Takeaway 2:
Just a shameless plug for Agile Scrum, this is one of my favorite aspects of it. I love being able to jump into conversations that don't necessarily involve programming all the time. This really helps bring out ideas from people who you normally wouldn't go to for direction. For instance, my team's QA Analyst turns out to be a fantastic UI Designer. I, coming from at least some video game development background, have an eye for User Experience that nobody really has on the team. But, every rose has its thorns as they say.
As a Scrum Master, you shouldn't limit who you talk to just because everybody can know everything. The short truth is that, while there's potential for it, most of the time the person you're comfortable talking with will not have the full understanding that the team's expert in that area has. This kind of channel can lead to miscommunication and essentially just delegates the Scrum Master job of opening effective communication channels, resulting in them doing the legwork to get the answer you're looking for on top of their role obligations. This just isn't right. Just because your team is cross-functional doesn't mean there aren't experts. Know your team and find your experts. Get the right information from the best sources and inform the team afterwards. You've done the legwork no one has time to even consider and kept information flowing as a result. You might even find some team members are very passionate about certain work that no one knew about before, ultimately helping the team better understand each other and opening potential new communication channels along the way.
Leadership vs. Management
Case 3:
At my workplace, it is actually rare for a Scrum Master to have recently come from a development role. This role is usually taken by people who are supervisors or managers. Not to say that these people are ill-suited to being a Scrum Masters. They're already good (or at least experienced if not good) at working with people. The pitfall here is that supervisors and managers are not, by definition, people who facilitate teams. This is an important distinction to make in that Scrum Masters should know how to facilitate individuals (manage) and facilitate work (supervise), but combine the two by facilitating individuals who work as a unit. Too often I see Scrum Masters who come from the aforementioned roles and concentrate too much on what they know without learning what it takes to lead a team rather than a person or a work-flow. They miss the proverbial forest for the trees.
Takeaway 3:
The title for this section might sound a little misleading, but I usually find that a Scrum Master is kind of a figurehead for the team they're on. What's interesting here is that I find the Scrum Masters I enjoy watching tend to lead from the shadows. This actually makes a lot of sense when I think about it. A Scrum Master will observe a team and find its strengths and weaknesses. They introduce small changes over time that get the team working as a more polished unit. All the while, their vague role really has nothing to do with any of the designing, coding, or testing. They never really spearhead a development effort. They only need to allow people to rise to the occasion and spearhead the initiative themselves. Ensure the team knows each other well enough to put the right team members in the right spots at the right times. Since the Scrum Master isn't actively leading these efforts, its hard to see the development they've been doing all along: team development.
When a person tries to establish themselves as the pinnacle on a team, as a manager or supervisor usually should, this gets in the way of letting the team become self-sufficient. There's the illusion that this person is the one everyone reports to, but this is not a Scrum Master's role. While needing to be an exemplary leader in their own right, the greatest Scrum Masters are, to me, the most humble. They assume a heavy responsibility of making a team the best it can be while putting the team in charge of their efforts as much as possible. The brand of leadership that Scrum Masters need to be good at is one of enablement, not one of individual growth or maximized work-flow efficiency. We already have managers and supervisors, respectively, for those parts of an organization. Lead from behind the scenes and watch your team blossom. Even though I'm not a Scrum Master in title, when I see my team succeed, it fills be with great joy to witness that. Knowing the little things I did, while largely unseen, helped them get there... that's what the role is all about.
Harvesting the Knowledge
Now, these three points are only scratch the surface of what paths and pitfalls a Scrum Master may encounter. They are just ones that I see fairly often, and have given some thought to as far as escaping the pitfall or maybe even avoiding it altogether. They're really more like principles than strict actions because every team is different. The things that I do to help my team be the best team they can be may not work for your team. I do think, however, that these guidelines can help new (or even active) Scrum Masters approach their role in new and better ways.
If you find yourself in a similar situation to mine, being the communication guy between a bunch of seasoned developers, hopefully these tips help you get the information flowing. And for any seasoned veterans, maybe there's something in their you can glean from a beginner, an outsider looking in. And for everyone, remember that growing a team takes a lot of time and unseen effort, but the pros of having someone looking out for the health of a team can truly be immeasurable when employed well. While the effort may be hard to track, it is most certainly a boon. There's a great Futurama quote that captures this quite nicely, and I'd like to end on it:
“When you do things right, people won't be sure you've done anything at all.”
RSS Feed
