Scrum is about collaboration, trust and empowerment. It is going to be very difficult to make people do those things. They have to want to do them. Some things I would suggest include: Try and build up trust - perhaps by giving them good advice or by being an effective facilitator of their meetings Spend time coaching - try to get them to understand why they would benefit from following the Scrum framework Use the retrospective to hightlight challenges the team faces Introduce them to teams that are successfully using Scrum If you do decide to speak with your managers, ask them to motivate the team to be more agile. Perhaps by setting agile objectives (e.g. "Demonstrate a good Scrum process") and rewarding them if they do this well.

As a Scrum Master, you can do your best. But your best might not be enough. I have seen people that were so distrusting and obviously hurt by their former bosses and management strategies of backstabbing, blaming and favoritism that they could not let go of those experiences and bring up the initial mental investment of extending a minimum of goodwill and trust to a new beginning. Teamwork is all about trust. "I need help" is a basic, fundamental sentence in team work. If you cannot find the courage to say it, because you have been experiencing for years or maybe even decades that this sentence only causes you pain from people that will exploit your weakness to it's fullest to gain something, then teamwork is impossible. I have had the fortune of witnessing this first hand. We had a big company with ~50 developers and we transitioned from command and control to multiple Scrum teams. Of the new formed teams, all under the same conditions, under the same Agile Coach and same line manager that did not interfere, some worked great, some just worked okay and some just didn't. Or only formally, but not as a real team. As a Scrum Master, you can educate and offer the opportunities for teamwork, but they have to be taken. You cannot force teamwork and trust on someone. If they don't put out a little bit of good will and see what happens if they are "weak" and ask for help but instead stay in their defensive shell, there is little you can do. You are a Scrum Master with a potential team member, not a psychologist with a patient. You can lead by example. You can offer opportunities. You cannot make people take them. And you certainly don't have the skillset to fix people's trust problems. As a step forward, if you find that your offered opportunities are not accepted, find out what the problem is. Do they not trust you? Then you need a different Scrum Master. Do they not trust each other? Then you need maybe a different team composition if you have multiple teams, or you need to replace those people that aren't trusted. Do they not trust the whole process, because they have been burned by the company before? Then there is little you can do. Make a list of opportunities you offered, explanations you gave, workshops you had, teamwork games you played, demonstrations to show that Scrum and teamwork produce better results. Go through it yourself and think about other opportunities. Talk to your team about it. If you cannot find a solution, talk to your manager about it. Scrum is not a silver bullet. It works through team work, it cannot enforce team work. If you find member(s) on your team to not be team players despite your best effort, you need to switch them out, as you would in any other team.

A good place to start would be to try and work out what is motivating this behaviour. Is it that they don't feel these working practices have value? Maybe they are introverted and feel uncomfortable when collaborating? Once you have a feel for their motivation it will hopefully be easier to work out an approach.

It will be a challenge, but there are a few possible approaches that can help: Combine the Scrum Master role with another role (such as an automation test engineer) - organisations that hire for combined roles will be less strict on the Scrum Master experience Look at charities and NGOs - salaries won't be as high, but they are typically a bit more open-minded in their recruiting strategy

Some suggestions: External speakers Senior management guests (e.g. CTO) Maintain a 'top 5 issues faced by our teams' - use outputs from retros and regularly present the list to senior management Have fun - provide snacks, ask Scrum Masters for the funniest thing that has happened to them recently, etc. Go offsite, or to alternative settings like parks, etc. Above all, make the meetings interesting and fun to attend. A community of practice is never going to be a priority for the Scrum Masters, they need to want to attend.

A common theme in Agile Software Development, and especially in Scrum, is the idea of a cross-functional team. There is no concept of an engineering team finishing something on Friday afternoon and then handing it off for testing later. The team, as a whole, does all of the design, development, and testing necessary to complete the work. This doesn't mean that you may not have specialists, but you would take a whole-team approach and eliminate hand-offs. If you are appropriately sizing the work and developing the skills to get work done across all of the team members, there's absolutely no reason why you cannot design, develop, and test work in one Sprint. Get to the state where the team can do that.

From a technical standpoint, code metrics should be baked into your test-driven development (TDD) or acceptance testing, preferably in an a fully-automated way. However, from a Scrum perspective, the framework is not prescriptive. The correct framework perspective is that gathering and checking your current code quality metrics should be part of your Definition of Done. Reviewing the usefulness or accuracy of your metrics should be an ongoing part of your inspect-and-adapt cycle, which means: Any impediments related to metrics that are raised during the stand-up should trigger a review. Your current processes (including code quality metrics) should be reviewed during each Sprint Retrospective, provided that the issue fits within the time box and you don't have higher-priority process issues to discuss. At any time, work related to your code quality metrics can be added to the Product Backlog for prioritization by the Product Owner.

