I joined Far Reach about a year ago as their first dedicated scrum master. Though I already had my scrum master certification, I had never actually played the role in a business before. As you might imagine, the team and I have learned a lot about my role in the last year! Here are some of the most important lessons we’ve learned.
1. Trust your gut.
Even if you don’t have the metrics to confirm your suspicions, listen to what your gut is telling you. Don’t wait until you have all the evidence you think you need to share what you’re feeling.
2. I now know more about development than I thought I’d ever know.
We have processes for a reason: they work. I understand now that code reviews and test cases are important. If I don’t hear that they’re being done, I’ll ask about it. There’s no way I could write a line of code, but I can still add value to the development process.
3. Sometimes, nagging works.
Period.
4. Even the obvious questions need to be asked.
I still doubt myself and hesitate over whether I should ask the most obvious, dumb question. However, I’ve never regretted asking one of these questions. Not once. In fact, I find if I don’t ask that seemingly obvious question, I usually regret it.
5. Uncomfortable questions are part of the job.
No one wants to ask them, not even me. But my job is to make things easier for the team, and asking tough questions is part of the deal. Do it.
6. Discipline is important, even for professionals.
As I said above, processes—good ones, anyway—work. However, we’re humans, so we tend to fall back to the easy path even though we know we shouldn’t. To help keep this from happening, I need to lend support and encourage the team to stay true to the way we work.
7. Everyone likes to hear they’re doing a good job now and again.
A question was asked at one of our huddles: “What if we put as much thought into our encouragement and praise as we did into our criticism of others?” We all want to know what we’re doing is helpful and beneficial. It keeps us going. Part of my job is making sure people hear what they’re doing well as well as what they could do better.
8. You’re not above any job.
If walking a dog somehow helps the team keep working, it’s an important job. Bringing in water (or chocolate) during a long meeting is a small gesture that helps the team power through long meetings. The jobs that aren’t glamorous but keep the team moving are just as valuable as writing code.
9. Relationships are important.
Building relationships with team members as individuals is really important. I learn more about blockers for our teams during one-on-one conversations than in any other scenario. It’s not enough to just listen to your team, though. You also need to act.
10. I’m not sure you can ever “master” being a scrum master.
Things are always changing—how the team works, projects, processes, and more. Scrum is about continuous improvement and iteration, so if the team is comfortable, I’m not doing my job to push improvement. Until things are perfect, I’ll always have a role.
11. Even though I don’t understand everything the developers say, there is value to being there and listening.
There are social cues and questions I ask in meetings that often times bring out issues developers wouldn’t have thought of. By being there and being engaged, I’m able to provide a different perspective, and, consequently, a lot of value to the team.
12. Data is hard to figure out.
I still don’t know what metrics are best to track for the team. I just keep trying to collect new important information, like how many points were done this sprint or how they feel about the sprint. The data we find most useful is always changing, which you would expect in an agile organization. Figuring out what data will help the team improve at any given time is a challenge, but I know how valuable it is, so I keep working to gather and share whatever might be useful.
Agile teams and scrum masters: What are some of the biggest lessons have you learned? Let us know.