3 ms·
> I think the answer badly misconstrues the purpose of "short term planning" ... 'short term planning' appears to be your construct, not found in TFA. Short t
by Jedd 7y ago
> I think the answer badly misconstrues the purpose of "short term planning" ...
'short term planning' appears to be your construct, not found in TFA.
Short term implies reactive / tactical -- not the planned / strategic level that TFA is talking about.
It may well be that Agile 'precludes long proof-of-concept projects', given its essence is 'better ways of developing software', which clearly hides a wealth of complexity behind the heading of user-facing software.
- pas 7y agoAgile (and XP) realised that it's a folly to plan in detail the next 5 years when likely the project, the circumstances, the business landscape, the team and even the technology will significantly shift in that timespan. This of course doesn't mean that if you have a very concrete goal and you need to do a trial and error iterative research and development project, there is of course no need to do "agile", because the goal is fix, the things you can try is probably largely predetermined, and you already know one of them will work adequately. (Or not, but then at least you might have some form of benchmark target in mind.) But even then, almost no endeavor starts in a vacuum, so it likely pays off to have some ability to quickly check progress (be it a CI system or just a testbed in the lab, or the aforementioned benchmark), and similarly other aspects of "agile", like try to break up the work and estimate it (think about it, its dependencies, its complexity, your competence for the particular work item, typical pitfalls), let the team know who works on what, interact with stakeholders from time to time, and so on.