TL;DR I refuse to offer a personal opinion on the qualifications of individual instructors because we don't allow polling questions on PMSE. In addition, evaluating the cost/benefit of any particular class is out of scope for PMSE. However, the question about whether instructor qualifications matter for Scrum training seems valid and on-topic here. Define Your Educational Objectives Certification training has two goals: Get certified. Get educated. If you only care about #1, then it doesn't matter who the instructor is as long as you learn enough to pass the exam. On the other hand, if you want to learn things and get an education, then of course the experience, teaching skills, and background of the instructor will matter. Would you rather learn about space-time theory from Stephen Hawking, or from my cat "Mittens?" My assumption is that you'd learn more from a respected expert in the field, but it's up to you to assess whether any given instructor is sufficiently expert (and talented at teaching) for your educational needs.

I'd focus my answer on the levers that I can move, either easily or with some effort. The levers I cannot move, such as no product owner or the answer provided by the PM to the Steering Committee of a single iteration, are simply facts that create the environment in which you are working. Serves no purpose to ask questions about it or analyze it. It just is. The four iterations is a work estimate. It lives in some probabilistic distribution that can be as optimistic as one or as pessimistic as 10. Since it was not provided in this blurb, then my first course of action is to try to uncover where the four iterations live within the range. This drives the risk of the work from a time perspective and how I will track and report progress. Adding additional resources could help. It obviously depends on the resource elasticity of the work, which varies from job to job. To assume Brooks Law will always adversely affect you is simply wrong. That said, my next action would be to analyze the elasticity of the work and determine where I am in resourcing compared to where I think the point of diminishing returns is. Then, I will recommend staffing the project to that point. Then, I will determine if the BA's limited utilization on this project has any adverse effect. If not, then leave it. If so, then I would argue resetting his/her priorities such that (s)he becomes full- or near full-time on my gig. Once these levers are pulled, I would analyze the likelihood of my end date and report in a non emotional way where I will most likely finish. Pressure and potentially angry senior stakeholders notwithstanding, an answer well substantiated by thoughtful analysis is the answer. I would continue tracking, reporting variances and updated forecasts, in a non emotional and frequent way.

It is possible, but not recommended by most experts I know of, as these two have conflicting roles and responsibilities. PO is focusing on getting the most bang for the bucks, while the role of SM is to help the team get to and maintain its full potential in the long term. This includes shielding the team from external discruptions and ensuring they get only as much work as they can handle. So the PO is continually pushing the team to deliver more value, while the SM is pushing back to avoid overloading the team. If these two roles are being handled by the same person, one side usually wins over the other, resulting in imbalance. Mike Cohn explains this with a nice historical example in his blog. This question was also asked on Programmers.SE.

Individual rewards and incentives rarely work the way that was intended. Especially not in an agile team. As the old saw goes "Tell me how you'll measure me and I'll show you how I'll behave." As Spock would put it "The needs of the many outweigh the needs of the one." But perhaps more importantly, consider why you want to reward individuals and what you would reward them with. Mostly, we reward people to motivate them to do better. Turns out, financial incentives don't work for this. If you really want to motivate individuals and teams, appeal to their sense of autonomy, mastery and purpose. Have a read of "Drive" by Dan Pink. Fascinating read.

In a proper Scrum, it's definitely option 2. It's the team as a whole who decides about process changes. The Scrum Master is a servant-leader, not a command-and-control style leader. So even if she is convinced that a specific change in process is necessary, she shouldn't (and can't) force it to the team: she has to convince them, or preferably explain the situation, the problem(s) she sees and the available options to resolve it, then let them come to the decision themselves. That's one of the biggest challenges of being an SM, to keep one's mouth shut and instead just wait and listen to the team Note that even if the SM is perceived by the team to have the authority to make process changes by herself, if the team members don't fully accept such a change, it won't work; they will have buried resistance which may very well sabotage the process and eventually even break the team if not handled properly. Exceptions are always possible, of course So the above is not to say the SM can never, ever impose process decisions onto the team. I can imagine situations when e.g. the team is undecided for some reason (they are new to Scrum, and/or they are not accustomed to be a self-organising team so they need some hand-holding), so the SM has to make a decision on their behalf. However, she should still coach and support them towards becoming independent as soon as possible. Or if the proposed change is small and experimental, like "let's try the Boat Retrospective this time for a change". But by and large, these should be rare and limited exceptions rather than the norm.

