Would you say the 2 roles are analagous? Ie the scrum master doesn't fly the planes (code the app) himself, he makes sure that the pilots are flying (coding them) correctly and is responsible for making sure they land (sign off) correctly. He co-ordinates his planes (programmers) so that each is flying in their own airspace and not crashing (ie helping each other out when necessary and getting on with their own work when necessary, so the sprint completes it's commitments). If a programmer needs help, then he'll direct someone else to help them.
+2
A:
Except for the push through his own ideas part.
The Scrum Master is responsible for the process and making sure that the process remains on track. So things like ensuring that no new items are added to the backlog of a Sprint or the team does not get distracted by other things in the organization etc are the areas that a Scrum Master has ownership over.
Otherwise you can probably make the analogy work.
Vincent Ramdhanie
2010-10-21 14:47:35
The scrum master's *only* role is to remove roadblocks. He finds out what is stopping the team getting things done, and deals with it. Certainly, one kind of roadblock is failure to follow a process (both the scrum process and whatever programming process the team has), and his way of dealing with it is to enforce the process. But he is also responsible for making sure infrastructure, external support, requirements, etc, happen, feeding the team the things it needs to get work done.
Tom Anderson
2010-10-21 15:45:23
@Tom: So the only appropriate analogy would be that a Scrum Master is like a cow catcher? http://en.wikipedia.org/wiki/Cow_catcher. I think I know what I'm going to be calling my Scrum Master, once we get one.
Mark Peters
2010-10-21 16:04:27
@Tom It totally depends on what you mean by 'roadblocks'. Many people would have precise definitions and a different understanding for 'roadblocks'. I am assuming you have a fairly vague definition of roadblocks when you say an SMs only role is to remove them.
sjt
2010-10-22 05:04:12
@sjt: you're quite right, my statement rests on a suitable definition of 'roadblock'. I give a very brief outline of what i mean by that word in my comment; i'd describe it as broad rather than vague! I'd like to be able to be unambiguous, though - could you say more about the more precise definitions or different understandings that you think many people would have?
Tom Anderson
2010-10-22 09:22:24
@TomWell the official defintion of an Impediment as per the Scrum Guide is:Anything that prevents a team member from performing work as efficiently as possible is an impediment. Each team member has an opportunity to announce impediments during the daily Scrum meeting. The ScrumMaster is charged with ensuring impediments get resolved. ScrumMasters often arrange sidebar meetings when impediments cannot be resolved on the spot in the daily Scrum meeting.
sjt
2010-10-22 15:14:03
The above definition is intentionally simple, so that SMs and Teams have more room to adapt from it. Below is my explanation of impediments for a realistic world.I think while following the Scrum Framework the Scrummaster may realistically come across 2 defined categories of impediments, Active impediments and Passive impediments. Active impediments would be something which is highly tangible like "The Development Database server being down, and developers not being able to code because of that".
sjt
2010-10-22 15:14:31
Passive impediments would be something that may not be tangible enough but everyone knows it is affecting productivity in some way like a “Team member slacking off or taking too many days off”. In this category there could also be potential impediments i.e. the license of an application server is expiring in 1 month and it would be a roadblock for us in a month but we are okay now.
sjt
2010-10-22 15:15:05
I believe Active impediments should be raised officially as soon as they are known and the passive ones should only be raised if they add value to productivity of the team and don't have an opposite effect or lose its value. Also Realistically a Scrummaster might also face several Active impediments all at once, and may have to adapt to having some sort of light weight priority/criticalitysystem to handle the impediments more efficiently.
sjt
2010-10-22 15:15:31
I consider raising impediments as a Scrum Tool and it should be used wisely. In theory what you say is right, but realistically a lot of adaption may be required to take advantage of this tool. From my experience of being a Scrum Master I have learnt that "Not following the Scrum Process" (Scrum is not a process BTW , it is a framework) can certainly be raised as an impediment but because of its intangibleness , it may not have much value if it is raised officially, they should be resolved on a daily basis. All in all I think I agree with you, I am just giving a realistic definition.
sjt
2010-10-22 15:16:55
A:
That would mean that pilots talk directly to each other when trying to solve a problem. The case is that they talk to the airport stuff (tower, air traffic controller) only.
Otherwise it would mean that programmers only talk to the Scrummaster and do not communicate with each other.
MOnsDaR
2010-10-21 14:51:47
Pilots can and do talk to other pilots even if it's not as common on commercial flights as it is on amateur ones. If you've blown an engine and there's another plane that can take a look, you can get help to assess damage, among other things. It's just a radio.
tadman
2010-10-21 14:55:29
+3
A:
Forget the analogy. Every analogy breaks down, and it takes all of about 10 minutes before somebody makes the mistake of reversing the analogy: using the analog to ascribe new attributes to the subject. Defining the roles and responsibilities of a team member through an analogy is likely to muddy things without delivering any value.
Analogies are usually used to explain things to somebody that doesn't know anything about a certain domain and so can't follow a direct explanation/description. Scrum master isn't a very complicated role to define or even explain (though filling that role can be very difficult). It's not technical. And the people you should be describing it to should know the domain. Forget the analogy, just list the responsibilities and be done with it.
Mark Peters
2010-10-21 14:52:26
Wow...Scrum Masters have very stressful jobs, and they are highly trained for many years! When Scrum Masters make mistakes people die! Scrum Masters work in towers! I think this is an excellent point about analogies. You do have to be very careful when using one.
Vincent Ramdhanie
2010-10-21 15:28:06
Scrum Master is *sold* as a not-a-very-complicated role. That's half the problem. Any role which has to do with getting complex, intelligent, diverse people to collaborate on a single vision through transparent metrics that don't relate directly to the vision itself, in an environment which is frequently hostile both to the vision and to transparency and collaboration, is far, far harder than most CSM courses would have you believe.
Lunivore
2010-10-21 15:55:25
@Lunivore: I'm not trying to say it's an *easy* job. It takes talent and patience, among many other things. But the *roles* you give it aren't complex to *explain* to somebody of pretty much any background, so an analogy has little value.
Mark Peters
2010-10-21 16:03:21
Depends on how you use analogies. If you use them to help people *unlearn* anything they thought they knew about air traffic control in a Scrum environment - well, that can be valuable. I've talked about how I would build houses if they could be unit-tested; how I'd code if computers worked using pixies; how I would control traffic if my planes were Scrum-built software. Most of the time the valuable stuff for me is not in how the analogies are similar to what I'm describing, but in how the new seemingly similar process would change the familiar.
Lunivore
2010-10-21 16:24:58
+1: ATC is highly process-oriented with lots of details and rules. Does that mean the Scrum Master has to maintain all the traffic separation rules, altitude, approach vector, noise level restrictions, etc., etc., etc.? Kudos for making it clear that an analogy isn't always helpful.
S.Lott
2010-10-21 19:55:57
@Mark You said 'I'm not trying to say it's an easy job'. Can you please edit your answer then and add that above statement? Most people who read your answer would perceive it as a SM role is an easy job, irrespective of what you are really trying to imply. Perception is reality. I have seen numerous Companies fail because they under estimate a Scrum Masters roles importance and do not take it seriously and fail terribly, all because they think it is not that complicated.
sjt
2010-10-22 05:15:11
@Mark You also said "the roles you give it aren't complex to explain" Well, that is the beauty of it. Simplicity- one of the Agile principles! The Scrum Role Guidelines and Framework are intentionally meant to be not 'complex' so that the framework and process is lean and more adaptive. But the key here is "Inspect and Adapt". A Scrum Master is no good if he just follows his suggested 'role'. He has to adapt. And that is what makes it a more exciting and challenging job. I am sure other currently ACTIVE and past Scrum Masters would agree with this.
sjt
2010-10-22 05:21:39
@sjt sure I added it, but obviously my answer wasn't trying to make a statement about Scrum Masters but rather about the dangers of relying on analogies. Seems like some people are getting defensive about the SM job, whereas I was only ever trying to say that the SM's purpose is not a hard enough thing to understand to warrant a complex analogy.
Mark Peters
2010-10-22 13:16:53
+1
A:
If I were going to make the analogy between a ScrumMaster and an Air Traffic Controller, this is the kind of controller I'd want.
I want my controller to help us find a way to build our planes quickly, over and over again, because we're going to break them quite a lot. We also need a safe place to which to parachute when this happens in mid-air. He could help by stopping people yelling at us when we crash our planes. It happens, OK?
Occasionally we'll build a plane that doesn't even fly! So the ScrumMaster needs to help us work out how to stay out of the way of the other planes which are actually in flight. We might need a few runways, so the ScrumMaster is going to help us collaborate with other people to get the land.
There are going to be planes landing and taking off fairly regularly - many of them on autopilot (our build tool). So the ScrumMaster should help us manage that by ensuring that we can see any problems with the runway without actually having to go and stand in front of the incoming planes (which would almost certainly crash them).
We're not the pilots. We're building the planes. In fact, hardly any of the planes contain real pilots. We're experimenting a fair bit, so we wouldn't want real pilots on those planes!
However, every couple of weeks we'll get something which works, and then we have a launch in which all our planes get their new features at once, and the real pilots (our users) cheer and drink a lot of champagne because they love their updated aeroplanes so much. And hey, who needs an excuse to drink a lot of champagne?
And those new planes are actually carrying passengers - paying stakeholders; people who really wanted this service in the first place - so if those planes don't land where they were meant to, it had better be damned gentle (or relatively bug-free). And our controller is going to have to help us get another plane out to them really quickly if that happens.
If a ScrumMaster is an Air Traffic Controller, his air field is the biggest playground in the world. No wonder his job is so hard and ours is so much fun.
Lunivore
2010-10-21 15:44:50
A:
I'd suggest the metaphor of a noble sheriff in an old Western: protecting the townsfolk from outside menaces (bandits, rustlers, corrupt officials, etc); keeping an eye on the town's railway, water supply, etc; but also making sure they respect the law and live peacefully with one another. Where he needs to apply corrective influence, he's more likely to do it with a friendly but firm chat than the threat of gaol.
He doesn't have to be a miner or a stockman himself to do any of that, and he's not in a position to offer any advice on mining or cattle-raising, but he's crucial to making sure the miners and stockmen in the town can do their work.
Tom Anderson
2010-10-21 15:51:22
+3
A:
If I find out that there is anything remotely "Agile" about air-traffic control I'll stop flying. Anyone up for some Test-driven flight planning?
DancesWithBamboo
2010-10-21 18:08:37
+1: I don't want to be there for the first few "expected-to-fail" tests of a flight plan.
S.Lott
2010-10-21 19:56:54
+1 Analogy may not be the best way to understand a role deeply. The notes from a Retrospective would be horrific. "What went well?", "We landed successfully", "And What went wrong" " We landed in the water and around 100 people drowned", "And for improvements to this, next time I will aim better for the runway"
sjt
2010-10-22 05:30:04
Agile air traffic control might be a good idea if, like software projects, aeroplanes didn't really know where they were going when they took off.
Tom Anderson
2010-10-22 09:30:40
@Tom It would be a nightmare. The customers (passengers) would keep changing their minds about the destination, and the retrospectives would be horrific.
sjt
2010-10-29 14:29:18
A:
Should a scrum master be like an air traffic controller? Would you say the 2 roles are analagous?
What's important is to find an industry that's a little bit like software development, first, and try to reason from analogy there.
Architecture (creating buildings) or Urban Planning (creating cities) might be closer to software development.
Knowledge Capture (creating an encyclopedia) is pretty close also.
Almost any "service" framework (like air traffic) isn't even close.
Even most conventional engineering (electrical, chemical, etc.) aren't very close because the knowledge domains are smaller and the "invent from scratch" element isn't there.
Remember the golden rule of software.
If it already existed, we'd just download it and use it
That makes software development unlike almost any other discipline. We're always doing one of two things.
Inventing something never before seen anywhere.
Stupidly wasting time reinventing something we could have downloaded.
It's really hard to reason from analogy here. Even urban planners are creating another city. Not inventing new modes of human habitation and commerce.
S.Lott
2010-10-21 20:01:16
A:
The only prominent similarity between a Scrum Master and an Air Traffic controller IMHO is that they are both practically powerless but yet considered highly responsible for the livelihood of the customers. They can only facilitate and suggest guidelines to follow to the pilots, but if the pilot misunderstands and crashes the plane, the Scrum Master will be blamed anyway! It's the sad satirical truth!
sjt
2010-10-22 04:12:54
A:
From the Scrum Guide (Copyrights to Scrum.org - Ken Schwaber and Jeff Sutherland):
ScrumMaster
The ScrumMaster is responsible for ensuring that the Scrum Team adheres to Scrum values, practices, and rules. The ScrumMaster helps the Scrum Team and the organization to adopt Scrum. The ScrumMaster teaches the Scrum Team by coaching and leading it to be more productive and produce higher quality products. The ScrumMaster helps the Scrum Team understand and use self-organization and cross-functionality. The Scrum Master also helps the Scrum Team do its best in an organizational environment that may not yet be optimized for complex product development. [...]
The ScrumMaster could either be the Air Controller in the tower at the airport or one of the pilots within the plane. The Product Owner would be and can only be one and only one passenger, so that instructions for the pilots can only be from the that passenger. What the passenger want, is to arrive at destination, that is the most valuable top Product Backlog item. The plane should, in my opinion, be thought of as the organization. If the plane doesn't come to destination, it will crash, as no other customers will want to do business with it again. The reputation would then be flawed. As the Air Controller at the tower, he might just be another Team member, as he can be an outside resource capable of doing the work the Team alone can't.
In short, the most important role the ScrumMaster has to play in a Scrum Team is to facilitate the communication between the Team and the Product Owner, make sure the Scrum Team plays by the rules of Scrum, and remove impediments so that the Sprint (flight) is delivered sucessful, hopefully.
Will Marcouiller
2010-10-29 01:53:09