4 ms·

> First, I see the same sort of dysfunctions driven by The Date™ even when no customer promise is involved. Even when no customers are involved. I believe it,

> First, I see the same sort of dysfunctions driven by The Date™ even when no customer promise is involved. Even when no customers are involved. I believe it, but I've also seen the reverse too. In a situation where no customers are involved, at a non-profit enterprise. When we have a launch date, it helps provide focus on distinguishing what's truly necessary from what's not, and using our development resources responsibly. The launch date needs to be reasonable, and it needs to be understood that it can slip (especially if new requirements show up), but it provided a lot of focus. Having no launch date, sometimes everything but the kitchen sink ends up being thrown in, anything that anyone ever thought was a good idea, and we lose focus on the mission or the end-user, and the project can stretch on forever never being done.

regularfry 5y ago
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!
opportune 5y ago
Good point, I think the problem is not having The Date but as you allude to, having a top-down fearful environment of missing The Date. In an ideal world we would be able to communicate The Same Date all the way up and down with an understanding that personnel issues come up, sometimes estimates aren’t accurate, requirements change, etc. Maybe we expect The Date to only be hit 50% of the time and we’re all chill with slipping a few weeks/months/quarters depending on the size of the project. This allows you to set dates that force you to prioritize (don’t delay shipping forever to add random features) without burning people out or shipping software that’s not ready for prime-time. One problem in large organizations (especially ones that grow fast) is there is no common understanding of what deadlines/targets/The Dates mean. New engineers and management come in from environments where missing The Date is met with unpaid overtime or being fired, getting yelled at, etc. This causes problems when people with the opposite understanding - The Date is flexible and just a loose target - set Dates without padding or fully scoping something, or the opposite when those people become beholden to dates set by people who take them extremely seriously.

regularfry 5y ago

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!

opportune 5y ago

Good point, I think the problem is not having The Date but as you allude to, having a top-down fearful environment of missing The Date. In an ideal world we would be able to communicate The Same Date all the way up and down with an understanding that personnel issues come up, sometimes estimates aren’t accurate, requirements change, etc. Maybe we expect The Date to only be hit 50% of the time and we’re all chill with slipping a few weeks/months/quarters depending on the size of the project. This allows you to set dates that force you to prioritize (don’t delay shipping forever to add random features) without burning people out or shipping software that’s not ready for prime-time. One problem in large organizations (especially ones that grow fast) is there is no common understanding of what deadlines/targets/The Dates mean. New engineers and management come in from environments where missing The Date is met with unpaid overtime or being fired, getting yelled at, etc. This causes problems when people with the opposite understanding - The Date is flexible and just a loose target - set Dates without padding or fully scoping something, or the opposite when those people become beholden to dates set by people who take them extremely seriously.