In my experiences the one of disadvantages being a Scrum Master is when the organization (small to mid organization usually) not understanding enough SCRUM as a whole package, especially the new Scrum adapting organization, which mean there is still conventional project manager paradigms that organization expect from a Scrum Master.

I would take great care diving straight into being a Scrum Master, as you risk being perceived very negatively by teams. I am a Scrum Master who has come from a development background, which makes it much easier to fit in with the team naturally and not come across as 'management'. There are three stages of Scrum Teams, sometimes referred to using Shu-Ha-Ri; a martial arts term. Your background will mean you fit into teams in some of these states much easier than others. In the 'Shu' (Obey) stage teams are learning the fundamentals. This requires more of an enforcement attitude from the Scrum Master, and is where technical knowledge would be most useful. This is where teams are likely to be creating their 'development best practice' - so to me the scrum master should be enforcing code reviews, helping to implement XP or whatever approach the organisation are taking, and suggesting (often technical) additions to the definition of done. This is where many 'Scrum Consultants' (who are often not technical) seem to be failing the industry to me - they bring in 2 week sprints, self organised teams, and backlogs, but do not address the most important part - the underlying development standards that Scrum was built and relies on. Most teams never leave this stage, and this is where Scrum Masters who are not technical are really hurting the industry. The next stage teams reach is 'Ha' (Digress) where they are working as a good Scrum team, and start to understand why they are doing things, rather than just following the process. This is where the team have the basics down and are working as a good team already. At this point they must have good development practices in place, so a Scrum Master who is less technical could probably get by. The team is motivated to keep up their technical excellence, so the Scrum Master doesn't need to be driving this, but might want to keep reminding the team to keep up their technical excellence. There is still a risk development practices could slip and the team not notice, and without being technical a scrum master may never know. If you get the rare chance to work with a team at 'Ri' (separate) who is hyper-productive, I don't think you need to be technical. This is probably the best sort of team fitted to your situation. Your psychology background would probably make you better than most Scrum Masters at really getting to the bottom of deep, hidden issues that many Scrum Masters might miss, so you may want to try to specialise in working with awesome teams that are trying to etch out additional improvement. This is where teams are coming up with their own ways of working, maybe abandoning Scrum all together. I have a software development background, and have led multiple organisations through the Shu and arguably Ha stages - often after agile consultants have already done a lot of damage by bringing in Scrum without any consideration of the development practices it relies on. If you are involved in agile adoptions, ensure to work with a development manager or senior developer to put best practice in place BEFORE bringing in agile. Without this, non technical Scrum Masters can seriously break teams and organisations. You can do it, but the more technical knowledge you can get the better.

Summary This previous PMSE answer clearly summarizes why there is an inherent conflict in having a Development Team Member perform double-duty as Scrum Master: The Scrum Master role is a process referee role. This is inherently a conflict of interest with the Team Member role. For the same reason that you have (theoretically) impartial referees in professional sports, the Scrum Master role should be separate from developer roles. — CodeGnome, PMSE Answer Scrum Master and Development Team Member are Separate Roles The Scrum Master is defined as a separate role within the framework by The Scrum Guide: The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. — The Scrum Guide, Schwaber & Sutherland, p. 5 While a separate role doesn't always require a separate person, effective Scrum practice requires that this triumvirate should have a clear separation of duties in order for the framework to operate as designed. The Scrum Master is also has a full page of unique responsibilities within the framework. See The Scrum Guide (Schwaber & Sutherland, pp. 5-6) for the complete list, as it's too long to simply and copy and paste here. In short, while the framework doesn't forbid a team member from also wearing the Scrum Master hat, it is extremely unlikely that a full-time developer will have the bandwidth to be an effective Scrum Master (or vice-versa). Part of a Scrum Master's job is to manage Scrum artifacts and provide an interface to the broader organization; such tasks limit the capacity of a single person to provide service delivery as members of the Development Team, and will create a more or less permanent drag on the team's potential velocity. In my considered opinion, this unnecessary drag is itself a conflict of interest. Responsibility vs. Authority Any organization that doesn't value the Scrum Master role sufficiently to create a proper separation of duties is unlikely to understand the inherent conflict of interest between service delivery and process refereeing. This means that the Scrum Master's job of removing process impediments and enabling organizational change may be limited by politics and org charts. Any time a position has responsibility without sufficient organizational power or delegated authority to carry out those responsibilities creates a situation ripe for failure. Even if one disregards the inherent conflict of interest in the roles, the consequences to the project in disregarding the separation of duties may be dire. Perhaps your organization will understand that you will have less time to develop when wearing the Scrum Master hat in addition to your other responsibilities. Perhaps they are also enlightened enough to see you as more than just another member of a service delivery team, and will actively engage with you on essential business process re-engineering issues. Perhaps and perhaps...but I have never personally seen this work out well for a project, or the dual-hat wearing person stuck in the middle. Your mileage may vary. However, I wouldn't bet my career on it.

