14 comments:

Well said. Scrum is just a different way to manage projects. If you take Scrum's focus on features, short iterations and meetings but ignore engineering disciplines like TDD and refactoring and place all the authority in the hands of a manager its a recipe for failure. You wind up with a taskmaster that ignores quality and rejects developer feedback.

I want to agree with you and I loved the story about poor Dr Royce but frankly this smacks of glass half empty. Scrum needs more people with insight into the scrum process and if certification gets that knowledge into the PM discipline then I consider that a good thing. Clearly we are better off if PMs are familiar with and endorse the scrum process. This will fail if the certification process produces waterfallers but one of the drivers of certification is to assure a level of knowledge about a particular disciplone.

Very interesting input. From a Scrum point of view, elitism could be considered an organizational impediment to the process. And the organizations that are not willing to deal with that impediment might be advised not to even try to adopt Scrum. In practice, of course, they will do so anyway.

I don't know how to deal with this, but I'm sure I will be thinking about it.

Love the essay; especially got a kick out of the PMBOK paragraph because I've noticed that PMs have a harder time with Scrum because of all the trouble they had in achieving PMP. The personality of the individual will shine through. PMs are often used to 'tasking' and Scrum is in conflict with that.

I've always been about enabling the team, even when I was the "boss". I much prefer to be a Scrum Master and concentrate on helping the team become more productive than being their supervisor and tasking their work as an elite (or not).

I believe most companies desire to continually do more in less time, with less people, will ultimately result in a bad Velocity that will result in burn-out and the failing of an Agile/Scrum team/process. Interesting enough this is the same problem as with other project management methodologies where too much work (tasks) are required in too little time.

Allot of good points, personality, features v task, too rigid and over controlling, inability of a ScrumMaster to let go of control.

I enjoyed the Coach ~ ScrumMaster ~ elitism analogy in Mr. Martin's document. (Which Linux and LibreOffice opens just fine, but I did re-save it as an open office document .odt format anyway...but i digress.)

Velocity is the key, is yours sustainable or not? Do you spend time at the end of each cycle looking at the velocity? Is the velocity allowed to be changed? Does your team have the political and institutional ability to push back in order to maintain a viable Velocity?

Based on the article, if elitism is becoming "an organizational impediment" as elitism rises, one way to check for that would be via the velocity. If its un-reasonable or not sustainable, yep, someone is dictating when they should be coaching. Or perhaps the management structure only pays lip service to the Agile/Scrum process for the good will and validation they believe it will bring their company and the company's products.

A typical over-controlling, type A, Disc Profile big "D" type management structure and/or PM is unlikely to allow a reasonable velocity to exist. Its just not in their nature. Never was, never will be.