After all, to be a level II SCRUM master, you don't even have to know how to program

You will have, if you use Scrum, someone on each team whose name is, it's called the ScrumMaster, also known as "The Prick". And this person's job is to make sure that you don't cut quality. D'oh. And they have no authority but they, what they can do is if we've defined that an increment has a certain level of quality for it to be demonstrated to our product management, their job is to make sure that quality's there. And if the quality isn't, not to let you demonstrate it, but instead to say to the product manager, "Hmph, we lost our heads, we're not done, it's gonna take us another month to finish this".

This person is probably the least loved person in the world because they stand right at the nexus between product management believing that any amount of stuff can be done and our willingness to help them cut quality to support that belief.

The burnout rate on these people is usually, like, 13 to 14 months. Throw 'em away. We often get them from hopeless, professional areas like QA. People in QA are used to doing incredible things with no authority, no respect, and no hope of success, so that's where we take these people.

-- Ken Schwaber, Google tech talk on Scrum, Sep 5, 2006 (46:34)

The Scrum Master role reminds me of the Political commissar, commonly attached to military units during WWII. The political commissar role was not created to do any actual fighting, rather to teach ideology and exercise social and political control over the soldiers, to guard against anti-revolutionary thought and action.

On the subject of non-programmers making big bucks in the software industry, I'm reminded of this little piece from Joel Spolsky:

The whole fraud is only possible because performance metrics in knowledge organizations are completely trivial to game. The best part is that most management consultants, the stunningly good-looking, bright, earnest chipmunks with 4.0s in Russian Lit from Harvard who work for these companies, have absolutely no way of knowing this, so they can go through this whole exercise without even knowing that they're doing it! They get all the way through the 2-year associate program on their way to MBA school without even realizing that they haven't done a goddamn thing about productivity, all they've done is caused a fairly pointless transfer of wealth from ExxonMobilConoco to BainMcKinseyGartner's senior partners. And it's a lot of fun! First class flights to Houston and Oslo! Helping the world be more productive! Rock on, young stunningly-good-looking Management Consultant.

It suddenly occurred to me as I read this where a good portion of my discomfort with these methodologies comes from: The Military and my upbringing. Not that the two were all that similar in any other way than both consisted of consistent roles with well defined expectations and a consistent language describing and defining those roles and expectations.

There are, to my way of thinking, some very good functional reasons for the rigidity of those role descriptions and definitions. The main one is that everyone knows their basic functions. They are simple:

• Functional Skill Set - ex. Grunt, programmer, eldest sibling.

  In the service, everyone was a Grunt first. You had to know how to kill(shoot, toss things that go boom, set up stationary things that go boom when the other team was properly aligned as a target, avoid the other teams things that go boom, keep oneself reasonably serviceable in nasty environments, etc...) Everyone had the same basic skills and there were metrics, and if you didn't measure up, you were out(which is a big favor to everyone including the ousted; better ousted than dead).

  An individual on a development team should have the basic skills to program 'something'. Otherwise, they should not be on a development team. The basic metric is you can write some sort of functional code or you can't. If you can't, what the hell are you doing in software development?

  In the family, the eldest helps build the basic skill sets of the younger and protects them from ignorance. Up until their own ignorance/stupidity(in my case) gets in the way of that, which is when mom/dad step in and make sure the problem isn't being handed down the line. Some pretty simple metrics their too, though I am sure it varies from family to family.

• Role - While the basic skill sets are common and expected, the role one plays on the team may vary.

  In the service it is rank and rank type(Officer/Enlisted). The skill sets may differ(supply vs motor transport), but even so, those support roles are still aimed at the basic skill sets which enable the core mission.

  In a development team, there may be a SCRUM master or a technical lead or a developer. Each has a role which is aimed at the basic mission which is writing serviceable software.

  In the family, well... I won't go there, as the roles in many families vary in many ways and often interchange, which is really cool. Never-the-less, the functioning families I have encountered have designated roles, and each knows what their current role is. Each role maintains the members of the family as well as the family unit itself.

• Mission - Everyone knows the mission, their role in it, and how the basic skill sets apply, which roles are direct and which are in support. I will leave this point alone...

The bothersome thing with all these methodologies is that they keep changing things up. What they all really boil down to (at least in my neolithic mind) are a constant re-shuffling of the basics above. That continual shuffling around undermines the basis of how I function. I need to have a clear understanding of what my role is and what the role of those around me is. I expect to be expected to understand and contribute at some level in the basic skill sets regardless of my role. I think part of the reason that this article hits the nail squarely on the head ( Joel Spolsky ) is that it becomes easy to 'game' a system when the system is in constant flux. When it comes to metrics in a changing system, about the only measurable thing is the change itself. Thus, the metrics become frustrating because the standard keeps changing, or at least the way it is talked about and understood.

Every role needs to be based on the functional skill sets which get the job done. It may be organizational, or technical - manager or architect for example. That role is still based on applying the skill sets to the task at hand. I question whether one can do that without having a functional understanding of those functional skill sets. And that is another part of the reasons those hucksters sell what they do, the way they do... everyone wants the newest paddle for the canoe and they are so busy looking at paddles, they don't see the canoe drifting away...

Ok. Enough... I will stop. (Past?)Time to get off my high horse... :-)

...the majority is always wrong, and always the last to know about it...

Insanity: Doing the same thing over and over again and expecting different results...

A solution is nothing more than a clearly stated problem...otherwise, the problem is not a problem, it is a facct

wjw

At this point, I’m mostly a “hybrid Business Analyst / Project Manager who has done a helluva lot of coding over the past 30 years.”   Which means that I have sat in that role, and I agree that it is tough.   However, the first thing that I say to a team (when it isn’t remote, as it most commonly is ...), is:   “please, sit down.”   And I take a seat next to my coffee.   The shocked looks are quickly replaced by smiles of relief.

The next thing that I is to very briefly describe my own history, not in flowery terms, and to say, “Therefore, I know what I am doing – and, so do you.”   Raised eyebrows, smiles, “I’m from Missouri” glances.

But this normally isn’t what team members are told:   they’re expected to be “rock stars” and tend to try to act the part ... not because they necessarily want to, but because they assume that all of the pressure, and all of the blame, rests upon their shoulders.   And, bluntly, they expect project failure.   No one ever told them (or, told the owners higher-up) that the project consists of building a software mechanism and that the work must be done in that way if it is to have any hope of success.   They are used to dealing with higher-ups who try to bribe them to do good work and to spank them if they don’t.

I feel for – feel very badly for – the earnest folks who swallow these “methodologies” so willingly and then try to digest it.   Computer software-building is ruthlessly unforgiving of a misinformed approach, and it is much harder than it looks, for reasons that are not initially apparent.   (I guess you’ll have to buy a Kindle, but ... read that book.)

- - - - -

Right after graduating from undergraduate, I worked for the school and therefore had the opportunity to essentially get an MBA for free, from an excellent school.   I declined.   I knew that I knew nothing about business yet, let alone business administration, and that school wasn’t going to teach me that.   At least, not yet.   I never did go back and get one.

After all, to be a level II SCUM master ...