I have been a Scrum Master for my team of 8-10 since November of 2011, and it has been one of the most rewarding experiences of my career. I was very lucky to land this position. Previously I had done development and testing projects, but my only lead experience was for a team of myself and one other guy, and that only lasted a few months. It was a risk for my manager to put me in this role, so I had a lot to prove. I started to keep a private list of all my lessons learned (i.e. every time I stuck my foot in my mouth or dropped the ball). This list currently has 68 items in it, and I’m sure there were far more times that I forgot to record. I recently had the opportunity to go out to eat with some of the other Scrum Masters on my project, several of which were brand new to the position, and we talked a lot about what the position means and what responsibilities come with the title. I shared some of my personal “lessons learned”, and managed to boil it down into three main areas.
Servant Leader
I’ve heard it joked before that “Jen goes to meetings so I don’t have to”, but there is some truth to that. As the interface for the team, I have to know how we might affect other teams and how they might affect us. I need to listen every time someone says, “If you see this problem, here’s the fix” so that I have the answers when we need them. This means reading ALL my email and being able to quickly find the pertinent pieces (organize your emails well, archive everything). I have to know who to talk to when we have questions, which means I have to pay attention to who knows what. I get to report when we mess up and take the responsibility to fix it. I schedule our meetings, I reserve the conference rooms, I make sure our board is up to date, I buy the pizza – all those little things that my developers shouldn’t have to worry about. They have better things to do.
“My Developers”
My developers are the guys that make it happen. Without my developers, there would be no project. Without them, my position would be meaningless. I get to do everything in my power to make life easier for my team, so they can do what they do best – write code. I grease the wheels, I’m the glue that holds it together (yes, grease AND glue… just trust me). I fight for their autonomy, their interests, their purpose. My team is happiest when we have work that is meaningful, useful, and we feel like we’re being productive. It is my job to make sure they get that.
And now I get to brag a little. If making me a Scrum Master was a risk, giving me the team I have mitigated most of it. I work with such a high caliber of developer that there are whole classifications of issues I never have to worry about. These guys know their stuff. They are smart, they get things done, and they are all incredibly nice people, despite the amount of good natured teasing that I get from them on a regular basis. Their success is mine too. If we crash and burn then I’m going down with the ship. I’d better make sure we’re not set up to fail, and sometimes this means stepping out of my comfort zone.
Productively Annoying
As a Scrum Master, I have to be what I call “productively annoying”. Now, being straight up annoying isn’t a good thing, so let me explain the difference. Scrum Masters need to be able to keep track of details and follow up to make sure things have been done. We need to not be afraid to ask for clarification, even if that means being the one person who speaks up in a meeting. We need to question what we’re doing and evaluate its effectiveness so that we can improve. We need to not be afraid to go sit on someone’s desk until they answer our team’s question or make the decision we need made (don’t literally sit on their desk). We need to listen to our team, act on what we hear, and then follow up to remove those impediments. Sometimes team members don’t come out and tell you what they need, you have to infer it and apply some “productive annoyance” to understand.
We need to be able to call things out when they are wrong, hold people accountable if they screw up, and figure out how to prevent making the same mistakes in the future. We have to be willing to have hard conversations, to receive criticisms, and to admit when we mess up. It can be uncomfortable. It doesn’t come easy, especially for natural inverts. People might end up being annoyed with you, and you have to be ok with that. Take matters into your own hands to get stuff done (i.e. Who is going to let me? Vs. Who is going to stop me?).
It basically came down to these three things: ** Be a Servant Leader, Value Your Developers, and Be Productively Annoying.**
If you’re actually interested in more than just the highlight reel, I’ve posted a filtered version of my 68 lessons learned here. They are very project specific, but it gives a decent outline of my 17 month tenure so far. Keep in mind, I wrote these as notes to myself, and each one was learned the hard way.
Build awesome things for fun.
Check out our current openings for your chance to make awesome things with creative, curious people.
You Might Also Like
