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)"

Make a deadline for additions

[kawabago]

Any additions must arrive 3 days before weekly build otherwise they come out the following week. That is a perfectly reasonable approach to keep things moving on time.

When requirements change in-sprint

[NastyNate]

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.

Scrum

[sanosuke001]

Tell them that you do 1-2 week sprints where you have a set amount of tasks. If they want new things added, they have to wait until the next sprint. Give them a login to your tracker site so they can view the progress/status. Have them come to sprint meetings as well so they have some input.

Historical (Hysterical?) Observation

[3leggeddog]

I hope no one thinks this is a new problem. We had it back in the early 1960's (yes, really, all of a half-century ago). I once was told to attend a conference which stretched on for three days trying to get agreement on how long after the last change order the users would have to wait for delivery. The closest we could get to agreement was that if the change orders never stop there will never be delivery, and only the developers agreed to that: all the managers would agree to was "It can't be that bad." I didn't go back after the first day; I had constructive things to do.

You need someone to say no.

[miltonw]

What I always did with change requests: The rule was, you must get an estimate and approval for ALL changes. The estimate would include how long it would take -- and I was real good at estimating that. The approval would explicitly be for the additional time required for the change -- meaning how much that change would push back the schedule. Most "urgent changes" became "oh, never mind". Any that survived and got approved automatically adjusted the budget and schedule to accommodate the change - so I remained on schedule and on budget.

Re:Scrum

[hey!]

I second the nomination of Scrum, which complements agile development practices.

Scrum is about managing development priorities. You can't work efficiently if you keep changing priorities every day because nothing will ever get finished. On the other hand, if you *never* change development priorities until you've finished everything you set out to do, developers are happy but they might not be working on things the business needs or wants.

The truth is that businesses have to respond to change. A rival announces a new feature; the price of some related product or service changes dramatically; regulators threaten to fine your company for some reason; a PR scandal forces your CEO to get up and make public promises you'd never imagined. Things like these can change a business's priorities, and if your employer's priorities change, yours ought to as well. Just not so often you never manage to finish anything.

Scrum strikes a sensible balance between changing direction so often you never finish anything, and putting your head down and finishing things but then finding out your employer actually needed something else. Don't get me wrong, if you *can* keep the same priorities for months on end, you should. But in many situations you don't have that luxury. You have to respond to business changes, while at the same time finishing what you set out to accomplish.

Re:Scrum

[AmiMoJo]

We have a board with magnetic labels that we write tasks on. When a new task comes in it gets a label and is stacked under the name of the person assigned to it. Anyone wanting to give us a new task has to physically push the other stuff we have down the board in order to stack their's on top, or accept a lower priority.

We started adding time estimates to the tasks with a simple green/amber/red colour coding system too. We assign the colour before handing the label to the boss. It's very handy when you have multiple people wanting you to do stuff because they can fight out priorities between themselves.

You can't

[lightknight]

The short answer is that you can't. Your boss, if he / she is a programmer, will go to bat for you, and say "this won't happen; deal with it." If they aren't, you're screwed.

See, in the business world, much to its caricature, there are people who think they are business-savy. They watch 'The Apprentice' with a notepad in hand, and think that when it comes time to handling outside work, it's all about how fiercely you negotiate. Your non-programmer boss, who got his start in sales / marketing, is used to promising people stuff that others need to deliver on...as well as combing over any problems when a 'whoopsie' happens (missed deadline, etc.); he is also used to the idea of pandering to the client, and doesn't understand the intricacies of telling the client, in non-subtle, but non-insulting language, that something simply cannot happen.

So, when your client comes to negotiate with your boss, he's going to give them everything for nothing; he doesn't know this, but he does it. He's going to ask for time estimates from a programmer, where things operate in a completely different kind of world (every project is a new set of problems, first rule; ergo, all time estimates are vague and unreliable...even for 'easy' projects, because of some stuff I will touch on later); he's going to take these time estimates, and shave them down...asking the programmer, "Can't we try to get this done by Tuesday? And we can fall back to Friday if it doesn't work out." The programmer, of course, will tell him the truth (the programming / mathematical truth), which is "Sure, we can try to get it done faster." But in reality, it's not a magic button that gets pressed to make things 'go faster.' So, your boss tells the client his truth, which is that the project will possibly be done by Tuesday. The client, hearing this, thinks that it might be done by Monday, but will begin annoying your boss via phone calls as of Tuesday.

Now, let's take a moment to look closely at some of the elements around this scenario: your boss is going to charge the client for a certain amount ($2K), based off of your low wage, long hours, and another project that will be coming up a few days later for another client (it's all about volume). The actual cost of the project is $3K, but after your boss is worked down in negotiations ("We need to keep this client / build a relationship. We'll make it up to you with more work down the line / another project from them that will be worth more at some point in the future."), it'll be $2K. Bear in mind that the Tuesday deadline is actually negotiated by this client as well...so from their viewpoint, they've gotten a pretty sweet deal according to Apprentice 101: by dominating your boss, they got him to place their project at the top of the 'critical priority' pile...and they saved themselves $1K.

Your boss, believing the lies of his industry, thinks he's building a relationship with the client...he's not, since the client will bounce as soon as he tries increasing the costs anywhere near market rate, and they know that they can tweak him at will to speed things up / shave costs because he's already done it once before. Meanwhile, you, the programmer, are doing $7K worth of work, and enjoying near constant panic attacks because -> the client submits development requirement changes piecemeal, via email, telephone, SMS, Skype, and toilet paper. Your boss, of course, will come to you, and ask you if you can just do these extra tasks...that they won't take too much extra time, right? Of course not...changing the backend from SQL to NoSQL, and the frontend from ASP.NET to PHP shouldn't take any extra time at all...you're a programmer...you're second-kin to a magic elf...you can just not sleep, and reach into your magic bag of tricks, and pull off this thing by Tuesday's lunch. And skilled salesman that your boss is, he's either giving the changes away to the client for free, or taking on an absurdly low number for the additional work ("It'll pay for itself in the long run, you'll see!").

So, Monday