Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 2 years ago.
Improve this question
I am just curious, since for a scrum-enabled development process the Team Leader (TL) role is merged with Scrum Master (SM) role and the team is supposed to be self-motivated, self-organised and self-driven.
Without a Team Leader (and architect!) inside a team - who is making decisions on a future-proof ways on the implementation? Say, which libraries to use, client data-handling, etc.
Based on the scrum concept, such decisions should be made by the team collaboratively or by the individual team member. Chances are they will not be qualified/experienced enough and the decision could cost millions in the years to come (even one or two years perspective).
How in scrum concept is this addressed, please?
Thanks
Scrum is only the delivery process. Technical decision making should be done by relevant responsible people. Those decisions may come after discussions and team meetings. Team members can also participate to these meetings if required. Role of the scrum master is to make sure the backlog items taken into the sprint is delivered. It has nothing to do with technical decision making. (Scrum master is responsible to remove the blockers and make the team move towards the sprint goal) The team can allocate time for architectural decision making or design/redesign process when they take in a task during the planning meeting.
For example, the TL may have a 4 hour task in scrum board to do the design. If this task involves a meeting with the architect, and the architect is offsite, scrum master should take necessary actions to schedule a meeting and make sure this blocker is removed. May be he can arrange a call between them.
Also it is wrong to think technical leader should be the scrum master. Those are two separate roles and may or may not be the same person.
In Scrum there are three roles defined:
Scrum Master
Product Owner
Development Team
The Scrum Master helps the team to follow Scrum and to remove impediments. The Product Owner looks after the backlog of work and prioritises things.
The Development Team does everything else. There are no defined roles in the Development Team, but instead we have capabilities.
For example, the Development Team has a capability to do development. It also has a capability to do testing.
There is nothing to stop a Development Team having a capability to do architecture. For example, it might have a team member who is from an architecture background or perhaps several team members have architecture experience.
As for the Team Leader role, there is no need for that as everyone in Scrum can act as a leader. For example, if somebody in the team is really experienced in database work, they might show leadership when the team is working on database work items.
who is making decisions on a future-proof ways on the implementation?
The team does.
An experienced Scrum team will get together regularly to talk about 'the big picture'. They will think about the future of the implementation, about the way its architecture, etc.
which libraries to use, client data-handling, etc.
Who has experience making decisions on which libraries to use? They might be a good person to suggest an approach on which libraries to use. The team can then discuss it and agree on an approach. The same goes for client data-handling.
This is collaboration. Everyone has a voice and everyone is a potential leader.
Chances are they will not be qualified/experienced enough and the decision could cost millions in the years to come
If the team is concerned that they don't have enough experience to make important decisions then they should raise that as an issue. Some possible solutions include:
Get additional training for team members
Bring somebody into the team with more experience
Use communities of practice to get advice
The Agile Manifesto directly addresses your question in the Principle that mentions self-organizing teams: "The best architectures, requirements, and designs
emerge from self-organizing teams." Relative to the other well-known Agile methods, Scrum perhaps does the best job of trusting "motivated individuals" (per another Principle) to do so using what scientists calls the "group mind." My coaching practice is based on my review of scientific studies related to teamwork. These have shown repeatedly that cross-functional small groups with diverse backgrounds will out-perform a single expert in decision quality over time. Scrum facilitates this by making people plan everybody's work together and holding them accountable to the group through the scrums and Demos.
That doesn't mean you can't have a technical expert like an architect on the team or providing input to the team. I agree with Leni that it's best not to have the technical expert be the SM, as that consolidates too much social power in one role and places further psychological blocks to true self-organization. (Having a full-time SM prevents real self-organization from the social psychology perspective, so I have members rotate the role.) But those experts can serve as advisors by coordinating bottom-up standards development across teams, providing input into user stories, sitting in on various teams' Planning Ceremonies and Demos, etc.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
We are acting Scrum in our department now. But the up level management structure is traditional, such as Project Manager(PM), Development Manager(DM), Team Leader(TL) and Test team leader(TTL).
Team Leader act as a Scrum master, he controls all the things in our team: communicated with PM/DM/TTL, development management... Our PO's responsibility is just maintaining PBL.
Our managers and team member are accustomed to the traditional management type, they do not care Scrum, and they said some Scrum rules are hidebound.
I act as another SM, I want to change the current status.
But I haven't any headship, just is an ordinary developer in our department. Does anyone has this kind of bother too?
Thanks in advance!
I heard a lovely saying once and can't remember who said it. "They want Agile but they don't know what it is - so we give them Agile but we don't know what they want."
It sounds as if this is happening in your company. Someone, somewhere wants the team to use Scrum, but it's not the team.
That must be a difficult job for an SM, especially if you're doing it unofficially! There are some things I can suggest for you. First, learn some basic coaching techniques: positive language, GROW framework and giving and receiving feedback. This will give you some additional tools which are outside of Scrum and support someone in a leadership rather than a management position (even an unofficial SM can become a leader).
Then, don't worry about the actual practices. If someone has mandated Scrum then the team will be forced to do this anyway. Instead, concentrate on the values and principles of Scrum - particularly collaboration, communication and transparency. Help the team to work with each other instead of being silo'd away. You will have to be an example for them. Don't mandate pair programming, but do go over and pair. Don't mandate stand-ups, but do have conversations first thing in the morning and draw in as many people on the team as you can. Look at the principle of "Continuous Improvement". Learn how to do root cause analysis and the 5 Why's so that the team can understand better why things are hard and take action themselves.
I also recommend Mary Lynn Manns and Linda Rising "Fearless Change". This will help you to work out who else could help you.
Finally, I will echo #sjt. Don't commit Scrum suicide. However, if it's something you really want and your company aren't doing it in the right way, don't be afraid to look elsewhere. Learn some of the fundamentals, practice TDD on your own and find a new job.
Whatever you do, good luck! The first step to change is desire.
If you don't have buy in from your other developers its not going to work. Period.
Scrum requires a heap of discipline, especially during the early adoption phase.
I wouldn't be bothered that management don't care for it. If you're free to do the work of developing the software, and all they care about is results, then it shouldn't matter if you happen to have a 10 minute stand up each morning, and plan small chunks of the work into manageable bits, as long as you're hitting the targets they want you to hit.
If you're team isn't on board though, you're going to have a really hard time getting it working, and it will probably fail and cause more impact that not having tried at all.
If you can try to start it in a small project, with a few developers who are on board with the idea, then you can report back to the rest of your development team on how you found it works, what were the benefits and what were the negatives (reflecting is after all an important part of Scrum).
If you want to get your management on board, you might find that after doing a few projects this way you're much better at estimating the time it will take to develop the requirements you've been given by the PMs, hopefully being able to hit deadlines with more accuracy.
Remember, the PMs and BAs can still work in their normal way, once they've handed requirements to you, you're able to build them using Scrum. Its not ideal, but short of having the buy in of everyone, and the ability to speak directly to users and get them to help write user stories, it will be the best you've got.
When asked to estimate the time it will take to complete the project you can apply Scrum techniques. You can break the specifications down into smaller chunks, group them into sprints and develop them accordingly, hopefully yielding better results.
"I act as another SM, I want to change the current status"
Well, that's a good start right there, wanting to change the situation. Although I must say that without the management buy in, it will be tough. Try and arrange an experienced Scrum Speaker or Agile Coach come and do a presentation or workshop at your company which involves all the upper management. Once you have the management believing in Scrum, it will be all downhill from there.
"Team Leader act as a Scrum master, he controls all the things is our team"
This goes against the Self Organized and Self empowering Teams principle in Scrum. A good Scrum Master would empower the Team in a disciplined fashion within the Scrum Rules, to that appropriate level that, the Team should be able to run on it's own. One suggestion is that the Team Leads need to have a different mindset when working as a SM and different one while working as a Senior Developer, there are no Team Leads in a Scrum Team, only Scrum Team members. You cannot assign true leadership, that is a mutual role which can be earned by creating a reputation of helping others and mentoring others. Have them spit time between SM and development duties 30%, 70% or 50-50 or whatever you find appropriate. Command and control could be counter productive for the Team.
Our managers and team member are accustomed to the traditional management type, they do not care Scrum
A Scrum Trainer had told once told me, "Do not commit Scrum Suicide". If your managers do not care about Scrum, don't get fired trying to convince them. Whatever methodology you guys might follow or "not" follow, you have to realise that all this is a business. Your pay check is dependent on your boss's approval, if your boss or manager does not care about Scrum, then don;t do it. If they care about waterfall, Switch to it, do it like you care, but don't do Scrum halfway and call it scrum.
What has worked for me in the past is to identify and communicate pain-points. Certainly, you should never do something because Kent Beck told you to, especially something that will just get you fired. However, some smart people worked at figuring out a set of practices which is cohesive, and divergence from these practices almost always leads to pain points.
As just one example: if you do Scrum where you have a requirements iteration, a design iteration, an implementation iteration, and a testing iteration, this in theory could work but in practice never does. (When it does, it ends up being Waterfall, and the "iteration" notion becomes meaningless.) Pointing out to your boss that you learned something about the requirements while QA was testing might help him realize there's value in getting QA involved in requirements. Or finding risks in the software design by doing a small prototype may help to show why it might help to collapse the design iteration.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I would prefer if those who answer this question state whether or not they have experience developing in an Agile Environment or if they are speaking from a theoretical standpoint.
Backstory:
Let's say there is an opportunistic company that develops technologically innovative products (multi-touch interfaces, speech recognition devices, etc, etc) all of which are fundamentally unrelated. However, as one may see, the key advantage of working on products like these are that libraries can be created / extracted from the product and sold to other companies, developers, etc. Thus, working in an incremental fashion is advantageous as it allows the milestones to be separated from the final product.
Question1 : Is this advantageous from a business standpoint? Have any of you encountered the separating of libraries into individual products within your company?
Question2 : If products are indeed created in such an incremental manner, does Scrum seem like a valid methodology to apply?
Let's assume that this incremental process of creating components to piece together into a final application is set in place. The development team is initially very small, 6 or 7 people. For the fun of it, let's call this team a Guild. The company is just starting out, and they need to make something profitable. For argument's sake, let's say the Guild developed the FaceAPI Library. All of this was done within the Scrum methodology, let's say in one sprint. Now, the company has enough funding to employ 7 more people. These new 7 people are put into their own Guild, and their skills mirror the skills of the original Guild.
So now, this company has 2 Guilds, and 1 library off which to develop. Let's say that the one Guild is tasked with creating Product1 using the original library, and the other Guild is tasked with extending the library with more features. These two "sprints" would be carried out concurrently, and at the end the updated library would be merged into the application. As you can see, it is possible that some modifications might need to be made to the library by the team working on Product1, in which case the merge will be non-trivial.
In any case, this is the general idea. The company would have individual Guilds, or teams of people (Question 3: What do you think of this idea? Since teams are smaller, they would want to hire members that have good synergy. Is this likely to increase overall morale and productivity?), which would carry out sprints concurrently. Because of the nature of the service the company offers, the teams would work with more or less the same components, and parts of the applications, however their sprints could be created so that the teams could always carry out work without impediments. Each Guild would be a self-enclosed unit, having testers, designers, and QA's.
Final Questions:
As developers or testers, what are
your opinions on a company that
functions in this manner? Does it
foster leadership skills in
developers? Does it sound appealing?
Does it sound destined to fail?
Anyone with knowledge or experience
with Scrum, does it seem to apply
naturally in this kind of
environment?
Has anyone worked for
a company that functions similarly to
the above description? If you don't
mind answering, what was it called?
Was it successful?
To start with, I have been working on 3 more or less Scrum projects so far.
There are a couple of unclear things in your story. What is the company aiming for - developing libraries or final products? To me the two seems fairly conflicting, especially for a small company.
Another thing is, starting development with a library itself without any real users doesn't sound very agile to me. IMO an agile setup would start the other way around: develop a concrete product first, refactoring the design as dictated by the concrete situation, to possibly arrive to some sort of layered architecture, in which the lower layer(s) could be extracted into a reusable library. Then start developing more concrete products, looking for possibilities to reuse code between the projects, and evolving the design of the common library - again, as dictated by the concrete usage and needs of its clients (the product development teams).
At some point, library development would probably require its own team - in the beginning, it might suffice to have its design and its backlog coordinated between the different teams.
Regarding your question about teams treading on each other's code - this is what source control is for. Fork for the new stuff, then in the next sprint reintegrate and stabilise.
Regarding q2, scrum is an incremental approach so if the design lends itself to incremental segments of work then of course it's appropriate.
Regarding q3, how could it ever be a bad thing to hire "people that would work well within them and that they would want to work with"?
Team organization and system structure are highly dependent. See Conway's Law
This means that for you to have two separate teams working on two separate code modules (the Library team and the product team) you will need to have a clearly defined communication channel between the teams and thus, the code developed will reflect those channels in the design. Traditionally what this means is you end up defining an API or interface for the library which acts like a contract to which each team can develop. Agile practices normally adopt a more emergent design philosophy so it can be difficult to create an API that makes sense.
The way most agile teams get around this is by time boxing development to manageable increments. So while it might be unrealistic to design the entire API, the product team and library team could probably agree on an API design enough for 2 weeks of work. Write the code, deploy, design for the next iteration, and repeat. This way communication paths between the teams and code modules are established so the two teams can work independently without stepping on one another's toes.
Another option I've seen used recently is to have larger teams managed with a Kanban/Limited WIP process. Having everyone on the same team managed by a Kanban allows for more organic and flexible self-organization which means your system will be able to evolve more easily. By keeping work-in-progress highly visible it increases communication and by limiting work-in-progress you constrain developers from clobbering each other by keeping the system from evolving too far in any one direction. Combined with a solid VCS you should be good to go.
Finally, another option is that you take some time to really think about your architecture before diving into development. Using a software architecture design process such as the Architecture Centric Design Methodology (ACDM) in a limited "spike 0" kind of role could help you resolve many of the issues commonly encountered when allowing emergent design. By the end of the design sprint, you'll be able to lay out a plan that makes much more sense for what you need to do. And remember, just because it's a design phase doesn't mean you don't write code - quite the opposite. ACDM advocates strongly for experimentation.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
What are the reporting lines when using SCRUM methodology as compared to a "tranditional" matrix organisation where developers report to development managers, project managers and any other stakeholder at the time?
The point of Agile is to eliminate all the "reporting lines" and pare things down to the essential relationships and nothing more.
Scrum teams are intended to be self-organizing, not have organization imposed on them.
I don’t believe it is the intention of Scrum to define any reporting lines whatsoever, at least not in the formal context. It’s a software development methodology, not an organisational structure approach. Although I often play the role of a Scrum Master and my direct reports do the development, we could conceivably operate with one of the other guys playing the lead role and myself being a developer without it being contrary to the formal construct. Of course this could be interesting in the event of a dispute but for the most part I think Scrum and reporting lines are two independent concepts.
The reporting lines within a Scrum project are dependent on the situation. At a high level the reporting lines for the project might look like this . . .
Team member => Team => Product Owner => Customers/Sponsors.
The team members are accountable to each other, and as such at the very least use the daily standup to bring their team mates up to speed with any issues and problems. Between them they will decide on course corrections, or a plan of action to fix the issue. The ScrumMaster is part of the team, and may decide to take on tasks to facilitate the removal of any impediments that the team runs into, but that does not mean that the team reports to the ScrumMaster.
The team also makes a commitment to the Product Owner (PO) when they agree on the goal and deliverable for the sprints. As such they will allow the PO to provide leadership for the project and let them (the PO) resolve any issues with respect to the clarification, scope of features.
The PO was the original champion for the project and managed to get funding and buy-in from customers and sponsors. As such the PO needs to keep those stakeholders appraised of the projects progress against the plan for delivery and success. The PO needs to ensure that the stakeholders remain satisfied and in the case that something unforseen occurs, confirm that the new plan still meets with the stakeholders buy-in.
My final note is that managers and project managers are still involved, though more indirectly to help the team remove and solve their impediments that are inhibitors to their success.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Yesterday I had a team leader of another team say that they took a while to figure out something I wrote on a wiki page because I referred to obtaining code from source control as "checking out" which apparently confused them. They said that they were use to Clear Case and had only heard of the term "joining a project" and said that they haven't really programmed much for a long time.
While this is fine, what it then made me think of is the different types of team leaders I've had over the years. I've had some that have been almost purely managerial and I've had those that are programmers that do managerial things at the same time.
Do people have a preference as to what kind of team leader they have? How do you care if your team lead is active in the development of your product? I find team leaders who actually sit and code like the rest of the team more likely to understand things like (from my experience):
things aren't always as simple as they sound. Team leaders I've had who don't code or rarely code at all believe everything is a piece of cake and shouldn't take much time at all (which perhaps might be the case if you want to hack it together)
they are more understanding that developers don't always like sitting in long meetings and do their best to avoid getting their team into as many pointless meetings as possible
they understand what you say from a technical point of view. Those that might not have coded for a while might not be up to speed with a lot of the new technologies, techniques or lingo
I find it much more satisfying to have a team leader who has the mind of a developer and likes to get their hands dirty in the code as well. Perhaps there are some people out there that like team leads who distance themselves from the actual coding side of things and simply doles out the work, or perhaps another type of team leader that I haven't mentioned?
A team leader has to be a coder -- they can't lead the team unless the team respects them and where they're taking everyone.
A team manager, on the other hand, can either be a coder or someone who is just well organised and knows when to ask questions and interface to other management.
It is possible to find both a manager and a leader in the same person, but more often the roles (should be) separate and distinct.
You should read the book Managing Humans. I am of the opinion managers should keep their hands out of the code. They have more important responsibilities like keeping people away from developers, so they can do their job. Having them jump into development creates confusion as they aren't in it enough to know what's going on and have their time divided between that and other things, so it is difficult to count on them for major pieces of functionality. Plus, it really sucks when you have to tell your manager that something they just wrote needs to be changed, and you have to go back and redo it. Managers are really their to jump on the grenades for the rest of the team, so they can focus on accomplishing the task at hand.
That being said, should manager's know about software engineering? Yes of course they should, that's the field they are in. Should be know how to code in the latest and greatest whiz bang technology? That shouldn't really matter as long as they get how software development works.
I have no preference, I can't, I have to work with all of them, even though too many cooks spoil the broth. On a multi-developer typical project I have a technical lead, project manager and a non-technical customer. Of course, divisional and programme management will each stick their head in.
There are a number of types of leader, each have their own traits:
Non-technical customer: "The customer is always right." Often wants a moon-on-a-stick. Will call both the management and the technical bods and take the best answer as gospel.
Team manager/line manager: Somewhat pastoral role. Not particularly interested in the project I'm working on right now. Steps in when there is a decision to be made between project priorities. Probably really wants to be a coder, and delegates all the rest of his work that he can to his subordinates.
Project manager: Varying degrees of technical know-how. Is concerned only with timescales and costs. Does not understand, "I don't know how long its going to take, I need to play with it for a couple of days first to get a feel."
Team leader/technical lead: Just another developer, but with more experience. Responsible for technical decision making that will affect the whole project. Often fighting with the project manager to carry out good engineering practice, even though it will take longer in the short term.
Team leader/glorified secretary: Someone who is supposed to lead the team, but acts as more of a secretary. (Usually a grade above the team). Answers the phones, insulates customers from the technical bods. This works fine until they ask a technical question, where the glorified secretary tries to blag his/her way out of it, and eventually they work around the secretary and talk direct to the team.
We typically have a PM (non technical) who manages the project from an admin. viewpoint and a Tech Lead who manages the technical aspects and provides technical leadership to the team.
The Tech Lead will code parts of the project and will probably be the main (only) developer for the "Proof of Concept" stage.
On some smaller projects, they are the same person but it's a rare combination.
The absolute worst Software Leads/Chief Software Engineers that I've worked with were the ones that wanted to be intimately involved in the technical details. Too many important tasks were either missed or just not done. Managing a team is a full-time job. If the lead wants to get involved in the technical aspects it will certainly come at the expense of the managerial aspects.
I’ve only had 2 Software Leads/Chief Software Engineers out of dozens that I thought were worthwhile. While both were previously software engineers, those days were long gone for both of them. They knew it. They didn’t even try to pretend. Their job was now to manage. Their job was to make sure the developers had every chance to succeed. They did their best to remove all obstacles and make sure everyone was making progress.
I have a theory, but have never seen it in action, that the best software lead would be someone who is not, nor ever has been a software developer. They specialize in the true spirit of management, specifically that of being a facilitator. Unfortunately, most managers are more politically motivated or are just in the job because they've reached their pinnacle technically.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
To quote wikipedia:
Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as they are self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules."
Working on this basis, and the fact that most businesses are running 2-3 projects at a time, what actual work tasks does a SM do to fill a full time job? Or, is it not a full time job and that individual do other things such as development, sales etc?
Do any SM's out there have anything to share?
Unfortunately we don't have the luxury of having dedicated scrum masters. I am also a team leader and senior developer which more than fills the day.
I typically am on Stack Overflow all day. Oh, and I try to co-ordinate lunches.
The key to the ScrumMaster role is to remove impediments.
The ScrumMaster/ Iteration Manager
Builds the Release Plan
Builds the Scrum/ Iteration Plan
Plans and hosts the
Scrum/ Iteration Planning Meetings
Show & Tells
Release Planning Meetings
Retrospectives
Owns the blocker board and actively works with the team to identify and remove blockers
Updates the team WIKI
Updates Big Visible Charts in the team room including the story card wall
Participates in the daily standup
Participates in the daily Scrum of Scrums
The ScrumMaster/ Iteration Manager is also the sheep dog, that is they protect the team (herd). Finally, the ScrumMaster/ Iteration Manager is the point of contact for the team to external resources but primarily the Project Manager.
"acts as a buffer between the team and any distracting influences"
That is a full time job. There are a bunch of people who would love to get information from the team and it is the SM to handle those questions. To do that job well, it is important to be proactive, not reactive. Therefore they should be keeping all the wheels running smoothly. It is an amazing transformation when the SM is working well.
I think there will be as many answers to this question as there are people to answer it. On a small team with dedicated people who mostly know what they doing, the role of SM is almost invisible; on a larger team trying to cope with vague requirements and power struggles the SM will be highly visible and probably never have a moment to themselves, as they will become the lightning conductor for all the frustrations of the team (and stakeholders outside it).
There's no substitute for knowing what you want to achieve and having a small team of people who know how to achieve it. If you have that, and you "adopt SCRUM", you will probably be convinced quickly that being a Scrum Master is easy. But if instead you have a big mess of a team, and an undefined goal, and a lot of political fighting going on, and you "adopt SCRUM", you will probably come away thinking that being a Scrum Master is a full-time (perhaps impossible) job requiring a combination of very rare talents. Most real teams are probably somewhere between these extremes.
Please note: this question and answer is over twelve years old. The consensus understanding of the role of scrum master has moved on massively since then and so I no longer view this as a valid answer to the question, let alone one worthy of being the accepted answer. By all means downvote it. Beyond that, pay it no heed.
The Scrum Master will do things like ensuring scrums occur, organising sprint planning meetings, retrospectives etc. Also (s)he will be able to explain to management what the team is doing and why the team members cannot be poached off onto other projects until the sprint finishes. Beyond that, there aren't really any defined tasks for the Scrum Master. So one person should easily be able to be Scrum Master for 3 teams, and still have time left over to either do management type jobs (holiday requests, procedures, attending boring meetings with directors or whatever), or be free to contribute to the development resources of the team.
While ScrumMaster is a role within the Scrum framework, the individual fulfilling that role must be a member of the Team. In Scrum, Team members should at all costs be full time. Team members should be able to pick up tasks on the Sprint backlog. They might be development tasks, testing tasks, configuring the CI server tasks, etc... If you can't contribute to the burndown then why be on the team? Buggering off and joining another team is the last thing any self respecting ScrumMaster should do. ScrumMasters should be servant leaders that are embedded with and dedicated to their Team and product. ScrumMaster is a role on a Team, not a job title. I disagree with those that think you can be a ScrumMaster on more than one project at a time and still be world class. The fact is, that's just not Scrum.
First and foremost: remove impediments.
It is best if a Scrum Master is dedicated to one team, so that impediments are removed as soon as possible. Some of this can be done proactively, for example by pushing the PO to analyze certain stories better for the next Sprint.
If there is extra time available it is convenient if the SM has some skills that can make him function as a developer or tester on the team. I've seen good result with SM's that delegate as much as possible to a (classical) project manager and focus on development most of their time.
To make a long story short, the Scrum Master is responsible for making things happen. And in practice it is often the case that the Scrum Master is actually a project manager in disguise. At least that's the case in my company.
Working on this basis, and the fact
that most businesses are running 2-3
projects at a time, what actual work
tasks does a SM do to fill a full time
job?
Anything within their skillset to help the Team achieve the goal.
Or, is it not a full time job and
that individual do other things such
as development, sales etc?
ScrumMaster was not originally intended to be a full time job. ScrumMaster is a role fulfilled by someone on the Team. That team member is dedicated to the product full time. So, when he\she is not doing ScrumMaster duties they default back to burning down tasks on the Sprint Backlog.
Everything and anything that developers need to keep being productive. Order pizza. Go talk to admins, management, other teams. Do bureaucracy kind of stuff. Fix the build server if no one else's available.
The key word here is that a Scrum Master's role is a facilitator's role. And as someone rightly mentioned up there his most important job is to ensure seamless distraction free environment for his team, which means removing impediments, making sure his team has whatever they need at all times. Scrum master is a link between the Product team and the Development team. The decision making is done by the TEAM and not Scrum master.
It is bad idea to share one Scrum Master between multiple teams as requirement of one team may be an impediment for the other team and hence defies the whole purpose of a Scrum Master.
Also it is very dangerous to have your Manager as your Scrum master as the pressure of delivery on the manager may force him to micro manage which is a killer for any scrum team.
Other than the regular stuff which is
Arrange Sprint planning and retrospectives
Facilitate daily standups Arrange
Demo's at the end of sprint iteration
Address team's concerns mentioned at the standups
A few important things that a Scrum Master has to manage on a day to day basis is
Foresee and remove any distractions for the team before even it hits the team.
Encourage team to communicate more
Maintain constant communication with product team to check what needs to be done in
preparation for future sprints
Make sure the team follows the processes they have collectively agreed upon as sometimes
during sprint busyness some processes slip through the crack
Constantly find ways on how to improve the processes followed by the team
Most importantly a Scrum Master has to standby and support his team.
All this work takes up a lot of time and does require a dedicated Scrum Master who performs no other role.
Scrum Master is like the mother bear for the team. They look after the team's health (project wise), protect them from pesky outsiders and remove any obstacles for the team. I play ScrumMaster for my team but I am also a development lead (for the same team!) who takes part in technical discussions, design discussions, coordinating between the developers and QA on our team(if they arent already doing it themselves). I do try and take on actual development tasks to burn the chart down when time is available.
Isnt it extremely distracting for the ScrumMaster to play that role in multiple teams. God I would find that confusing. Which impediment is blocking which team again?? Wait who was working on this task??
A Scrum Master role implemented correctly, is invaluable to the Project and should not be look upon as a Part time role. The most important aspect of the role is to act as an obstacle remover for any queries raised in the Scrum meetings by the Development Teams. A Technical Scrum Master (which is what most SMs tend to be) should not be a Developer on the team, but should be able to advise on design and solutions (an extension to pair programming if you will).
They are responsible for updating the ProductBackLog (stories should be created by the business), SprintBackLog and BurnLog and for liasing with the business and IT Management on progress. They also manage a SpikeLog for any items that require investigation that may evolve into Stories (again driven by the business).
As drivendevelopment implies, the ScrumMaster is a full team member and thus should be full time. I generally treat my role as "ensuring the team functions as a well oiled machine", which can have a number of meanings at different times. Frequently, a SM spends a lot of time facilitating the team's interactions with people outside the team, especially those related to business analysis and stakeholder expectations. Beyond that, it is a matter of meeting the mechanical items listed by Cam and looking after the physical and emotional state of the team.
Related to one of the earlier answers, one of the fundamental aspects I insist on is that no member of the team is a direct report to me, nor to each other. This precludes things like vacation time, expenses, etc from being part of my job, but goes a long way towards not cluttering the trust relationship that must exist.
As generally understood priority # 1 on scrum-master list is to remove impediments as reported by team. But this should not stop here, he should constantly look out for potential impediments.. and more importantly impediments that are there but not yet identified. Ken said Impediments are opportunities. So scrum-master should avail these opportunities all day along to bring his team(s) to hyper productivity.
Ultimately purpose of scrum is to bring success to projects. Purpose of having a scrum-master is to ensure that scrum succeed in fulfilling purpose of scrum. Now to to fulfill purpose of scrum-master, he/she must think & act at strategic level as well. This is full-time job.