Scrum Master and Forming teams

... and best tips how to start with forming teams?

I have had similar situations and I'll answer to each one separately. It is going to be long because unlike @Ian, I can't give short answers that mean anything useful.  

If team is switching project alot (every month) should i do DoR, DoD regardless of stable long term project and adjust definitions on the way?

For me, DoR stays the same.  It really doesn't matter what project you are working on.  The way the team knows if a story is ready for inclusion in a sprint usually doesn't change. Our DoR usually involve things like "story is pointed, impediments addressed, dependencies removed".  Those are pretty consistent.  DoD usually stays mostly the same. There could be minor differences in how delivery is done or something similar but it usually stays the same.  Our DoD usually involves things like "all acceptance criteria has been met, Development team all agrees that adequate testing has occurred, automated tests written for all newly added code."  Again, those usually do not change.

How to handle dominant person challenging and undermining my role as scrum master?

This one has some controversial statements so anyone reading please provide more politically correct solutions if you have them because I'd like to know them also. Scrum Masters in most organizations have no authority to deal with this. So I usually resort to some subtle manipulative tactics.  Let the person win some arguments when you know that their idea is going to cause issues.  Then when the issues manifest, make sure that they are discussed in Retrospectives.  Remind the team that they decided to follow the recommendations of the "vocal one", ask them how they felt about the results, and then ask what could have been done different.  Remember that as a Scrum Master you equally participate in the Retrospective.  I will frequently provide my input by prefacing with "According to Scrum/Agile practices, ..." This helps them to realize that what they did wasn't Scrum/Agile, that you actually do have some knowledge of what is going on and can provide good ideas. Yeah, I know it is pretty crappy of me. 

There is almost always some managerial figure that can be involved.  If the organization has decided that Scrum is going to be embraced, then the managerial level should be willing to help deal with this.

..., PO stopped the conversation between two devs as they went technical, should i ignore first time and second time say this should not 

be done by you, you are only observant ? ...do scrum master give first time free pass or no free pass, immediate talk and discuss?

My preference is first offense results in private conversation with the individual that interrupts where I reinforce the purpose of the Daily Scrum and the individuals involvement. Remind them that they are there as an observer and the the Scrum is for the sole benefit of the Development Team.  Second offense results in my stopping it in front of all in attendance, again with explanation.  What I find is that the third and any subsequent offenses are usually handled by the Development Team themselves.

...Scrum master teach agile values and ways between the sprint as people are focused and starring hard on the monitors, ignoring all around, when they go for coffee they care less?

I sit with my teams.  I support two teams currently and I have a seat in each area. I switch back and forth between the seats at random intervals.  I use the time to listen to the teams talk.  It helps me to understand what they do every day and it also gives me an opportunity to speak up and impart some knowledge.  I also will share articles I find online with them via our chat system.  They come to trust that I only share things that are relevant to them so they usually read and comment on them. I also take EVERY opportunity to give them Agile/Scrum advice. If they had any kind of conversation during Scrum that I feel could use some "guidance" I will ask them after they finish if I can speak to them quickly about the topic.  Again, they have come to respect that I only do this when it will benefit them.  

How did I get to the point where they respect me in this way?  Persistence. Do not give up and continuously try to help them.  I have also let them fail on many occasions and then use the Retrospectives to coach them. Failure is a huge motivator for change.  I will let small failures occur. If I see them on the way to a big or damaging failure I will step in immediately. 

how do your days as scrum master look like in one iteration (what do you do and why),

I spend my day improving my knowledge of Agile practices and team dynamics. I study everything I can find.  I share things with my teams and with the Scrum Master team we have here. I share information with our Managerial Staff including our VP level.  I observe my teams looking for ways to help them become more self-sufficient and high performing.  I also make sure to take some time for myself.  It is sort of like the "put your oxygen mask on first, then help others around you" thing on airplanes.  If you don't take care of yourself and make sure you are "healthy" you won't be able to help others. 

If team is switching project alot (every month) should i do DoR, DoD regardless of stable long term project and adjust definitions on the way?

In my opinion, no. Your DoR and DoD should be pretty stable across the board. Think of it as quality control. Your quality should not increase/decrease just because you switch projects. On the other hand, your team may decide to add or remove things from these definitions as they see a need to do so.

How to handle dominant person challenging and undermining my role as scrum master? 

