In my current position, I had the opportunity to interview a lot of developers. Some of them were very senior with years of experience and coming into the job with a resume that was stacked – amazing job titles, fascinating projects, the whole works. Others were green and inexperienced, with their biggest software project being a month or so in length. For the most part, experience didn’t really indicate whether someone had an agile mindset.

I never liked interviewing people, because I wasn’t one to enjoy interviews myself. I didn’t like the tricks that people asked, or the little riddles that they liked to solve. (I remember in one interview, someone asked me the default port number for MySQL. I knew the answer, but simple fact-based question like this don’t give much insight and it’s a hit or miss.)

Determining whether someone has the agile mindset is actually pretty simple. It doesn’t involve asking questions about the manifesto, or even common process oriented Scrum-lingo, like iterations or sprints or planning meetings. I used to ask a lot of yes or no questions, or questions that had very clear cut answers, but I quickly learned that these didn’t really give good insight into figuring out a developer’s skill set.

Rather, I found that the best way to determine if someone has an agile mindset is to just have a few minutes of open-ended conversation with them, and talk about how they would run a project if they were given full control, or how they work on hobby projects in their spare time.

I have a lot of developers who would often claim that they love agile development, and everything that it stands for, but when they talk about how they would like to develop software, they often start with an approach that doesn’t have much agility to it. It’s very documentation heavy, process oriented, and doesn’t really have much of the twelve principles, which some of them could recite by heart because they’ve memorized it. I’ve noticed that people who have the agile mindset tend to focus on getting working software as soon as possible, and everything is focused around that.

So from my limited anecdotal evidence of interviewing people, what I’ve noticed is that a lot of people have learned what developing with agility is, but they haven’t understand why they want to do it. Someone who has the agile mindset is someone who understands, believes and knows why they want to develop with agility, and will usually eagerly explain it to you.

One thing I constantly used to struggle with, and constantly see my colleagues and fellow developers struggle with is what their roles and responsibilities are as scrum team. Often times, I see this from developers who have worked for larger companies, with set hierarchies and organization charts defined, where they are just another smooth gear in the Scrumerfall Work Horse.

I sometimes do see it from people who have free-lanced, or worked on gigs, and have a more pragmatic approach to building software — and my own guess is that these kind of people are used to dealing with all aspects of software or web development, from soliciting gigs, business paperwork, coding, testing and even deployment of the many projects that they work on.

But first, a little bit of background. My first foray into software development started at a young age, and was more hobby-ist in nature. I didn’t do software development to make money when I was a teenager, but I did it because I thought it was fascinating, and it was amazing to be able to write some code, and have my web browser be manipulated, controlled to whatever I was able to come up with. Software development become an art, an infinite canvas of expression, bounded only by the limits of imagination.

I quickly learned that people were able to make money off this, and went into free lancing at a young age, and made it through school, and then worked for agencies and enterprise environments, and have seen a lot. I haven’t seen it all, but I’ve seen enough to notice some common trends.

My hobbyist passion of software development drives my work philosophy in my career, and any software development I do outside of my day job. The free lancers I mentioned earlier, are generally more adept at handling the roles and responsibilities of a developer on a Scrum team, because they are used to wearing multiple hats, and it’s easier for them to learn. Developers who have only coded in a corporate work environments, where they are specialized to code are great coders and developers, but sometimes have a hard time to learn the shifting hats required on a truly Agile team. This is just anecdotal evidence, and a trend I’ve noticed so far.

Going back to the opening topic of this post — what are the roles and responsibilities of a developer on a scrum team? Well, the short answer is no list of roles and responsibilities that can be cleanly cut, easily defined, and neatly put into a list. There is only one guiding principle, and that is: Do whatever you can do to help the team deliver great, working software and do this in the best way that can be done.

I have found that not limiting myself to a set of roles or responsibilities, but doing whatever I can do to help the team has been the one factor that has made me successful as a developer. Sometimes this means venturing into unfamiliar or new territory, or doing tasks that are mundane in boring. I have learned much more about QA and testing, simply because there was a need on our scrum team, and I learned it to make sure our team was successful. I’ve helped out with scheduling and organizing meetings, scheduling design sessions, take meeting notes, and even follow up with external vendors — all which were not technically my responsibility, but it needed to be done.

The second part of my principle is doing this in the best way that can be done. This is very different than doing things in the best way that you can. Doing things in the best way that can be done naturally challenges you to better your techniques, and not get stuck in a rut, because you are always trying to optimize your processes and making yourself better.

