Thoughts about embracing the role of (part-time) Scrum Master while being a Developer and avoid getting conflicted
Disclaimer: Being a Scrum Master is not the same as being a (traditional) Manager, although one can consider that Scrum Master is a management level position. This post helps clarify the distinction. I think the concepts in this article also apply to people who are developing and managing software and not necessarily doing Scrum. My apologies if the title of the article is somewhat misleading.
Typical Project Managers are interested in implementing and managing strong processes which translate into results. In Scrum, the Scrum Master handles processes but is also the one in charge of promoting the interaction between team members and mediating that contact when necessary. As the Scrum Master, you’re not only making sure the team is performing accordingly, you’re also investing your time into making sure each member is an active contributor and increases the team’s value and throughput. You take part in being an active promoter of the team’s growth and success.
Key Responsibilities
Being the Scrum Master means that you’re responsible for:
- Coaching the team in regards to Agile and Scrum’s principles and values
- Helping the Product Owner maintain the Product Backlog
- Facilitating team events and promoting self-organisation among team members
- Removing impediments to the team’s progress, being those either internal or external to the team
These are the core responsibilities as defined by the Scrum Framework. They might not look like much, but depending on the Agile maturity of the organisation, they can either take 1 hour a day or be someone’s full-time job.
Complementing these responsibilities are other important aspects which foster collaboration within the Scrum Team and between the Scrum Team and the organisation. They are presented in the following sections.
Don’t Be a Status Collector
The Scrum Master should not ever be a status collector. His duty is to serve the team, not to report the team’s work.
Tooling these days makes it so easy and inviting to focus on reporting, that sometimes its cost is a loss of visibility and personal interaction. Try to adapt your tools to the way the team works versus having your team adapting to a specific tool.
Individuals and Interactions over Processes and Tools- Agile Manifesto
I’m not saying you shouldn’t dedicate time to reporting, reporting is essential for collaborative work. It’s simply that reporting should come second when the matter is enabling people and improving the way they work.
Besides this, the Scrum Master should also work to adequately convey information to everyone impacted by the team’s work. He should be capable of translating macro terms (consumed by managers) into micro terms (consumed by the team) back and forth to ensure everyone is aligned.
Listening and Asking Questions
The Scrum Master needs to be a good listener. Rubber duck debugging is an effective technique to uncover problems. The simple act of verbalising the problem can lead to finding its cause, and if you’re a good listener sometimes you’ll get to be a rubber duck.
Being a listener is sometimes enough but there are cases where you’ll need to do some exploration. This is achieved through questioning.
Your questions should help people explore their own opinions, question underlying assumptions and try different points of view. This is beneficial since you’re not presenting a different point of view but rather guiding people to their own alternatives. This leaves them with a sense of satisfaction (since they were the ones progressing towards an answer) and will remind them that you were there to help.
This article is very insightful on this subject.
Lifting Morale & Improving Feedback Loops
There’s a really easy combo which goes a long way in terms of improving the team’s spirit while also promoting the team’s growth, which is celebrating successes and learning from mistakes. This concept may appear as simple or obvious but when time is of the essence, it’s easy to forget congratulating the team for the good work or cutting learning opportunities such as retrospective meetings.
There’s a huge difference in the quality of the work produced by someone motivated and whose morale is up versus someone who’s bored or unsatisfied with their work.
Build more informal feedback loops. I don’t think having company-wide evaluations every three or six months as the main source of feedback in an organisation is correct. Shorter and more informal feedback loops are better at providing guidance and support for employees. For this to happen, the team should embed it into its culture. A simple “Good job!” after a meeting or an “I didn’t know that. Thanks!” can go a long way. Be a positive force from within the team, give people feedback, either good or constructive, and suggest them to do the same.
Switching Things Up
Tuckman defines four stages of group development: Forming, storming, norming and performing. Teams go through each stage until they reach the point of peak productivity (performing). After a while, teams should look to storm again or their productivity might plummet (since people get used to the way they work together, they stop challenging each other to be better).
With this being said, the Scrum Master, as the one responsible for promoting the Scrum events, might fall into doing things always in the same fashion. Look for ways of switching things up and getting people excited about trying something new. Perhaps opt for real cards over virtual ones when doing Planning Poker. Try some warmup exercises before doing a retrospective meeting. Possibilities are endless and the outcome is usually positive.
Photo by Nigel Tadyanehondo on Unsplash
Self-Awareness and Improvement
Juggling both technical and management work comes at a cost. You may become biased towards one side of the scale and try to solve people problems with technical work. That won’t cut it.
Besides this, Scrum practitioners advocate for a full-time Scrum Master. The consensus is that the Scrum Master can be part-time when he is very qualified or when the team is either small or experienced with Scrum. Still, this is usually not the case.
So in order to keep growing in both areas, one must be critical of their own thoughts and actions. The following are a few key points to consider when balancing technical and management work.
Conflict of Interests
The first obvious risk is the conflict of interests involved in being the Scrum Master but also a member of the team. To avoid conflict, self-awareness is needed. The following are examples where both functions could clash:
- Conducting/moderating meetings while taking an active role in it
- Programming whilst serving the team by removing blockers and facilitating communication
- Focusing too much on Scrum Master duties, which may lead to you becoming a bottleneck since your other work is not getting done
Having time-slots where you perform each type of work might solve the problem of focusing too much on either management work or development work. Keep in mind that this may be difficult to achieve since your job is now very prone to interruptions.
In regard to being biased towards either one of your roles, try questioning your intentions when taking a stance — “Am I really helping the team trying to crank out this feature or should I be preparing the planning meeting to make sure everyone gets the most out of it?”.
Getting Too Technical
“No matter how it looks at first, it’s always a people problem” - Gerald Weinberg
Sometimes having the Scrum Master be a person completely outside the environment of the team can be the first step to uncover underlying people problems. These may have been wrongly identified as technical problems and having technical knowledge may be a drawback since you get tempted to approach things from the technical side and leave the root causes unaddressed.
This isn’t always the case as having technical insight sometimes gives you a leg up on technical matters and facilitates getting into context.
Switching Context
Context switching is one of those things that can go unnoticed but it can be a real productivity sucker. As previously mentioned, allocating time slots to specific activities is a good option. Since developing software is a task which requires continued focus, allocating time slots of 2 or 3 hours without interruptions might be the solution for not killing all of your development work productivity.
Avoid Coding on the Critical Path
Being a part-time Scrum Master means you have to split your time, and sometimes your Scrum Master responsibilities come before your developer responsibilities, especially since there are no other Scrum Masters on the team.
This means that you should not be working on the team’s critical path when you have to split focus, or you might become a bottleneck for your team. Remember that your contribution to the team is not only measured by the code you write but also by your more management-oriented duties. So be ready to make trade-offs between working on that cool new feature the team’s developing and grooming the team’s backlog.
When the Scrum Master is also one of the most tech-savvy people on the team there is the possibility of the team becoming dependent on his work to be successful. This is against the Scrum principle of having a self-sustaining and cross-functional team. In this case, the Scrum Master should leverage his coaching position to help the team build up their tech skills.
Learn How To Become Better
Scrum is something that is easy to learn but difficult to master, for two reasons.
Firstly, Scrum gained a reputation as being the silver bullet for Agile development, when, in most cases, you need to adapt it to your organisation’s use case. Blindly following the practices won’t get your team far since it’s easy to introduce bloat by having rituals and processes that aren’t carried out properly. Make sure everyone involved understands the value of Scrum’s practices and question them when necessary.
Secondly, Scrum provides a lot of resources in regards to knowing how to manage the team, what meetings achieve which results and how to measure progress. This is great for one to get familiar with the processes. Yet, the people part is usually the hardest task to either teach or perform.
As the Scrum Master, you need to protect the team from outside interruptions and be sure to remove blockers. Is the Product Owner constantly pinging the team for status reports? Easy, let’s call him to the Daily meeting as a chicken (observer) so that he can be in the loop. Is some feature dependent on an API owned by another team? No problem, let’s set up a pair programming session so that we can get things rolling. Are two of your team members not talking to each other because of a disagreement? Hmm… Not so easy to fix right off the bat.
I’m becoming more and more adept that soft skills are what makes or breaks an organisation. Hard skills can be learnt and practiced. Leverage your communication skills to address people problems in your team when hard skills failed to do so. Some pride swallowing and an honest conversation go a long way.
Wrapping Up
In summary, being a part-time Scrum Master requires you to be very conscious of how you’re managing yourself. It also requires a habit of introspection to determine if your priorities are right and that you’re not biased towards a specific type of work or decision.
All in all, if you enable your team, promote feedback and learn from mistakes, you should be poised to be successful.
References:
- ScrumMaster — Should They Be Technical Or Not?
- Can a Scrum master be a developer also in the team?
- Can You Be a Part-Time Scrum Master?
- Small topics: Done, and Sprint Length
- The Case for a Technical ScrumMaster
If you enjoyed this post please consider clapping for it and following me on Medium and Twitter. All feedback is appreciated!
