Bad habits of your Scrum Master

Question

Scrum is quite popular dev.process these days and often Project Manager suddenly gets new title (Scrum Master). However it should be not just a new title, but new habits and new paradigm. What are the bad habits of your Scrum master?

Answer 1

When I was involved in a Scrum, the Scrum master quickly developed the habit of just letting us do our own thing, and the Scrum fell back into our normal development routine.

Answer 2

Not helping with the push-back part of the process e.g. 'these are all the stores the customer wants in this iteration so thats what we have to do'.

Answer 3

Not keeping scrums on track - letting them descend into technical discussions and a much longer meeting.

Answer 4

Constantly swapping new bugs in and out of the Sprint.

Answer 5

Assigning work and asking for daily status reports instead of letting the team learn how to manage its own work.

Answer 6

The big bad habit our Scrum Master had at first was thinking we would take care of our own impediments. That's one of the things the Scrum Master is supposed to do but she left it to us until it got unmanageable.

The other thing we've dealt with is the Scrum Master thinking they were in charge of riding the developers' backs until tasks were taken care of. This creates a bad atmosphere on the team since they're supposed to be self-managing.

To me and our team, the Scrum Master's job is to be a shield and assistant for the team, blocking impediments and doing what they can to help expedite things. Ken Schwaber's Agile Software Development with Scrum is an excellent intro to Scrum, it's what our team used and we've been pretty successful with it. There's also Agile Project Management with Scrum, which is more for the Scrum Master and Product Owner roles specifically.

Answer 7

1. Not being able to slot tasks within cycle appropriately (too many usually)
2. Not dealing well with external customers (if a certain task is too large for a single cycle, whining to the team instead of pushing back on the customer)
3. Making daily scrums too large of a process -- not sticking to a certain time limit (we prefer 15 min max).

Answer 8

Constantly trying to tie actual hours worked back to story point estimates.

Answer 9

1. Micromanaging
2. Exercising old-style command and control instead of facilitating a self-directed team
3. Focusing more on the numbers/burn-ups/backlog than on the people who make up the team
4. Not protecting the team from outside interference

Answer 10

There are two kinds of scrum masters:

1. A project manager whose title has changed because of adoption of Agile.
2. An exclusive scrum master who only facilitates the scrum and reports to the project manager (shusa).

The second point is preached and practiced in 'truly' Agile organizations. It is expensive but it has some merits.

Also,

1. A scrum master is expected to be present with the sprint team all the time (not literally). If a project manager does that, s/he would be micro-managing.
2. Scrum masters' role is not to manage budgets, but to put predictability around the sprint team, in terms of amount of work that the team can do.
3. Scrum masters should know strengths and weaknesses of team members, and facilitate inter-scrum best practice sharing.

So, my point is, if these roles are confused, the team may not do very well.

Answer 11

1. Micromanaging the team with hyper activity
2. Overriding senior developers on technical decisions because "Scrum says" and "the team must vote". Totally dis-empowering senior technical people.
3. Trying to squeeze blood from a stone at retrospectives on issues that aren't actually issues.
4. Telling me the points don't matter but at each review the points are disected, analysed every 2 weeks at review. Furthermore, basing our annual bonus on our points performance.

Scrum is good but it can disregard good engineering practice and technical processes that have worked like a charm for ages.

Answer 12

I really dislike it when ex-PMs turned Scrum Master consider Scrum a way to cut back on their original (individual) obligations without investing that time back into team-work, and active stress-reduction (planning for setbacks). They just lay back and start praising themselves for the great results, whereas everyone can see the team would perform even better without their presence, at all.

In my opinion, our best Scrum masters have been developers with a large sense of responsibility, or non-PMs.

Then again, I have worked (before the world knew about Scrum) for PMs that seriously rocked. They would make great Scrum masters today, I'm sure.