Slashdot Mirror
Ask Slashdot: Development Requirements Change But Deadlines Do Not?
cyclomedia writes "Over a number of years my company has managed to slowly shift from a free-for-all (pick a developer at random and get them to do what you want) to something resembling Agile development with weekly builds. But we still have to deal with constant incoming feature changes and requests that are expected to be included in this week's package. The upshot is that builds are usually late, not properly tested and developers get the flak when things go wrong. I suspect the answer is political, but how do we make things better? One idea I had was that every time a new request comes in — no matter how small — the build gets pushed back by 24 or even 48 hours. I'd love to hear your ideas or success stories. (Unfortunately, quitting is not an option)"
We have a bastardized combo of waterfall and agile here. I call it the Drunken Sailor approach.
People in cars cause accidents....accidents in cars cause people
The sprint should start over. It encourages stakeholders to not interrupt the current sprint and to wait for the next sprint to shift priorities or introduce requirements.
I go upstairs to the salesman who promised that feature to the customer without changing the deadline, grab him by his shirtcollar, and tell him, "You worthless overpaid coke-addled dumbfuck...if you ever, ever pull that shit on me again, you'll be explaining to the customer why you're talking like a soprano and walking like a cowboy."
-- Ethanol-fueled
Pretty much this. Don't change the deadline of the weekly build, set different dates for when the feature appears. One thing our team did was state up front that no new feature would appear for two weeks. Not today, not yesterday, not at the end of the week. Our policy became "all new stuff takes two weeks". This let us spend time fixing things and gave us a buffer to introduce and test stuff before it got rolled out. It ticked off some managers at first because they were used to stuff getting set up or committed right away, but we stuck to it and they eventually learned they had to plan ahead. Well, most of them learned.
You think you're fighting manager's lack of understanding of software development. You are wrong.
You are fighting politically savvy people who have found a way to blame you for their problems. They don't want you to solve the problem and will actively work to prevent you from solving the problem, because then you can't be the scapegoat.
If you don't have a VP or C-level manager who will fight this fight for you, then you've already lost. Don't bang your head against the wall. Play the same game as everyone else and find someone else that you can use as a scapegoat. Meanwhile, start looking for a new job.
Even if you miraculously "fix" this problem, someone else is going to claim credit and you're going to get nothing.
"Agile" is something of a misnomer... it's about committing to the work items you've estimated into your current sprint -- and no more. If someone wants to add a feature or request, it goes straight into the backlog for consideration during the next sprint planning session.
"Agile" is more about setting up a consistent delivery schedule... the build train leaves the same time each week, carrying whatever passed QA testing... and no more. The build train is never delayed, only derailed by an Act of God. That's right, if some exec really thinks that something is so important that it needs to be done *right now*, you completely stop all work, scrap the current sprint and start a new sprint planning session with all of the overhead that entails.
Anyone who practices differently is not practicing Agile according to the way it was intended. There are no "sprint schedule extensions" in Agile, since it's a measurement and estimation tool... the same way you don't measure with a longer "yardstick" when something is too big to fit in a 1-yard container.