Re: Thoughts on the Agile Imposition

[eyepopslikeamosquito]

Don't try to cram in some half-baked code and hope to catch the problem in staging.

Indeed. This should be covered by your Definition of Done. I strongly recommend that your team tape their "Definition of Done" to their Scrum board -- and get buy-in from the Product Owner.

Now comes the tricky bit though. In many organizations, the ScrumMaster and the team come under intense pressure to ship from the stakeholders, the product owner and upper management. Do they buckle and distort the meaning of "Definition of Done" to save face, please the stakeholders, and perhaps even save their jobs? Or do they have the integrity to openly admit that they mis-estimated, hit unforeseen problems, and no, they are not done yet -- and that it is not sustainable and not in the company's best interests to keep accumulating Technical Debt like this. Whether that happens or not in practice depends principally on the personal characteristics of the ScrumMaster in my experience. A clueless ScrumMaster won't even know whether the team is being truthful re Definition of Done.

Scrum co-founder Ken Schwaber highlighted this "ScrumMaster Problem" in a Google tech talk:

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)