How to find the best Scrum Master for your team and organization? Many teams often ask who is the best person to fill the Scrum Master role. The assumption is that this role is best filled by someone who was previously a project manager [or is the current project manager of a team]. Clients ask: “What’s the difference between leading a RUP (or Waterfall) team, and leading a Scrum Team?”
From my experience traditional project managers (PM) have a great deal of difficultly releasing control of the team and this is exactly what needs to happen if the team is to self organize and collaborate effectively. PM’s can certainly learn to be effective Scrum Masters but the search for a SM should not be restricted to the organizations pool of Project Managers. Read the Agile Project Management article on AgileProgramming.org
Is there another group within in the organization who are better suited to being Scrum Masters? I feel that the answer is “yes”. I’ve found that individuals who are charged with ensuring the quality of the product make ideal Scrum Masters. This includes individuals with jobs titles such as: Testers, Test Managers, QA and/or QS managers. They are focused on the quality and integrity of the product without feeling the need to control the activities of individual team members.
For organizations that have reached a high level of maturity, there is also the option of the team nominating their own Scrum Master. If the team is being asked or self organize and there is clearly a need for a facilitator then it is likely that someone on the team will emerge as the Scrum Master. This final approach [i.e. the team nominating their own ScrumMaster] is probably the most intimidating for an organization because it takes so much control out of the hands of management.
But allowing the team to select their own ScrumMaster also produces the most benefit by place control where it’s most needed … in the hands of those who do the work.
Table of Contents
Product Owner and Scrum Master should not award credit
Seeing the long-term affects of awarding partial credit has convinced me the product owner and Scrum Master should not award credit for something that isn’t done per the agreement. An exception might be if the team came to you well before the review meeting to renegotiate, but even then the outcome should be reduced scope (fewer features) rather than reduced quality (fewer tests).
The times it’s hardest to do this are the times you have the most to gain from doing this. Awarding credit for work not done to the agreement robs the team of growth opportunities and dilutes the credit when it really was earned. The team can get into a habit of not taking the agreements seriously enough to do the last few millimeters of work that often turn out to be the hardest. Some people say the Scrum Master shouldn’t even allow the team to demonstrate work which doesn’t meet the definition of done. Scrum Master training should deal with this problem.
A related topic Ken Schwaber has become adamant about is the danger of a team creating an artificially high velocity by getting into “technical debt.” Doing this for too long will lead to a “design dead” (unmaintainable) product. Teams should allow time for *refactoring* to keep the code quality high.
Scrum is simple but hard (also for the Scrum Master)
Ken Schwaber’s comments in this scrum development thread are fantastic; we need to keep in mind that Scrum is a set of principles, not a call to follow a brainless list of processes.
I like something I heard Ken say during his course: Scrum is simple but very hard to do. Then he proceeded with an analogy to chess. We can all learn chess moves in a few hours, but mastery of the game takes a lot more.
So what does it take to be successful at a game like chess? I have some insight into this because much of my family plays chess, some even competitively.
Smart in the “right way”: I don’t think everyone can reach a high level like “master” in chess, even if they played their whole life. You must be clever and a strategic thinker to do so. I consider myself to be fairly intelligent but I somehow can’t seem to get past a certain level in chess–my brother, much to my chagrin, beats me consistently.
Experience: it’s worthwhile to learn common “lines” in chess, which are basically patterns that show up frequently in high-level play.
Courage and Bravery: to win you must think outside the box and risk in order to win. Overly conservative play will lead to a stalemate.
Innovation: Creativity is key to success. This is how good players beat computers.
A passion for the game: if you don’t care you won’t stick around to reach a high level of mastery.
I’m sure there are others keys for success.
The term “common sense” describes the light framework and principles of Scrum; however, it is difficult because it requires intelligence, bravery, passion, and innovation to succeed within the framework (as with most things worth doing).