In the end, a scrum team is exactly that — a scrum team. With any team competing to win and be successful, you can’t be narrow visioned and limiting yourself to roles and responsibilities — instead, take a step back and do what you can to make the team successful.

One thing that I continuously harp on about is agile software development, or as I’ve recently learned from Dave Thomas, developing software with agility. I work in a large enterprise level company, and we have our share of hurdles, and obstacles to overcome, but I recently faced an interesting situation.

Our department was in need of a scrum master, and we needed one badly. The situation was fairly dire, with our technical leads and project managers serving as scrum masters. They were overworked, over burdened, and simply didn’t have enough time to be effective scrum masters. I had expressed my interest in changing our scrum and agile processes, and was asked if I wanted to be scrum master.

Now, keep in mind, our processes were very immature and ad-hoc. We didn’t have a lot of structure, but we had the basic scrum foundation. Daily scrums, planning meetings, retrospectives and the usual stuff. We were doing all the things of “agile development” without being truly agile, but just trying to check off a list of tasks we could do and try to make it work. It was a mess, and I knew we could do better, but as anyone working in large company knows, change comes slowly and there’s a lot of other parties involved which means that it’s always feels like an uphill battle.

So when given the chance to be a scrum master, I took it eagerly. I knew I was going to face some challenges and problems, and I had read that it was never a good idea to have the dual role and do two things, but I thought I could manage. “What’s the big deal, anyways?”, I remember thinking. “Schedule a few extra meetings in Outlook, facilitate them, and most importantly remove blockers from our team”. Our team was relatively small, with only two developers, one QA, and a part-time tech lead, so it wasn’t that big of a deal.

How did it go? It went well. Our team was successful for all the sprints I was a scrum master for, and we delivered three sprints worth of work (nine weeks) on time, and everything. But I would strongly discourage anyone from trying to do both roles.

The problems I faced were pretty bad — I was being called into a lot more meetings from project managers, and tech leads, and people I never normally interacted with. Product owners and managers would request me to be to part of meetings for their status updates, and what not, and this wasn’t too bad, but definitely distracting. Distracting. That was the common theme by juggling two roles.

When you are focusing on being a developer, you have one goal. To develop working software, and all the good stuff related to that. Being a scrum master requires you to adapt like crazy to whatever situation that will get thrown at you (and it will), and respond with agility, and remove blockers. Mentally being able to juggle these things was very difficult.

Remaining neutral was also very difficult at times, but doable with the right mindset. By nature, I am a very outspoken person who isn’t afraid to defend my thoughts and ideas. When dealing with QA, who is naturally trying to find bugs, and hammer your application, it was difficult to remain neutral, and I found myself wondering if I should be neutral, or if I should say what’s on my mind. This took some time to balance, but in the end, it definitely helped me mature more as a person because I truly forced myself to see other people’s perspectives.

The benefits were good too — being the primary developer on the team, I had intimate knowledge with the stories and the issues, and this allowed me to communicate updates to the external world of our scrum team very easily and effectively.

It also allowed our team to implement more agile development changes, and be very flexible. Our previous scrum master was not as technical as a developer or QA, so by removing this element, we were able to make changes that improved our agility. It required one less person to propose the changes to, and to agree — things just seemed to move more fluidly.

After our 3 month experiment ended, and we found a scrum master replacement, and I went back to being a simple developer, and it was a huge relief on my shoulders. I had learned a lot, and I began questioning why I even served as scrum master, and what the benefit of it was. In the end, I’m glad that I took the chance to work as a scrum master, and I would only suggest it as a brief experiment or a temporary thing to keep a team going. It’s definitely not sustainable, because with the split focus, you won’t be able to juggle the responsibilities and do both jobs well.

What I learned is that I became a scrum master for the wrong reason — I had a lot of suggestions and ideas on how we can run scrum, and what we can do to improve our agility. And for whatever reason, I thought that being a scrum master would allow me to do these changes more easily, and give me the authority to do so. I was right and wrong — I did have more authority, and I was able to make those changes I wanted a little bit more easily, but I realized I didn’t need to be a scrum master to do it. In the end, just because you have the authority to make changes or have a fancy title doesn’t mean anything. What really matters is leadership. I could have implemented all those changes by being more proactive as a developer, and just focusing on what ultimately matters — help the team work with agility, don’t be afraid to step out of my self-imposed bounds as a developer, and do whatever I can and is necessary to produce great, working software.