I used to take pictures as well. Another possibility is having some (or many) take notes in a shared google doc. This also work for on-line retrospectives. The key point, in my opinion, are any action points. It's all nice and fine to dig down to root causes, but in many cases it's quite unproductive: many root causes lay outside of the scope of the project team and there's little if nothing that can be done to address them adequately. What are important are: the issues ("start doing", "stop doing", "continue doing") any actions to be taken, with somebody responsible for them This does sound like "team-themed" stories, so I think documenting them as stories, can also be appropriate.

This question seems to be from two mis-understandings about Scrum. I don't really see how it follows that Scrum Masters cause a reduction in quality by keeping focus on the definition of done. The Scrum Master does not write the definition of done, the team does. The Scrum Master helps the team enforce the standards of quality that the team has decided upon. The quote from Clean Code does not apply. Most managers might obsess about schedules, but Scrum Masters do not. They work with a different variable, they keep the scheduled fixed and instead adjust the scope of the project. A Scrum Master will drop user stories to keep the deadline the same. However, that being said, I think that Scrum takes an overly simplistic view to team structure. You need to build your teams with the right balance of experience and skills so that they can self-organise. Ideally, when a team has a gap, they can recognise it and ask for more support in that area. You can't just put random people together and hope for the best. Edit: As Jmort253 mentions, you have also assumed that a Scrum Master is non technical. This doesn't have to be the true, but in any case Scrum Master should limit the amount of directing and decision making that they do and instead make sure that they facilitate the team to make [technical] decisions.

TL;DR Is it or can it be a Scrum Master's responsibility to: setup/improve a code review software system? setup/improve the continuous integration process? provide scripts/macros/helper tools to make the development process easier/more efficient ? No, no, and no. These responsibilities rest with the self-organizing development team. If you turn the Scrum Master into a DevOps engineer, that person will no longer be able to focus on the core responsibilities of the Scrum Master role. The Scrum Master Role The Scrum Master is the shepherd and evangelist of the Scrum process. In other words, the SM acts as a process referee, and "removing impediments" generally refers to working with the team, management, and the stakeholders to raise the visibility of process-impeding issues and providing a constructive framework for all parties to cooperatively develop an organizationally-appropriate solution. The Team's Responsibilities If a Sprint Retrospective identifies code review as a process issue, then the Scrum Master should capture that issue and provide guidance to the team and the Product Owner on how the framework allows them to improve that part of the process. This may include: changing the "definition of done" to incorporate code review processes, the Product Owner adding a new user story to Product Backlog that prioritizes the installation and configuration of a code review system, or anything else that everyone agrees fixes the issue for the team and the project. The same is true for continuous integration and tool chains. Whether driven by technical debt or a desire to continuously improve the process, the Sprint Retrospective is the place to raise such issues. Ultimately, it is the Product Owner's responsibility to prioritize the work related to process improvement (by manipulating the Product Backlog), and the team's responsibility to implement a solution once that work has been prioritized by the PO. The Scrum Master's job is just to make sure that the Scrum framework is properly leveraged to give everyone involved the process tools that they need to do these things within the context of Scrum. If you take your Scrum Master off-task by assigning implementation work, then that person is no longer fully-dedicated to performing the tasks that are essential to the Scrum Master role. Don't do that. Intra-team process and technical implementation are responsibilities that rest within the self-organizing development team. Neither the Scrum Master nor the Product Owner should be sticking their thumbs in those particular pies.