Like Daniel Wilhite said, Scrum Masters do not have authority over anyone. From my experience, people will come around to your suggestions and teachings once they understand the purpose of the changes and see the end result. For example, I've worked with several people who were against doing Scrum ceremonies (meetings) because they were time consuming and saw little value in it. Many of the retrospectives were centered around why they thought meetings were a waste of time. I think it's important to listen to everyone's complaints and try to understand why the things you want them to try don't work in their minds and find the actual root cause. In this case, they didn't see the value in the meeting because they were not coming in prepared, weren't having the discussion they needed to, and they ran out of time before fulfilling the purpose of the meeting. In order to remedy, we came up with ways to fix that and tried them out til one day I no longer heard anyone complaining about having to go to meetings. It's not a perfect answer, but it will take time for them to trust that you have their best interest in mind.

Once on daily, PO stopped the conversation between two devs as they went technical, should i ignore first time and second time say this should not be done by you, you are only observant? Related to above do scrum master give first time free pass or no free pass, immediate talk and discuss?

I am curious as to what setting this was in. Stand-up, for example, shouldn't get too technical. It's time boxed to 15 minutes, so you want to make sure that everyone understands what everyone else is working on and if there are blockers or time commitments that may not be met. If everyone started getting too technical with what they were working on, the purpose of the stand-up gets lost. Same can be said for some backlog refinement meetings. You don't want to get too in the weeds about the details of the project if you are not quite starting on it yet. On the other hand, if this is a purposefully technical conversation where two devs need to architect a system (for example), then I can see why that could get in the way of things. If you see something that is detrimental to the team's productivity or the purpose of a meeting regardless of who it is, I suggest having a private conversation about it with the offender. I usually ask the people affected if they were bothered by what happened, and if so I will go talk to the person who did it and explain how it affects the team member(s) and what they could have done better. I would not suggest doing this in front of everyone, especially when it occurs because now you are contributing to the issue of detracting from the conversation at hand. Sometimes the behavior becomes a serious recurring issue that the team should all talk about during a retrospective.

How can scrum master teach agile values and ways between the sprint as people are focused and starring hard on the monitors, ignoring all around, when they go for coffee they care less?

Make yourself involved in the conversations. You don't need to talk, but at least observe. I sit next to my teams so I can listen to every conversation they have. Attend any of the meetings they have outside of the ones prescribed from Scrum. If you see a recurring issue that you may be able to help with, offer your help or write it down as something to discuss during retrospective. Other things I do is taking a look at the product backlog and making sure that it's in good shape. You may need to nudge the PO to make sure things are prioritized and that there is a clear plan for the next 2-3 sprints. You may need to nudge your developers to make sure they are writing up good bugs or stories so that the PO can understand it. I also have weekly 1:1:1 with the PO and engineering manager to make sure that product and development are all on the same page. You may have a 1:1 with the engineering manager to address where you see issues with team dynamics or individual morale. There is a lot you can do. I would start with just getting involved as much as possible as an observer. 

One last big question, how do your days as scrum master look like in one iteration (what do you do and why), exclude events planning and facilitating?

Outside of planning and facilitating meetings, I also manage the team's physical scrum board (I set it up at the beginning of every sprint), remind people when meetings are about to occur, attend any and all meetings to make sure I'm on the same page as them, but also to make sure that the purpose of the meeting is fulfilled. If they are having discussions about the sprint in our area, I come and listen in to try to understand the problem they're having and to offer suggestions when I can, or ask questions to help them think about the problem. I also try to take notes for when I see problems during the sprint so that we can discuss it during retrospective, or come up with an activity to do for retrospective. I meet with my fellow Scrum Masters once a week to discuss problems we are having with our teams and how we can solve them. I do research online on different retrospective activities, team building exercises, and ice breakers. I come up with ways to reward the team at the end of projects or completing everything in a sprint. Some days I just spend time trying to learn more about agile practices and different frameworks, or come here to help other people. Some days you will be so busy that you know exactly what you need to do. Other days you need to take it upon yourself to be involved or grow your knowledge and skills as a Scrum Master.

Best tips on how to start with forming teams:



I would try to introduce a quick ice breaker (5mins or less) at every meeting to make sure people get more comfortable with each other in terms of familiarity and just being able to talk aloud/contribute.

I would definitely try to try to stick with whatever process your department has set as a standard to start for a few sprints before you change it up. Make sure you're doing things "correctly" before everyone gives up and tries suggesting something else.  When you do retrospective, try to do a small number of simple changes and ensure that it is being done. 

You don't want to bombard the team with too much at once. You really want to focus on making sure they get things right (and understand why they are doing it) before you change anything. It will be a lot of coaching and understanding the team dynamics on your part.

