These are the musings of a ScrumMaster based on the help he has given in multiple implementations. Like Don Quixote, these will highlight his battles with the giants in the land or IT management as well as the forever lasting quest for Dulcinella, the hyperperforming team
Wednesday, April 24, 2013
To infinity and beyond - Guest Blogger +Todd Azbill
Today we have a guest Blogger, and this is his first try at this. I'd like to present +Todd Azbill and some thoughts on his current role change...
I am currently a Scrum Master for two teams on a short-term project. I am also new to Scrum Mastery. During my transition, my manager pulled me in to a meeting where he asked me if I was planning to continue coding…
…I’ve actually given this a lot of thought. On one hand, I don’t want to lose my technical skills. They've gotten me where I am. You could almost say I’m defined by them, right? At the same time, I don’t want to be the best Scrum Master I can be. Doesn't that mean the teams deserve my full attention?
After a few days of mulling this over while struggling to take on technical tasks and facing the context switching inherent in the “Scrum Master And ____“ role, I asked myself the simple question: Why? Why do I want to keep developing? Why do I want to maintain a skillset that may not help me in my future endeavors now that I’ve gone Agile? Why would I want to give up the happy euphoria that comes from solving the technical problems we developers face on a daily basis?
What I’ve come to realize is that a move from development to people management (Whether it be Scrum Master or Agile Manager) doesn't mean you’re going to give up that euphoric response you’ve come to depend on day after day; only that it will come from a different place. Development teams are complex systems (Some of you may read that as “Development teams are herds of cats”). Your job as an Agile Manager or Scrum Master is to maneuver the complex system in a profitable and functional direction. Often, issues with team dynamics will crop up requiring a similar level of thought as software issues, except you won’t have a nice Googleable solution ready for you since each team is unique. I’ve found that when these problems crop up, thinking of, and Implementing a solution that succeeds will result in a similarly, if not more, satisfyingly euphoric response. After realizing this, I no longer have misgivings or regrets about a codeless existence.
So I'm not a writer, nor do I pretend to be, but I've been told writing on other people's blogs (with permission of course) is a good way to get your name out there. I have no ego invested in this and appreciate honest feedback.