We are new to scrum and team with most are experience devs. (even decades). The project manager (experience dev but new to project management) gave a scrum master role to a junior BA. She is ambitious well organized and not much scrum or even matured working experience. She seems to eating into PM role are and becoming bossy type. May be she thinks her responsible is to make project successful in-expense of what others do or thinks.

With real agile experience with 3/4 years (another organization) ,I feel those agile projects were more democratic and encourage autonomy. How could I bring-up that we are going in a wrong way?

  • Can you describe "bossy" in more detail? Bossy about what? It is her job to make sure the rules are followed, it is not her job to pick priorities or even make the rules. So what does she do specifically?
    – nvoigt
    Commented May 20, 2020 at 4:24
  • mainly I believe task should be pulled by team-mate not pushed to.
    – 1234
    Commented May 20, 2020 at 4:39

4 Answers 4


There are actually two questions here:

What went wrong?

From the short description, it seems that there has been no training but the person was just given the job title (maybe with a copy of the scrum guide). SM is a demanding role which has to be learned and which requires exquisite interpersonal skills, it's not just about holding ceremonies and pushing the project forward.

What can you do to help fix it?

How you could bring it up and help your organization improve depends largely on your organization's communication culture and on the relationship between you, the project manager, and the scrum master. I'd try to be open but non-aggressive in my communication, but many people tend to enter a defensive position when you point out problems to them, so this won't always work easily. You could concentrate on common goals (project success, team performance) and point out which changes could help to secure these goals, that is, focus on positive suggestions instead of criticism.


It's interesting that you are questioning the role of the SM but not the PM. There is no Project Manager role in Scrum and the PM shouldn't need to assign roles and tell an experienced team how to work. I would start by having a word with the PM and seeing if they are happy that the team should self-organize. If not then the PM is the real problem, not the SM (who after all is presumably trying to make the most of the responsibility she thinks she has).

Explain to the SM that it makes sense to rotate the role among the team because the SM is not a lead or a manager but a facilitator. A good SM should be willing to take a back seat and allow the team to develop their own way of working. A good PM should do the same.


This is a tough place to be in. You have an inexperienced Project Manager and an inexperienced Scrum Master. The team is also new to Scrum. Chances are that the team will follow the Scrum Guide mechanistically, because that's usually what happens when inexperienced people need to put something in practice which requires experience (and that's valid for a whole bunch of things, not just Scrum). What's even worse, is that, unless explained to them, people will think that they are actually doing Scrum because they have nothing to compare their implementation against.

There are a few solutions (of the top of my head):

  • get yourself an experienced Scrum Master. You don't need someone to fill this role just because in Scrum you need a Scrum Master. You actually need someone to help you with the implementation, someone who has already figured things out. Hiring an experienced Scrum Master might or might not happen depending on the company you work for and how determined they are too actually do the right thing not tick some Scrum boxes.

  • get yourself trained. Find a company to train you with Scrum and Agile practices, someone who can accompany you for a while and act as a launching pad and evaluate your progress, a trainer or a coach that comes to your office and guides you on this new path for a few sprints.

  • figure it by yourselves. Constantly inspect what you are doing and figure out how to improve. This means everyone to be mindful of your practices not just follow the ceremonies. It involves learning about Scrum (and finding out about good and bad practices), being open at the retrospectives, and it involves a lot of communication and collaboration. As another answer mentions, this won't be easy as people might get defensive if you point out problems. And it also won't be easy because the team is inexperienced and you need some kind of experience to recognize when you are falling of the Scrum wagon and how to get back on.

No matter what solution you find, people need to be involved and to want to improve. Attitude matters a lot. Open up a discussion with your team mates (maybe at the next retrospective) and see what everyone thinks. You will then see what chances you will have to improve things and how open people actually are to implementing Scrum the right way.



You have a very new team, and everyone involved in the project is new to their Scrum roles. Furthermore, the Scrum implementation itself seems flawed, since the team is using Scrum labels without evidence of having truly adopted the roles, responsibilities, values, and events required of a successful Scrum implementation.

In short, you most likely have both a framework problem and a communications problem. The team as a whole needs to address both.

Unpacking the Anti-Patterns

Let's try and unpack the entire series of anti-patterns buried in your question. The top four seem to be:

  1. You have a "project manager."

    There is no project manager role in Scrum. The only three roles in Scrum are Product Owner, Scrum Master, and Developer. If you have additional roles formally attached to your team, you aren't actually doing formal Scrum because:

    [A]lthough implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety[.]

  2. You aren't minding your own business.

    When you make comments like "[s]he seems to eating into PM role" you are worrying about the delineation of roles (and possibly political concerns) that don't have anything to do with you. Unless you're the project manager or the Scrum Master, you don't have any obvious skin in the game. Unless there's an impact on the team (we'll get to that in a moment), the best thing you can do is mind your own business and let the PM and SM work it out between themselves.

  3. The term "bossy" is often sexist.

    Micromanagement can be a legitimate problem, but in American English the term "bossy" is often used pejoratively to describe behavior by a woman that would be considered a perfectly legitimate management style when performed by a man. So, make sure you aren't coloring this with cultural or personal preconceptions about what female leadership or female management styles should look like.

    If it turns out that your newly-minted Scrum Master is truly directing (rather than coaching or refereeing) the newly-minted Scrum Team, then you may have a legitimate concern that should be brought up respectfully and constructively in the next Sprint Retrospective. Learning the responsibilities of a new role is always challenging, and that goes for your entire "new to Scrum" team, not just the Scrum Master.

    The entire Scrum Team needs to continuously refine its internal processes to fit the needs of the project, as well as the skills and abilities of the team members. This doesn't happen overnight, and is why teams generally go through the three of the four stages of group development (e.g. forming, storming, and norming) before they can successfully get to the "performing" stage.

  4. Scrum is not based on "autonomy."

    While self-organization and continuous process improvement are central to Scrum theory and values, the underlying principles are about collective ownership and collaboration, rather than "autonomy" in the sense of doing things your own way without regard to the impact on the team as a whole. There's no place for "cowboy agile" in Scrum.

As a member of the Scrum Team, you should certainly be addressing any process issues constructively with the rest of the team. At a minimum, your Sprint Retrospectives should be addressing issues with the team's process, with a focus on how to collectively iterate towards a more effective process for the project.

Whether or not you end up doing real Scrum or just a Scrum-like implementation, you need to improve the level of communication within the team and between team members. Without effective interpersonal communication, and without continuous conversations about how to improve the team's process, nothing will change for the better.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.