4 ms·
Having dealt with US Federal Government customers and multi-year projects, I think the issue is that it gets really hard to provide an accurate cost and time es
by vonmoltke 11y ago
Having dealt with US Federal Government customers and multi-year projects, I think the issue is that it gets really hard to provide an accurate cost and time estimate for the whole project without a BDUF, at least once a project gets beyond a certain size. This is especially true when the project is just a piece of a larger product and needs to coordinate with other subprojects.
It may be that agile is just not appropriate for such projects, in which case I wish companies and customers would stop trying to force-fit them.
- TheCoelacanth 11y agoIt's really hard to provide an accurate cost and time estimate even with a BDUF.
- emodendroket 11y agoTrue enough, but I guess the question is whether agile processes help or hurt.
- mindcrime 11y agoThe difference, as I see it, is this: In a "BDUF" / "not agile" environment, the customer expects a rigorous change control process, and that serves to protect the developers when the customer starts changing things around. In an environment marketed as "agile" it became received wisdom that you don't do "change control" because it "isn't agile". So while the agile process (Scrum or what have you) was designed to manage the change in requirements from the developers' point of view, we seemed to get away from the thing that forced the customer to update their view of things, when changing requirements midstream.
- emodendroket 11y agoI guess it depends what people mean by agile, because I've seen some people talking about agile means it's impossible to say roughly how much time work will take without starting out which seems odd.