Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Submission + - How to manage development when requirements change but deadlines do not? 1

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)
This discussion was created for logged-in users only, but now has been archived. No new comments can be posted.

How to manage development when requirements change but deadlines do not?

Comments Filter:
  • The correct agile answer is:

    1. The developers select how many of the priority features make it into the next sprint.
    2. Once selected, the feature requirements don't change. They can be dropped or implemented, but new requests go in the priority queue for the *next* sprint.

    Everything beyond that is political. You either follow the process or you jump the process. If you follow the process it's the developer's fault. If you jump the process it's not.

    The one thing you can definitely do is this: process jumping

Q: How many IBM CPU's does it take to execute a job? A: Four; three to hold it down, and one to rip its head off.