4 ms·

I was on a project where we used Agile. The team genuinely wanted to improve itself over time and we didn't have hard due dates. The thing was done when it was

by Yhippa 6y ago

I was on a project where we used Agile. The team genuinely wanted to improve itself over time and we didn't have hard due dates. The thing was done when it was done. Despite that, something felt really off. Requirements and scope kept popping out of nowhere. We tried moving onto something new yet requirements kept popping up from things we didn't consider. The project was somewhat of a legacy refactor so it was easy to say "just redo X in system Y" but for some reason it didn't work out that way. I think this project could have used some the old waterfall paradigm where you did a lot of the requirements analysis up front. Sure, you're not going to capture everything, but in this case I think it would have helped everyone involved if there was more foresight put into it up front instead of continually bumping things into the night and making stories for it.

specialist 6y ago
Every successful project I've been on has narrowed scope approaching releases. Usually because new QA/QC work crowds out new features. A bit like the KickStarter campaigns: bucket features into MVP, stretch goals, and bonus. This was mitigated by having a tempo for releases, so everyone knew those extra features were coming soon.
loopz 6y ago
Once devs and testers get traction in their work, what happens is business slacking off. Then when approaching hard dates, stakeholders suddenly wake up and demand changes to everything, often just to leave marks or to hide they dozed off. This even though agreed upon scope. Keeping this in line demands PM skills, contrary to agility. No process will save people from themselves.
- spaetzleesser 6y ago
  Very true. The decision makers kick something, fall asleep during the work and then start to panic close to the end. Agile would require constant engagement by the business people which I have seen very rarely.
- jiveturkey 6y ago
  well said
marcosdumay 6y ago
What you needed was somebody empowered to judge the cost-benefit of those requirements and disallow low gain ones. (And if they were all high benefit, then things were just working as they should.) If you tried to collect the requirements up-front, the only thing you would get would be to either stall the project before it starts (what could be a good thing), or to do the exact same process, but only after a months-log delay that created a bunch of stuff you would simply throw away.
- Yhippa 6y ago
  I agree with you and I definitely don't think the up-front approach is great. I just wish there was a way to have some kind of forward thinking instead of low-gain requirements in that randomly appear.
spaetzleesser 6y ago
Yeah. I don’t understand why people like to jump from one extreme ideology to another extreme. First it was “plan everything ahead in detail” which then got converted to “plan nothing ahead”. Both are insane and don’t work. I always ask where the decision makers see a project in maybe 3-5 years. Having that long term vision gives a lot of insight into possible software architecture decisions. You still can make changes but at least the general direction is right.

by Yhippa 6y ago

specialist 6y ago

Every successful project I've been on has narrowed scope approaching releases. Usually because new QA/QC work crowds out new features. A bit like the KickStarter campaigns: bucket features into MVP, stretch goals, and bonus. This was mitigated by having a tempo for releases, so everyone knew those extra features were coming soon.

loopz 6y ago

Once devs and testers get traction in their work, what happens is business slacking off. Then when approaching hard dates, stakeholders suddenly wake up and demand changes to everything, often just to leave marks or to hide they dozed off. This even though agreed upon scope. Keeping this in line demands PM skills, contrary to agility. No process will save people from themselves.

spaetzleesser 6y ago
Very true. The decision makers kick something, fall asleep during the work and then start to panic close to the end. Agile would require constant engagement by the business people which I have seen very rarely.
jiveturkey 6y ago
well said

marcosdumay 6y ago

What you needed was somebody empowered to judge the cost-benefit of those requirements and disallow low gain ones. (And if they were all high benefit, then things were just working as they should.) If you tried to collect the requirements up-front, the only thing you would get would be to either stall the project before it starts (what could be a good thing), or to do the exact same process, but only after a months-log delay that created a bunch of stuff you would simply throw away.

Yhippa 6y ago
I agree with you and I definitely don't think the up-front approach is great. I just wish there was a way to have some kind of forward thinking instead of low-gain requirements in that randomly appear.

spaetzleesser 6y ago

Yeah. I don’t understand why people like to jump from one extreme ideology to another extreme. First it was “plan everything ahead in detail” which then got converted to “plan nothing ahead”. Both are insane and don’t work. I always ask where the decision makers see a project in maybe 3-5 years. Having that long term vision gives a lot of insight into possible software architecture decisions. You still can make changes but at least the general direction is right.