Mixing organizational and Scrum roles

Question

Within a quite young and fresh Startup, I'm currently holding the role of a Scrum Master, as well as a developer. My tasks are split up 50/50 between those roles. The 1.5 years before that, I was working as a full-time (FTE) Scrum Master, so this role isn't completely new to me.

The Team consists of 2 full-time developers, 1 freelance developer, 1 very gifted intern for QA & prototyping, a PO and me. So in total we have around 3.5 FTE developers, 1 FTE for PO and 0.5 FTE for Scrum Master.

For the Product Owner (PO), it's his first time as this role, first time within a software company and also first time working in a software / Scrum / Agile project. He's doing very well and learning quite fast. He still got some rough edges, but I'm satisfied with his personal progress so far.

Among the 2 full-time developers, there's that one guy who's my direct supervisor + is holding shares in the company. That person does have some background of Scrum, but in my opinion a quite dirty and ineffective one. Let's just call him Mike.

In order to get all Team members thinking about the Scrum process, I asked everyone in the beginning about his role within the Team. Mike gave me the answer that he's just a developer. Period.

Right now, I'm facing the difficulty that Mike is pushing and enforcing things by his organizational role. I as a Scrum Master massively dislike this situation, as it's doing harm to the process and is also slowing us down. By pushing and enforcing I mean e.g.

• secretly bringing in ungroomed and unestimated User Stories from the Product Backlog into an active Sprint Backlog, with afterwards arguing in favor of it based on his organizational role. I spoke to him about this situation in private. He told me that he knew it's wrong but needed / wanted to have that User Stories in the current Sprint.
• assigning User Stories of the Sprint Backlog to developers, rather than let them take the User Stories themselves
• constantly trying to push in more work and tasks, which only increases our Work in Progress

My questions are now

• I'm used to fighting with the PO concerning upcoming Sprint Backlogs, but I never had a situation without total backing of the Development Team. How do I gain that backing in such a situation?
• How do I solve the mixture of organizational and Scrum roles?
• Have I already been burned as Scrum Master for that Team?

Answer 1

TL;DR

Companies have many choices in project management frameworks. However, if they choose Scrum, then they have chosen to abide by the framework's methodology. This includes enforcing the Scrum roles and rules of engagement. Anyone who disrupts the process in unconstructive ways must be removed from the team.

Failing to remove disruptive team members undermines the Scrum process, disempowers the team, and prevents the organization from accruing any benefit from the formal Scrum framework. Do you want to captain that sinking ship? Probably not.

Analysis

In any organization, a person has three choices:

1. Lead.
2. Follow.
3. Get out of the way.

Your founding developer is doing none of these three things properly. Quite frankly, this is unsustainable from both methodological and organizational perspectives, and you are already experiencing toxic results this situation.

As the process referee, it's your job as the Scrum Master to educate the organization about Scrum. If you have a supportive leadership team, you'll need to educate them about the Scrum roles, the need for work-in-progress (WIP) limits, and the non-negotiable requirement to have all priorities managed through the Product Owner. The Product Owner himself should be at your side, cheering you on as you communicate this to the stakeholders, because it affects his ability to deliver an effective product too.

Vote Him Off the Island

Since you've already had a private conversation with the founding developer, he knows that he's violating the core principles of the framework, and has not undertaken to reform his ways, you will need to engage the rest of the leadership to remove him from the team. If they fail to do this, they might as well just replace the Scrum Master and the Product Owner with this guy, and let him manage the projects his way.

You need to be prepared to defend the Scrum process and the capacity limits and self-organizing principles of the team. If you are not willing to defend them thoroughly, up to and including walking away from the Scrum Master roles (and possibly the company) if they don't want to adhere to the framework that they themselves chose, then you are setting yourself up for failure.

Stick to Your Guns

If "Mike" has enough clout to get his way despite flouting the Scrum framework and principles, just call it Mike's Pseudo-Scrum and let him be responsible for the results. If you and the rest of the team keep pretending that you're following a formal process while really just doing whatever Mike thinks is important, then you are abdicating your responsibilities and tacitly giving your approval for this deviation from process. Members of the Scrum team who allow any one member of the team to hijack the process are at least partially culpable for any process failures that result.

Follow the process. Don't "be like Mike."

Answer 2

I think Scrum is just not a perfect fit for small software development start-ups. Its hard to commit and focus on a fixed scope of work for a fixed period of time when everyday new insights come in and clients/users are changing your world.

Small companies need the flexibility to change their focus faster then Scrum allows, unless you do one weeks sprints.

I would suggest to have a look at ScrumBan. The flexibility of Kanban and the Agile mindset, roles and meetings of Scrum. An continuous flow of work and planning/releases are just-in-time. Schedule a nice rhythm for reviews and retrospectives.

Answer 3

I would speak with Mike privately and point out that as a Scrum Master it is your responsibility to ensure that the Scrum process is being followed.

Discuss with him what is motivating his behaviour. Perhaps he has concerns over deadlines or the output of the team? Once you better understand his motivation then you can work together to find a way of reducing his concerns.

In my experience the best way to solve this kind of problem is to highlight the issues and suggest approaches that could make things better. Try and create a positive and constructive atmosphere where the team is willing to step up and solve their own problem.