Slashdot stories can be listened to in audio form via an RSS feed, as read by our own robotic overlord.

 



Forgot your password?
typodupeerror

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

Submitted by cyclomedia
cyclomedia (882859) 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

If you have a procedure with 10 parameters, you probably missed some.

Working...