4 ms·

I think engineers need to start talking about this concept in a much more official way, and approach it with the business side as another full task type called

I think engineers need to start talking about this concept in a much more official way, and approach it with the business side as another full task type called "Technical Discovery," with clear goals and a clear time-box.

maxxxxx 8y ago
In my company everybody goes over spec sheets and endless meetings to determine the right approach instead of just sitting down and using the time to try things out. A big problem is that there is also no culture of being allowed to say that an experiment has failed and we'll either cancel or try something else.
alasdair_ 8y ago
Hasn't this been a core component of doing "agile" in any meaningful way since the beginning? Example: "architectural spikes" in eXtreme Programming: http://www.extremeprogramming.org/rules/spike.html http://www.extremeprogramming.org/rules/spike.html
- maxxxxx 8y ago
  Yes, this is how Agile should work but rarely gets done from what I have seen.
- aninhumer 8y ago
  One thing I've been thinking lately is that this should be baked into the process for every unit of work, not just those people expect to be difficult. Instead of estimating by guessing based on reading the requirements, work on an issue for say an hour or so and then estimate it. It still wouldn't be perfect, but I think this would catch a lot of cases where, for example, a seemingly simple feature ends up requiring an extensive model change. It would also do a much better job of shaking out cases where the requirements aren't as clear as you thought when you start trying to code it.
- lazyasciiart 8y ago
  Oh, you'd think so. Then you might be unlucky enough to work with some 'senior programmers' who have been 'doing Agile for years' and are able to convince the manager that a spike that doesn't result in code that will go to production is a waste of time. I never worked out whether that was malice or stupidity.
- gaius 8y ago
  The irony being that XP and the like are only suited to cookie-cutter, commoditised work that is essentially risk-free anyway
  - TheCoelacanth 8y ago
    I couldn't disagree with this statement more. On projects that are breaking new ground it is even more important to follow XP practices like getting frequent feedback from customers, taking the simplest solution that could possibly work to avoid overengineering before you actually understand the problem, to embrace change because your original understanding of the problem probably isn't right. There also is plenty of risk involved in cookie-cutter commodity work. Those kinds of projects fail all the time.
    - gaius 8y ago
      Those kinds of projects fail all the time. ... because they use snake oil methodology like XP...

maxxxxx 8y ago

In my company everybody goes over spec sheets and endless meetings to determine the right approach instead of just sitting down and using the time to try things out. A big problem is that there is also no culture of being allowed to say that an experiment has failed and we'll either cancel or try something else.

alasdair_ 8y ago

Hasn't this been a core component of doing "agile" in any meaningful way since the beginning? Example: "architectural spikes" in eXtreme Programming: http://www.extremeprogramming.org/rules/spike.html http://www.extremeprogramming.org/rules/spike.html

maxxxxx 8y ago
Yes, this is how Agile should work but rarely gets done from what I have seen.
aninhumer 8y ago
One thing I've been thinking lately is that this should be baked into the process for every unit of work, not just those people expect to be difficult. Instead of estimating by guessing based on reading the requirements, work on an issue for say an hour or so and then estimate it. It still wouldn't be perfect, but I think this would catch a lot of cases where, for example, a seemingly simple feature ends up requiring an extensive model change. It would also do a much better job of shaking out cases where the requirements aren't as clear as you thought when you start trying to code it.
lazyasciiart 8y ago
Oh, you'd think so. Then you might be unlucky enough to work with some 'senior programmers' who have been 'doing Agile for years' and are able to convince the manager that a spike that doesn't result in code that will go to production is a waste of time. I never worked out whether that was malice or stupidity.
gaius 8y ago
The irony being that XP and the like are only suited to cookie-cutter, commoditised work that is essentially risk-free anyway
- TheCoelacanth 8y ago
  I couldn't disagree with this statement more. On projects that are breaking new ground it is even more important to follow XP practices like getting frequent feedback from customers, taking the simplest solution that could possibly work to avoid overengineering before you actually understand the problem, to embrace change because your original understanding of the problem probably isn't right. There also is plenty of risk involved in cookie-cutter commodity work. Those kinds of projects fail all the time.
  - gaius 8y ago
    Those kinds of projects fail all the time. ... because they use snake oil methodology like XP...