I think we have to draw a line between how we present Scrum (and Agile in general) within our community/industry and outside of it. So, as I wrote, you’re 100% right about team getting better being an important product of Scrum but I wouldn’t use it (in most cases) to sell Scrum to a client or a corporate boss.

Thanks for your thoughtful and well-considered comments. A couple of comments in reply.

Firstly, I think we make life difficult for ourselves if we misrepresent the organisational challenges to adopting agile. It’s like the old joke about how many psychotherapists it takes to change a lightbulb* – if your organisation isn’t ready to respond to the pressures for change generated by a well-functioning agile team, you’re storing up problems for your teams and organisation both. I’ve seen the friction generated when an executive decision to adopt (say) Scrum wasn’t followed up with effective action to resolve the issues exposed when agile teams rubbed up against parts of the organisation that weren’t.

Secondly, one of the main points I was trying to make is that the Scrum picture, because of its ubiquity, is how we represent Scrum to _ourselves_. We may “know” and “say” that we value team and individual growth but the picture – when we stick it on our walls, put it in slides, draw it on whiteboards – subliminally reinforces the message that all that’s important is the product. That message changes our expectations and behaviour. Psychologists call this “priming”: it’s a surprising and well-documented effect.

Once again, thanks, for the thoughts. I’ve put a link to this in the comments to the original entry.

(* I really don’t believe you don’t know the answer, but: one, but the lightbulb must really want to change)

We should see difference between pampering and motivating employee. If you mean “motivating” when say “pampering” you are wrong, cause unmotivated team never supply good product, They will work 8 hours per day and no more, when their are not motivated they wouldn’t be productive. When team is motivated they spending more time at work and/or their are more productive.

Off course you have right when you say that frameworks and methodologies themselves not upgrading product quality. But you should remember that their had been invented to help PEOPLE to improve their products quality, to make them work faster and easier. At the end behind all this thing we see people (clients, employers, boss, users etc.) and relations between them are most important.

When you working with scrum or another methodology you need remember that you selling product not methodology as you said, but you also should remember that you selling people to.