When a Project Manager becomes a Scrum Master… but not quite.
It’s well documented that Project Managers often fail to let go of a command and control style of leadership and struggle to succeed in the Scrum Master role. While that’s certainly where some of the Scrum Master anti-patterns originate from, I experienced another major source, the organisation which tries to have the best of both worlds (or their perception of it) with a hybrid Project Manager/ Scrum Master role to keep those reluctant to change happy whilst implementing the elements of Scrum that don’t require too much of a culture change.
I transitioned (partially) from Project Manager to Scrum Master when working for a digital agency that was keen to market the benefits of Scrum to clients; frequent deliveries, faster feedback loops and the ability to adapt to changing market conditions. There was a reluctance to introduce changes that could be seen as a downgrade of their service. As such, clients retained their Account Manager who acted as a proxy Product Owner and I became a Scrum Master. However, I also continued to serve in a Project Management capacity: providing status updates, fielding all communication relating to work in progress, and putting together project plans and reports.
The inability to shake off my project management responsibilities made for slow progress in learning Scrum and didn’t leave me much time to focus on helping the team to understand and adopt it. While they managed to master most of the rules and held all the events, they were fairly oblivious to the values and I prevented them from embracing self-management by continuing to cover all the non-technical aspects of their roles, at the request of my superiors who wanted them focused on development.
How I obstructed self-management
Developers were keen to embrace self-management in so far as deciding how much work to commit to and how to execute it, but it stopped there. They were encouraged to focus on writing, testing and deploying code and I was accountable for ensuring that happened. Any other activities were seen as distractions for me to protect the team from. Creating Jira tickets, updating burndowns, liaising with clients and suchlike wouldn’t have been seen as a good use of a developer’s time, so I covered those tasks. This meant the team were dependent on me and I could be a bottleneck slowing them down and contributing to reduced transparency and confusion.
How I made the Daily Scrum feel like a status update
In attending the Daily Scrum, with a Project Management interest, I inadvertently contributed to it feeling like a status update. I participated in a Scrum Master capacity to ensure the event kept roughly to its timebox and focused on the Sprint Goal, but I also made notes to inform the progress reports I would send to stakeholders. The team were aware of this and would direct their updates towards me, as they had when I was a Project Manager chairing the daily progress meeting. It wasn’t the collaborative developer-led planning event it should have been.
How I took responsibility for transparency
As I fulfilled the admin tasks that enabled transparency, such as creating backlog items for emerging work and updating existing ones, developers didn’t give transparency much thought, it was something that happened in the background. The unfortunate consequence was that transparency suffered when I wasn’t around. I would find the status of work unclear or work in progress which wasn’t represented on the Sprint Board. Scrum Masters covered for each other’s absence to maintain transparency, which often led to them being stretched too thinly across multiple teams.
How I reinforced barriers between developers and stakeholders
As a Scrum Master, I should have been removing barriers between the Scrum Team and Stakeholders and encouraging collaboration. Unfortunately, in continuing to field all communications between the two parties I reinforced those barriers. This worked in the team’s favour in the sense that they avoided unhelpful interruptions from stakeholders but it also worked against them when they had questions, as they were channelled through me with plenty of toing and froing to clarify questions and responses.
How I prevented creative solutions
As a Project Manager, I worked with the team to remove blockers and impediments (although the word impediment wasn’t used) taking over when problems arose to find a solution. This continued when I transitioned to Scrum Master and instead of coaching the team to explore possible solutions themselves I would step in and resolve issues, many of which were well within their capability to resolve. Blockers and impediments fell into the “distraction” category so resolving them was one of my responsibilities. While I was working on them developers would sometimes move on to the next task, which could lead to the highest priority work being parked until later in the Sprint by which time it was at risk of not being completed.
This way of working discouraged developers from thinking creatively when faced with impediments or blockers and I’m sure they could have come up with better solutions than me in many cases. They possibly gave less consideration to whether work items were ready for development as I could chase up any missing assets or information while they carried on working.
Summary
It was a combination of knowledge gained through Scrum Master certifications and moving to an organisation with more mature Scrum Teams that made me realise how much trying to do both roles directly conflicted with Scrum. In trying to have the best of both worlds the organisation certainly didn’t benefit from the best of Scrum.
