2 ms·

But this is what (for instance) Scrum and XP should give you. The Date is two weeks from now. What do we intend to ship? Did we do that? Shall we do it agai

But this is what (for instance) Scrum and XP should give you. The Date is two weeks from now. What do we intend to ship? Did we do that? Shall we do it again? We've got another The Date in two weeks. What do we intend to ship? Repeat until everyone gets acquihired and vanishes into the bowels of AmaMetaFlixgle.

wpietri 5y ago
Exactly. Releasing early and often to an ever-widening circle of stakeholders provides the same discipline with much less pathology.
jrochkind1 5y ago
Sure, that's the intent. I trust we don't need to reiterate all the ways it can go wrong, with a management culture that is dysfunctional. (Really, so much of software engineering methodology can be understood as "how do we compensate for dysfunctional management culture, or, at best, what practices can help and support our management to learn to be more functional.") In some cases, especially in the "enterprise", it's literally not possible to have something you can actually deploy in production (not just a proof-of-concept demo) after a single two-week sprint. In some cases, you only get so many chances to get press and public attention for something, and have to decide at what point it's going to be sufficiently impressive to do so. I agree that focusing on getting something live as soon as possible is a good idea, in almost all circumstances. There may be some stakeholders whose idea of "as soon as possible" is not as soon as yours. In some cases stakeholders deciding "shall we do it again" are basically always going to say "yes", until someone says "enough" and sets a date at which it will be cut off -- which then forces management to be really serious about figuring out the most important thing to go in every sprint until then. It is always very important to realize "you can have a fixed date OR a fixed feature/requirements set, not both." In some cases, the focus of a fixed date and "now what's really important to get in there if we can't get everything in" is more useful than a fixed feature set "and let's see how long it takes" stretching on forever with diminishing returns and nobody saying "you know, actually, it would be more valuable to the organization to work on something else now?" In my experience, working in certain kinds of organizations!

wpietri 5y ago

Exactly. Releasing early and often to an ever-widening circle of stakeholders provides the same discipline with much less pathology.

jrochkind1 5y ago

Sure, that's the intent. I trust we don't need to reiterate all the ways it can go wrong, with a management culture that is dysfunctional. (Really, so much of software engineering methodology can be understood as "how do we compensate for dysfunctional management culture, or, at best, what practices can help and support our management to learn to be more functional.") In some cases, especially in the "enterprise", it's literally not possible to have something you can actually deploy in production (not just a proof-of-concept demo) after a single two-week sprint. In some cases, you only get so many chances to get press and public attention for something, and have to decide at what point it's going to be sufficiently impressive to do so. I agree that focusing on getting something live as soon as possible is a good idea, in almost all circumstances. There may be some stakeholders whose idea of "as soon as possible" is not as soon as yours. In some cases stakeholders deciding "shall we do it again" are basically always going to say "yes", until someone says "enough" and sets a date at which it will be cut off -- which then forces management to be really serious about figuring out the most important thing to go in every sprint until then. It is always very important to realize "you can have a fixed date OR a fixed feature/requirements set, not both." In some cases, the focus of a fixed date and "now what's really important to get in there if we can't get everything in" is more useful than a fixed feature set "and let's see how long it takes" stretching on forever with diminishing returns and nobody saying "you know, actually, it would be more valuable to the organization to work on something else now?" In my experience, working in certain kinds of organizations!