Blog | Why dwyl scrum master must also be developers

[iteles]

This needs to be written.

I have a lot of experience to draw on here, originally being "project manager" ( 🤢 ) with no development experience, then becoming a developer, then scrum mastering whilst developing and now being in a position where I haven't had much time to write code (just some review) for the last few months.
It's been a huge hinderance and my effectiveness as a scrum master and the amount of value I can add to a team is sitting at around an estimated 50% of what it was when I was able to do both.

It breaks some conventions, but having been there and done that, I need to write this post soon.
This is how we do it; this is the way we don't waste our time.

[ghost]

@iteles is there a good reason not to make one of the developers that is on the project the project scrum master (like was done for OA recently) as they know the project best technically? And then have a separate role for yourself or myself (or whoever) for dealing with non-technical project management, client relations, etc?

[iteles]

@markwilliamfirth None at all! If you'll notice, we're currently training our developers to become scrum masters across a couple of different projects. This is something we're trialling out as we speak now that our developers have more experience in both understanding what the role entails and in End to end projects with dwyl. This is a role a handful of dwylers are beginning to enjoy.
Some clients however, require more work and a separation is healthy so that the development team can focus on what they need to do rather than the client which can create unnnecesary stress.

You personally were asked to scrum master one project because the experience of doing so is essential - we each need to understand what all the roles dwylers play are. If we talk the same language, the team's communication is infinitely less fraught.

[ghost]

Yes - I think we need to separate the roles into something roughly like this:

Project Manager

• Gets requirements from client
• Writes up project proposal
• Agrees budgets
• Gets contracts signed
• Organises resourcing
• Books meetings
• First point of contact with client
• Acts as filter between client and scrum master
• Understands client's priorities and communicates these

Scrum Master

• Organisational (not technical) lead for development
• Runs the stand ups to ensure everyone's on track
• Manages time estimations
• Breaks down requirements into smaller issues and time estimates wherever necessary
• Communicates to PM when something is needed from the client

So for example on EMF Cleo could act as Scrum (whilst also still being a developer) and either yourself or myself act as PM

[iteles]

The last thing I want to introduce at dwyl is another level of management and I abhor the term 'project manager' or 'account manager'. This also doesn't strike me as the correct issue to discuss this topic.

That is also nowhere near a complete list of what the Scrum Master's responsibilities are and is exactly why I created dwyl/process-handbook#35 and dwyl/process-handbook#36.

This is in hand and is not part of this blog post and therefore issue.

[ghost]

@iteles yep it's just a rough idea (job titles and responsibilities obviously need to be adapted)

It's more about the idea of separating development management and client management

[iteles]

👍 More thought is being put into this as we speak. That's why I'm trying to carve out some deep work time for myself and @nelsonic !

[ghost]

Ok well please let me know your thoughts once you and Nelson have discussed (please feel free to open a separate issue if you want to separate the threads of discussion)

[iteles]

Further thoughts that came up from a scrum master on a retrospective today:
'I try to ask all of the clarifying questions of the Product Owner that I would like to know the answers to as a developer so that when the developers come to it, they can don't have to ask the obvious questions and can work much more efficiently'

[ghost]

Couple weeks back I came across someone on LinkedIn who has experience as an Agile Coach / Agile PM and they were looking for a new role. They had quite good experience (some excerpts from cv below):

They were quite interested in dwyl and were keen to have an interview until I asked if they would be willing to learn our stack in order to be a "technical SM" (also having capacity to understand the code and understand a code review and estimate issues etc). They said they wouldn't want to and so I asked them why, thought it might be useful to share their insight on this issue:

[iteles]

This is the answer of a 'professional scrum master' whereas the more traditional scrum master is a developer who is part of the team, rather than someone who just deals with the business, which is what you now see in bigger teams (as there's much more bureaucracy for these teams).

I agree with them that code reviews are not part of the SM's role, though there seems to be some decent misunderstandings around our approach. Excellent validation that we need this blog post, thanks @markwilliamfirth !