Skip to main content
6 events
when toggle format what by license comment
May 15, 2016 at 18:03 comment added MrHinsh - Martin Hinshelwood Check the Chaos report from the Standish Group: Teams < 50 get about 25% improvement from Scrum; Teams > 50 get around 200% improvement from Scrum. Bottom line: Always use agile methods, especially on large projects...
May 10, 2016 at 10:01 comment added Venture2099 Waterfall is not impossible; try being Agile in a construction environment where concrete must be mixed and set within certain timeframes whilst concurrent activity must take place or else counter-charges start to roll in. There is no collaboration over following a plan when building a skycraper.
May 9, 2016 at 21:11 comment added Jeff Lindsey "Waterfall" is not impossible (and is actually beneficial) in situations where the development is highly repetitive and predictable, and the risks are tied to maintaining revenue (contracts, relationships, perception, etc.) rather than product fitness. That's what I mean by context, sorry if that wasn't clear. I am by no means a waterfall proponent - I've done far more agile overall, and prefer it - but it simply isn't appropriate in all situations.
May 9, 2016 at 21:04 comment added Software Engineer I didn't dictate the form of agile -- that is open to debate. However, waterfall and V don't manage risk and as such are open to criticism on this basis. Further, we all know that waterfall is actually damn near impossible, except in the extremely expensive environments I highlighted above, and that one actually ends up with both no development process and a formal system of lying to one's stakeholders and methods of justifying those lies. Make the decision to become honest now, and decide how to implement that later based on your organisational variables. Sorry if my suggestion wasn't clear.
May 9, 2016 at 20:56 comment added Jeff Lindsey No offense, but context is everything - without a LOT more info from Sam, simply prescribing "agile ASAP" (even for a tiny project) isn't very responsible. It ignores predictability of inputs/outputs, platform/service constraints, his org's culture, expectations, team personnel, partner relationships, and on and on.
May 9, 2016 at 20:05 history answered Software Engineer CC BY-SA 3.0