You’re making a number of mistakes here.

The first one is assuming that a Scrum Master is a manager. They’re not. They’re basically an administrator-cum-facilitator. They make sure things happen on the Scrum schedule, but they don’t have to tell you how to, if you’re a fully-mature Agile team. It mostly just happens.

But they don’t monitor the quality of your work or sign your holidays off or anything like that. Nor do they manage the product or project; that’s done by other people.

The bigger mistake you’re making is assuming that you can go from the situation you’ve described in other questions (“Developers are far from capable of doing agile programming practices at the moment. No unit tests, no pair programmings, no CI (huh? what is it?) … you get the idea.”) to “fully-mature Agile team” overnight. That’s simply not possible. Forget it. Don’t even try.

If overnight results is what you want, look to more structured project-management approaches. And hire some managers.

If the business wants you to be Agile, it takes time, it takes culture change. And yes, at first, when you’re in the Chaotic Stage of improvement, it’s going to require management. Whether that be an individual or a group, someone’s going to have to make some decisions.

You need a person or group to be responsible for taking a look at the bigger picture, explaining the current situation to both the developers and the business, and explaining the options you have for improvement, figuring out what the business needs and then guiding people through it.

It’s going to be a long time before you can call yourselves a fully-mature Agile team and self-manage. Most teams never get there.

In my understanding a mature team is fully self-managing.

Let’s assume for a moment you’re correct. I don’t know one way or another, so let’s not discuss it.

The issue comes that even a self-managing team ends up with someone with good social and political skills that can represent the team to other departments. Someone who keeps track of what everyone is doing, when they’re taking vacation, etc. Someone who handles HR bullshit and budgeting. Someone who argues with the QA and PM groups so that the rest of the team doesn’t have to. Someone who mediates the inevitable interpersonal squabbles between developers. Someone to schedule meetings and keep morale up.

This person is a manager.

• You arrive home one day and you pay check does not…
• You want to take leave, but the team is too busy and has been for a year…
• Your wife or child is sick and needs you to cut back to 20 hours a week
  for 6 months.
• The finance department has called for a budget cut and someone has to go.
• The coffee machine broke and no-one can fix it.
• Your team is so good there are no defects to fix and no features to add, you have run out of work – what to do now.
• The customer won’t pay for work done
• The customer wants more work done than you can achieve and is prepared to pay for
  it.

I don’t see anything in this list that has not happened to me in my career. I don’t see anything in this list that needs highly technical skills resolve. I see lots of stuff in this list that needs specific skills that, frankly, most developers do not have, and good managers do, no matter what they have managed in the past.

Stop bagging managers – recognize you have a set of skills and they have a different set. All of these skills are needed in any organization. You will do their job just as well as they will do yours. It is rare to have someone good at both jobs, it is rarer to have someone good at both that can do both simultaneously. What happens without a manger is things slowly erode into a state of disfunction. If you are lucky, its recognized early enough, a manager is hired, and all of a sudden problems disappear as if by magic, and you are left to get on with the job you are paid for rather than playing silly office politics (speaking from experience here).

I see management as a total waste of time and a by-product of immaturity.

Wow. You haven’t worked with any good managers lately, have you? (We’ve all worked with bad ones).

I have seen people occasionally make the mistake of assuming anything they don’t fully understand is easy.

(Business folk are especially guilty of this – have you ever received poor quality specifications AND a deadline set in stone?)

In most businesses the development team exists as a part of a larger whole. Managers exist as an interface between the team and the rest of the company. A good manager will work that relationship in both directions, ensuring the team gets what they need (requirements, office space, new computers, recognition, bonuses, etc) as well as communicating the (ever changing) priorities that come out of the corner office.

The corner office exists for a lot of reasons, most of which aren’t relevant to this post.

Remember that most managers are making the best decisions they can with the information available to them which may not be the same as the information available to you.

If you had a fully mature development team that was part of a fully mature company that had fully mature customers and nothing ever changed, you might possibly eliminate the need for most management. The term for that is Utopia.

Good luck with that.

ps – read Don’t call yourself a programmer – excellent advice, and explains better than I how the rest of the business world views us.

The job of a scrum master or a manager in general isn’t to act as a dictatorial overlord. A manager’s job is to make sure that his team is set up for success within the business. That includes hiring the right people, getting the right equipment, and keeping a strategic view of the product. A manager should be like a linesman, keeping the details and minutiae that aren’t important to a teams success from interfering with their progress.

Part of the problem is that “Scrum Master” is quite possibly the least-accurately titled role in all of history. “Scrum Facilitator” would be slightly more accurate, but as someone else pointed out earlier, the SM job isn’t to manage the team but to make problems go away so the (self-managing) team can get on with their jobs. Yes, the scrum master is also responsible for making sure that scrum happens: tasks get updated with remaining hours, stand-ups are held and add value, burn-downs are updated and velocity is tracked and so on, but that’s still a coaching and facilitating role, not a managing role.

Another part of the problem is that the folks in the corner offices want to know the answers to questions like “when can I ship the software?” and “what features will it contain?” and they’re used to being able to ask a “Project Manager” those questions and get answers supported with lots of impressive-looking Gantt charts and little or no mention of uncomfortable things like the cone of uncertainty.

Under Scrum, it’s feasible to start with a rough-and-ready list of the “will”, “might” and “won’t” features for any given ship date, but there’s definitely a role for someone – probably the scrum master – in keeping the corner office up to date with the inevitable changes in those lists over time. I’m tempted to think of that activity, along with processing the resulting feedback and managing new feature requests as “management”, albeit management that’s different from what many, many Project Managers might have done in the past.

If you think no management is needed, who will perform the following organizational jobs, who will respond in the following situations?

• new clients must be found. How do you sell your products? How do you advertise?
• materials must be purchased, suppliers must be found
• diplomatic discussions with other companies, or banks, or a government office must be led

I’m on a small team with no manager and it works. Why? I honestly don’t know.

My best guess is it comes down to the type of person you are. Some people “are” computers, so they need to be fed a process. Other people are “programmers” and have the ability to create their own world and structure from nothing.

I must create a system or be enslaved by another mans; I will not reason and compare: my business is to create. –William Blake

EDIT in response to glenatron’s comment:
It’s more than just a dev team. We have a CEO, a receptionist who answers the phone, and an IT guy. We communicate with clients directly by email, phone, or meetings. Our main business is creating our own product and selling it, rather than hunting down contracts. But there are contracts too.

I’ve thought about it more and these are the reasons I think it works:
1. We primarily create our own product rather than creating someone else’s.
2. We have a consistent work ethic independently without oversight.
3. We have domain knowledge.
4. Luck. A handful of people who get along and work well together.

Someone mentioned the company Valve has no management either. Valve creates their own product rather than creating someone else’s. I think a product company lends itself better to self-management. There’s no risk of going down a different path than the client expects because you are the client. In a game company this is especially true. Make your game fun.

You can’t manage your way to fun. You can’t manage your way to the original creation of art.