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.
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)
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||