5 ms·

> you must explain to your stakeholders beforehand that these estimates are only for course correction during the development process, and they’re separate from

> you must explain to your stakeholders beforehand that these estimates are only for course correction during the development process, and they’re separate from estimates you will give of when features will be done overall. ... > if you do put in the time to do estimates, you will spend less time coding - but because your team will be able to respond to things immediately, you will still reach your objective more quickly. This sums up the best argument I've read about the advantages of best practices agile software development. It's a shame some companies cargo cult agile as a way to bully engineers into being "more productive" in a brute force manner. That is, unrealistically cramming tickets into a sprint to gamify higher "velocity." Really agile is just about a more efficient development process. Agile provides a framework for discovery and course correction via planning/imagination/whiteboarding, and that is significantly faster than discovery via writing code.

ntietz 8y ago
Yes, exactly! It's such a shame that people think "more efficient process" means "we'll ship more lines of code" when really it is all about getting to the _correct solution_ more quickly.
- AstralStorm 8y ago
  Presuming you know what the correct solution is. This is the key point of agile processes, that you get to quickly discover what is required, optional and completely unnecessary. Generally by having a real customer (not a silly proxy) in the room or by sending out probe releases often and collecting feedback.
- _0ffh 8y ago
  Of course, "more lines of code" is about the worst possible metric for sw development success imaginable, anyway.
AstralStorm 8y ago
Why stakeholders decide about anything related to your development practices? Is it because... A) your hiring people like well known keywords B) someone is beholden to a bureaucratic process C) someone lied and broke trust? If you cannot deliver, just say so. If there are insurmountable barriers, as well. Why provide a bad guess to which you will be held, and this cause people to make wrong decisions based on the guess? Estimates are only good when you have strong basis for them. Software developer cannot in general have such a basis unless they're copying or adapting in trivial ways already made software. A civil engineer, on the other hand, can use a reference group strategy easily to compute cost and materials required, but not necessarily timescale. They can provide at best a reasonable, very wide range.
- slededit 8y ago
  Stakeholders will use your work product as part of some larger process. They need estimates so they can plan. They can't just turn on a dime when you say your finished.
  - AstralStorm 8y ago
    That's not an estimate then, it is a commitment. If you break someone's plans it is often worse than not having planned at all. Unless the plan is extremely flexible... Agile. Then the plan barely matters so why make one at all? Have a detailed unordered playbook instead and potentially a guiding strategy. (sometimes a playbook is timed, that is less flexible than untimed conditional plays and generally shows that you lack information) In case the words are confusing, plan is on tactical level and related to day to day operations. A playbook is a set of small roughly sketched plays to be used when conditions are met. A play differs from a plan by level of detail and size. "Release by the end of June" is rarely a good plan, "release before competitor adds a similar feature" might be. The date is reifying unknown to look known but does not make it so, and if leaked helps your competition plan. Deployment can be done whenever and unlike development is often much more predictable. Likewise marketing. Usually the story is that the stakeholder is targeting some annual demo event and that gives a strict timeline. Any of your estimates is worthless and useless then, only tracking and feature set near the time of such event so that marketing can decide what to show and whether to show anything at all. And the marketing takes some time too, so the stakeholder probably wants to know how ready something is before launching that machine, but not too much before or they might overhype and burn. Trying to do it backwards, when the features are time boxed target generally goes poorly as the features get implemented in a checklist but not useful, usable or extensible matter. (Scrum results in this too.) Second type of "stakeholder" is a time minded investor. Again that is a commitment not an estimate, since it you do not provide a good enough product you will not get paid and probably fold. Then there's a combination of both when trying to outdo established competition with known upgrade patterns.

ntietz 8y ago

Yes, exactly! It's such a shame that people think "more efficient process" means "we'll ship more lines of code" when really it is all about getting to the _correct solution_ more quickly.

AstralStorm 8y ago
Presuming you know what the correct solution is. This is the key point of agile processes, that you get to quickly discover what is required, optional and completely unnecessary. Generally by having a real customer (not a silly proxy) in the room or by sending out probe releases often and collecting feedback.
_0ffh 8y ago
Of course, "more lines of code" is about the worst possible metric for sw development success imaginable, anyway.

AstralStorm 8y ago

Why stakeholders decide about anything related to your development practices? Is it because... A) your hiring people like well known keywords B) someone is beholden to a bureaucratic process C) someone lied and broke trust? If you cannot deliver, just say so. If there are insurmountable barriers, as well. Why provide a bad guess to which you will be held, and this cause people to make wrong decisions based on the guess? Estimates are only good when you have strong basis for them. Software developer cannot in general have such a basis unless they're copying or adapting in trivial ways already made software. A civil engineer, on the other hand, can use a reference group strategy easily to compute cost and materials required, but not necessarily timescale. They can provide at best a reasonable, very wide range.

slededit 8y ago
Stakeholders will use your work product as part of some larger process. They need estimates so they can plan. They can't just turn on a dime when you say your finished.
- AstralStorm 8y ago
  That's not an estimate then, it is a commitment. If you break someone's plans it is often worse than not having planned at all. Unless the plan is extremely flexible... Agile. Then the plan barely matters so why make one at all? Have a detailed unordered playbook instead and potentially a guiding strategy. (sometimes a playbook is timed, that is less flexible than untimed conditional plays and generally shows that you lack information) In case the words are confusing, plan is on tactical level and related to day to day operations. A playbook is a set of small roughly sketched plays to be used when conditions are met. A play differs from a plan by level of detail and size. "Release by the end of June" is rarely a good plan, "release before competitor adds a similar feature" might be. The date is reifying unknown to look known but does not make it so, and if leaked helps your competition plan. Deployment can be done whenever and unlike development is often much more predictable. Likewise marketing. Usually the story is that the stakeholder is targeting some annual demo event and that gives a strict timeline. Any of your estimates is worthless and useless then, only tracking and feature set near the time of such event so that marketing can decide what to show and whether to show anything at all. And the marketing takes some time too, so the stakeholder probably wants to know how ready something is before launching that machine, but not too much before or they might overhype and burn. Trying to do it backwards, when the features are time boxed target generally goes poorly as the features get implemented in a checklist but not useful, usable or extensible matter. (Scrum results in this too.) Second type of "stakeholder" is a time minded investor. Again that is a commitment not an estimate, since it you do not provide a good enough product you will not get paid and probably fold. Then there's a combination of both when trying to outdo established competition with known upgrade patterns.