I wish someone would have told me when I was Scrum Master
Keep it simple over precise
With the education I have in computer modeling, I love numbers. The exactness and ability to read patterns give me thrills. Figuring out the visualization of different metrics has been one of my favorite things. I always get too excited when I share some numbers. Even though I love it so much, I have never been truly successful in telling the story through numbers. It made so much sense to me, but the feedback I got was typically confusion. One of the reasons behind this was that my mind works in complex dimensions where I can quickly put dots together, while for the others, it's a puzzle. I kept visualizing the complex problem from different angles and learned that sharing it this way doesn't help others. It was a curse until I realized it. So many confused looks and quiet times when I finished my presentation. I've learned the hard way that I can still look at the same thing from different angles and build the visualizations for my analysis, remaining as exact as possible. Then I need to cherry-pick just one to tell the story in the simplest possible way to the others. As obvious and simple as it sounds, finding the balance between simplicity and exactness takes a lot of work, but it worth.
Metrics are good servants but a poor master
Imagine management telling your team you have a production deployment freeze until all bugs in the backlog have been fixed. The reason is that the management saw the high number of bugs and concluded that the product the development team had been building was of poor quality. And they've thought that the new delivery freeze can help it. Sure. For a while. In the long run, the team changes the strategy when they raise a bug. It decreases the team's empowerment for their product, and management loses transparency. Let us use the metrics to serve us, to be a discussion starters, not the other way around. Otherwise, it can become very unhealthy and dangerous. And let's make sure we'll teach this people around us.
Timeboxed and small experiments can increase the success rate of agile transformation
When it comes to something my team wants to change in the process we don't have complete control over, I became a warrior. I would do whatever it takes to have a green light from management. And I got many reds instead. I considered management as an impediment to progress and innovation. I would fight them and get emotional until I learned how easy and pleasant such collaboration could be. First of all, I should be humble. The only place ego can take us is hell. The second thing is understanding what concern the change management has. And I could identify two high-level categories of their concerns: a) losing control; b) cost. Let's ask management for permission to give it a trial run for the time being for one team, and we'll regroup together in a month. We get timeboxed and small experiments, where management retains control over decision-making and would be relatively inexpensive since only a few people would be involved for a short time. I led a few timeboxed and small experiments, which became the new norm for the organization. It was a fantastic feeling to build something from the ground up. And if the experiment fails, it's ok because it wasn't comprehensive activity. We tried, failed, and learned quickly. I recommend giving it a try.
They don't mean to hurt you
The beginning was hard for me. I was inexperienced, a dreamer, a people pleaser, and insecure. I took everything personally. I cried in a bathroom between meetings over a comment from my teammate that I should ask the other Scrum master to learn how a telephone works because I couldn't set up a Polycom for a minute. I cared so much about what the team thought of me that I made some situations worse. Some people left the team, and I blamed myself. Over time, to not lose it, I learned to turn off my ego on demand. And it helped me in all aspects of my life. People don't mean to hurt anyone by default. There is always something beneath it, and the Scrum master should be curious to find it.
Pick your own battles
Oh my, I wanted to improve so many things at once. I got frustrated when people didn't follow my lead (BTW, I started this blog as a coping mechanism to remain sane while I was too excited to change the "world"). Some people have meant well, stating that I shouldn't waste my time on this or that. But I chose the battle anyway. Some of them were lost, and some were great wins. It took me some time to differentiate the things worth moving forward right now, which can wait, the things I need to prepare the environment for, and the ideas that never become a reality. As far as I am the one picking the battles, I am good. But it needs to be a pick!
It's ok to say what you think
For a long time, I thought I had to be an excellent coach to be a good servant leader. And while I have my opinions, my coaching attempts can only be successful once I genuinely would remove my thoughts. So it was a constant fight in my head. I've learned that this fight was unnecessary. I was in written communication with Jon Kern, the agile manifesto co-creator, and Mike Cohn, co-founder of Scrum Alliance, some very popular agilists these days. I boldly wrote them, asking for feedback and ideas for content for my agile app idea. We kept in touch for months, and both started tutoring me. They didn't coach me. They didn't try to let me figure out things. They just stated their thoughts and allowed me to work with this information. And I realized that such openness is refreshing, something that feels natural to me. Why I fought this so hard? Why, every time I said what I thought to my team, I felt guilty? Now I know that servant leadership is not defined only by coaching skills, but authenticity comes into question too. Because we all have different strengths, it's ok to say what we think as far as we have good intentions in our hearts.