Introduction Division of stories into smaller stories should be done by the Product Owner. Scrum Master and developers can help in that, especially during backlog refinement (grooming). Division of stories into tasks (meaning: technical tasks) is only the responsibility of the development team – this is about HOW the stories will be implemented. So I believe, neither Scrum Master, PO nor you (if you are not a dev) should not divide stories to (technical) tasks. I just answered a question about „who?” and not „when?”, but that was for clarification. Now answers to your questions: Answers a) The answer to „When?” is, in my opinion: during sprint planning. I think, no other formal meeting is intended for that in Scrum. Also whenever someone sees that a task may be added to the story, he may add it. But formally, HOW the stories will be implemented is discussed among developers during Sprint Planning meeting. b) Ask the Scrum Master to stop talking ;), to stop entering stuff to JIRA during the planning meeting. He should facilitate the meeting and encourage developers to do this work and not do this instead of them. Give pens and postit stickers with story names to developers and let them write on a sticker the tasks for that story. And take the keyboard from Scrum Master. He does not need it during the meeting. Give it to someone else. Think about empowerment, about encouraging for self-organization of the dev team. They will not start to do this job if SM is doing it for them. Some „space” needs to be created. Make them feel responsible for technical solutions, for dividing stories into tasks. c) SM should support PO before the planning in creating and splitting user stories and making them better understandable. Does he do that? UPDATE regarding a): The tasks like: design, tests, review should be a part of general Definition of Done of the team. I do not think it is needed to put them to the story during planning. It depends on what is the goal of adding them there - to have them visualized so that the size of the story can be estimated well or just to have a checklist if all the steps were done. If it is needed for estimation and the team prefers to have it written down, then it is fine. If the team do wants to have those tasks in JIRA to have kind of checklist (do they want? or you want it? :)) then a developer when starting to work on a story can add those generic tasks. During planning it would be enough to mention it - that's something that SM can do: "guys remember that you need unit tests as well". In my team tasks added to a story during planning session are more like: add a new button to screen A, create a new screen B, create a new db table, improve the SQL query. We put "unit tests" tasks usually when we know that in a specific story we expect a lot of effort in making/maintaining unit tests. Usually we do not write down "unit tests" task to a story as we all know it needs to be done.

TL;DR [I think] the only way to truly understand the benefits [of agile] is to become a certified Scrum Master. Is this a good idea? No. Agile practices encompass a spectrum of practices and frameworks well beyond Scrum, so a Scrum Master certification won't necessarily impart agility in a broader sense. In addition, doing more of something you dislike is not setting yourself up for success. Instead, you should look for roles in organizations or job sectors that use a framework more to your taste. You can even make desirable project management methodologies part of your job search or interviewing criteria. How is Scrum Mastering Like Teaching? If you hate math, should you become a math teacher? Probably not. You won't enjoy your time spent learning the subject. Even if you eventually master the material, you'll probably have a hard time inspiring anyone else to learn about a subject that you intrinsically dislike. In some ways, being a Scrum Master is quite similar to being a teacher. You are not only the shepherd of the Scrum framework for the organization, but you are also often called upon to: educate teams in the methodology, dispense Solomon-like wisdom based on your experience with the framework, and be an evangelist for the framework and its practices. Those things are hard to do if you actively dislike the very framework you're responsible for promoting. That will not set you (or your team) up for success with Scrum or any other agile framework. Instinctual Drift and ScrumBut In addition, if you lack passion for the framework or disagree with its underlying principles, you are going to struggle with finding solutions to process problems that don't violate core principles. Instinctual drift will lead you into grafting non-agile patterns onto your process, leading to a perniciously-persistent ScrumBut environment that will (over time) look more and more like whatever framework you do feel comfortable with. Recommendations Learn More About Agile Frameworks If you want to learn more about agile frameworks, by all means take a class or workshop to learn more about them. Take your pick from any agile topic that interests you, including: Scrum Kanban Lean Extreme Programming Cynefin Find Roles Based on Your Preferred Framework Despite what you may believe, non-agile frameworks are still quite prevalent in the field of project management. Whether as a developer or a project manager, you can certainly search out roles that use more traditional frameworks. In fact, if you go that route I would encourage you to ask employers about their project management methodology during interviews. Find out if they do big up-front design, or ask whether they use detailed specifications instead of user stories. Whatever it is you dislike about agile methodologies, figure out what your preferred approach is and seek out positions that value that approach. For example: Hate pair programming or cross-functional teams? Find individual-contributor roles. Hate user stories? Find roles that are based on up-front specifications. Hate incremental planning or iterative development? Find organizations that use waterfall development or traditional project scheduling approaches. Whatever it is you want, it's out there somewhere. Unless you're a serf, vote with your feet and work within an industry or organization that uses project management practices more to your liking.