Ask Slashdot: Development Requirements Change But Deadlines Do Not? 221
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)"
Re:Agile? (Score:3, Informative)
That already has a name:
http://en.wikipedia.org/wiki/Avalanche_model [wikipedia.org]
Change Management (Score:4, Informative)
It's a discipline, it's part of project management, it works. You can look it up.
I don't believe this answer will be well received on /. because it is usually practiced by project managers, and /. doesn't believe in project management.
uhh (Score:5, Informative)
2. The developer's first job is to estimate how long it will take to satisfy the request.
3. If the request is too vague for an estimate to be made then the developer conferences with the request's originator to get the information he needs.
4. Once a time estimate has been made, the developer communicates it to a project manager.
5. If the request can be accommodated without delaying the release then the project manager gives the go ahead for the work to begin.
6. If the request cannot be accommodated without delaying the release then the project manager conferences with its originator (and the originators of any other requests currently slated for the current release) to determine which will be dropped.
Not many options (Score:5, Informative)
First, you can -- and probably should -- just accept that the deadlines don't mean anything. They self-evidently don't to anybody else, so why should they to you?
But if you must pretend that they mean something, then you've really only got three options:
1) adjust the deadline based upon how much actual work is involved with the new request;
2) factor into your initial estimate how much you think it'll take to do what you think they're likely to add on later;
3) or make new requests a separate project with their own life cycle.
This, of course, assumes that you're the one estimating time and setting deadlines. If somebody else is doing all that, forget about it. It's not your problem; it's the problem of whomever is setting deadlines. Either they need to be doing a better job at time / project / resource management, or they need to bring on enough additional developers to meet the demands, or they need to fire the incompetent hacks they've got working for them now who can't meet the demands of the job. Whatever the case may be, it's a management problem and nothing for a developer to worry about.
Cheers,
b&
Agile + Scrum? (Score:4, Informative)
If you are using Agile with a combination of Scrum (like we do), then every task is roughly estimated for the size of work required. In each sprint, you can only accomplish so much work. Over time you determine your teams "velocity" (the estimated size of work you can do in a sprint).
Then, you have a person who plays the role of Scrum master. His or her job is to "protect the sprint". Meaning they help keep new issues from entering the queue during the sprint. When an actual emergency or rush item comes up, the Scrum master (or lead, whomever) asks, "what is OK to drop from the sprint if we can't get both done?". Some places take turns being the Scrum master, so it need not be a set role.
The Scrum master has to be willing to be that gentle jerk, and say things like, "not now, but we can work on that in the next sprint".
Re:Agile? (Score:5, Informative)
We use the Lava Flow [wikipedia.org] methodology.
You've already lost this battle (Score:5, Informative)
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.
Re:Make a deadline for additions (Score:4, Informative)
Branch the source code!
You should *always* have a stable base version that can be released at a moments notice. Each feature should be developed and tested on a branch. If the feature isn't "done", it isn't merged. If you discover a bug after merging you back it out again and review how you missed it.
Pausing development of the current set of half-finished features so you can shift priorities onto something else, should be as simple as creating a new branch and ignoring the others until your next sprint.
Re:Agile is about commitment, not flexibility (Score:5, Informative)
"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.