• If team is switching project alot (every month) should i do DoR, DoD regardless of stable long term project and adjust definitions on the way?

Product Backlog items should be "ready" for Sprint Planning, and a product increment should be "done" when the Sprint is finished. What can you therefore do to put the emphasis on products rather than projects?

• How to handle dominant person challenging and undermining my role as scrum master?

It's good to be challenged but not undermined. How does the undermining actually happen? What weakness in your position have they found, and how is being exploited?

• Once on daily, PO stopped the conversation between two devs as they went technical, should i ignore first time and second time say this should not 
  be done by you, you are only observant ?

Regardless of technical content, was the conversation proving helpful to the Development Team? Can the team be trusted to hold a focused 15 minute Daily Scrum on what they will do that day...and without either you or the PO being present?

• Related to above do scrum master give first time free pass or no free pass, immediate talk and discuss?

What can you do to detach yourself from the running of the Daily Scrum as far as possible, so the team self-organizes and develops their own plan for the day?

• How can scrum master teach agile values and ways between the sprint as people are focused and starring hard on the monitors, ignoring all around, when they go for coffee they care less?

Expose the truth by putting transparency over contentious matters. Ask questions which invite the team to think about what is happening and the assumptions which are being made.

One last big question, how do your days as scrum master look like in one iteration (what do you do and why), exclude events planning and facilitating ?

Most of the day is spent establishing transparency over value, backlogs, work in progress, Ready, Done, undone, and technical debt. This can easily absorb all of a Scrum Master's time with a new team. As they mature, more time can become available for agile coaching outreach, which is part of the service a Scrum Master ought to provide to the organization.

Thank you all for feedback. Certifications and books versus real life is like day and night but fun and interesting.

I like the approach to sit with the teams for a while and listen, currently each team has separated space and myself as well (limited space), but i think i can find a spot for few hours to sit and observe. This may proven very useful long term to see team dynamics and bounding.

Feedback for definitions THUMBS UP, did not look at it that way.

It's good to be challenged but not undermined. How does the undermining actually happen? What weakness in your position have they found, and how is being exploited?

Weakness is that i am new in the role as scrum master with 2 month experience and person undermining is a experienced dev with experience in scrum as well. He is more of force things loud and fast, i am more off small steps in neutral mode without stepping out of servant leader role. 

What i do now i TRY - FAIL - LEARN, i failed many times and learned already what to do and what not to do (transfering things that work from one team to another if possible). I told the team twice provide feedback, if i do not get it i can not adept (transparency).

Regardless of technical content, was the conversation proving helpful to the Development Team? Can the team be trusted to hold a focused 15 minute Daily Scrum on what they will do that day...and without either you or the PO being present?

Both teams finishes in time box 15 min. Conversation in my mind was proven helpful and there still had 6 minutes to burn.

Thank you Elisabeth i fully agree.

You don't want to bombard the team with too much at once

One more question ;) one of many?

How do you handle virtual teams, one of the teams works with virtual team from which they get insights into new project, they communicate directly and regular. I see frustrations some times in the team that they wait for feedback and communication is not at best. I ask if can assist, they say nothing to do here. How to handle this situations ?

It sounds like your expectations are different from your Development Team as far as interaction with the virtual team.  If the Development Team doesn't see a problem or voice concerns, then I do not see impediment to deal with.  However, if you and the Product Owner can see an impact to the team's ability to execute, then the two of you should bring it up in a Retrospective and discuss it as a Scrum Team. 

It also sounds like the virtual team is very much a stakeholder in your work.  They should be present in the Sprint Review in order to provide direction on the Product Backlog. Your PO might need to do more work on establishing and maintaining the communication lines with the virtual team. If your team is constantly waiting on the virtual team to provide information, then to me it sounds like the PO is not doing an adequate job of gathering input/feedback from the stakeholders. 

Having said all of that remember that Agile and Scrum prescribe having co-located teams for a reason.  But it is very common in today's economy to encounter the need for remote or virtual communication.  While technology is great, it still will not result in instantaneous responses.  And since you can't actually see what is going on at the other end, you may not be able understand that in order for the virtual team to respond they have to do some investigation or data gathering.  You can see the same kind of delays when working with co-located teams when stakeholders are involved.  They do not always or can not always react on your schedule.

I like the approach to sit with the teams for a while and listen, currently each team has separated space and myself as well (limited space), but i think i can find a spot for few hours to sit and observe. This may proven very useful long term to see team dynamics and bounding.

Observation is high on list of Scrum Master Tools. But beware, observing a system changes the behavior of the system. We need to find a way of not making it too obvious.