On average I provide two Scrum.org Professional Scrum Master courses a month. What's great about these courses is that all of them are unique. Every participant shares his/her own personal experiences which lead to a broad variety of discussions. However, some questions are asked during every course.
In a couple of short blog posts I'll share the most common questions. I'll focus on the Scrum Master role and will provide an answer based on my personal experience as a Scrum Master. This for sure isn't the ultimate answer, it's how I've fulfilled or experienced the situation myself. I would love to learn from your experiences as well!
In this blog post I'll share my view on the question:
Can you be a part-time Scrum Master?
With part-time I mean that you are a Scrum Master / Tester or Scrum Master / Developer etc.
Now I don't like "it depends" answers. I prefer answering the question with a clear and maybe bold statement. This often triggers a nice discussing in which different perspectives can be taken into account.
So, can you be a part-time Scrum Master: yes!
Do I recommend being a part-time Scrum Master: no!
Why "Yes"?
You are still doing Scrum by the book (or guide) if you're a part-time Scrum Master. The Scrum guide doesn't state the role should be fulfilled part-time or full-time. So yes, from a purely theoretical point of view you can be a part-time Scrum Master.
Why "No"?
Although it's possible to fulfil the Scrum Master role part-time, I don't recommend it. You can definitely become a good Scrum Master and achieve some success with the Scrum Team. However, the best Scrum Teams I've experienced all had a full-time Scrum Master.
The 3 most important pitfalls
The 3 most important pitfalls of a part-time Scrum Master are...
1. You're not really seeing what's going on
Let's take the Daily Scrum as an example. The purpose of the Daily Scrum is to inspect and synchronize the team’s progress towards the Sprint Goal, discuss if anything impedes the team and re-plan the team’s work to achieve the Sprint Goal. It's an event for the Development Team and it's up to the Scrum Master to help them achieve the desired results.
This doesn't mean the Scrum Master should attend the Daily Scrum every day. Put differently: a Scrum Master shouldn't have an active role at all. The Development Team should talk to each other to discuss the progress towards the Sprint Goal. As a Scrum Master, take some (physical) distance, observe the team doing the Daily Scrum. This also prevents the Daily Scrum becoming a status-update towards the Scrum Master. Notice what is discussed and also what isn't being said. Notice who is actively contributing and who isn't really paying attention. Maybe ask some questions afterwards, give feedback etc.
If you're part of the Development Team it's more difficult to take some distance. Your role is to contribute as a Developer as well. Because of this lack of overview, you might be missing some crucial information only an observer can notice.
2. It's difficult to offer services on 3 levels
A Scrum Master should offer services to the Development Team, Product Owner and the organization. Some examples of these services are coaching the Development Team in self-organization and cross-functionality, helping the Product Owner finding techniques for effective Product Backlog management and supporting the organization in its Scrum adoption.
Quite often, part-time Scrum Masters spend most of their time offering services to the Development Team. This can be very useful; however, to truly succeed with Scrum you should balance your focus on all three levels. The life of a Product Owner will become much easier if (s)he is supported by a Scrum Master. And when the environment of the Scrum Team (other employees and stakeholders) understand what Scrum is really about, the Scrum adoption as a whole will truly take off.
Offering services on these three levels is often not feasible for part-time Scrum Masters.
3. What are you doing when the going gets tough?
Imagine a Sprint that isn't going that well. Only a few days to go before the Sprint Review will take place. Some important stakeholders will be present and they can't wait to inspect the product and discuss the progress. The Development Team is getting a bit nervous. It's still possible to create the desired increment but only if everyone helping developing, testing etc.
As a Scrum Master / Developer you're in doubt. Something tells you it's better to focus on the Scrum Master part. Observe, coach, facilitate. But due peer pressure you feel forced to start writing code. As a consequence you're not really having the overview anymore and you don't have time to support the Product Owner preparing the Sprint Review. Your development efforts might work out in a positive way. But quite often the result is adversely.
Closing
In this blog post I've shared my view on the question "Can you be a part-time Scrum Master?". The short answer is "yes you can, but I don't recommend it". As a part-time Scrum Master you don't really see what's going on in a Scrum Team, it's difficult to offer services on the 3 desired levels, and what will you do when the Sprint isn't going well? Start developing, testing etc. or take some distance and truly 'see' how the team is doing and where they might need support? To prevent these pitfalls I prefer being a full-time Scrum Master.
What's your view on this topic? Especially if you are a part-time Scrum Master a would love the learn from your experiences. Do you recognize my concerns? How do you deal with them?