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

Comments

Agile?

[pixelpusher220]

We have a bastardized combo of waterfall and agile here. I call it the Drunken Sailor approach.

Re:Agile?

[Chrono11901]

That already has a name:
http://en.wikipedia.org/wiki/Avalanche_model

Re: Agile?

[MarkusQ]

We have a bastardized combo of waterfall and agile here. I call it the Drunken Sailor approach.

What DO you do with a drunken sailor?

Typically, you start working er'ly in the morning. And stay at it till the even'n's glomming.

-- MarkusQ

Re:Agile?

[kybred]

We use the Lava Flow methodology.

Re:Agile?

[Sponge Bath]

...his new features need to be done "yesterday"

If you explained the flow of time to him, you would be accused of not being a team player.

Re: Agile?

[interval1066]

What DO you do with a drunken sailor?

Maybe your experience is different but I was never put in the hold with the captain's daughter. Either that or she needed a shave and I wasn't interested in holding the mirror. It was a long voyage though.

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.

Re:Make a deadline for additions

[Anonymous Coward]

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

Re:Make a deadline for additions

[Anonymous Coward]

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.

Re:Make a deadline for additions

[Jane Q. Public]

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

I disagree. ANY additions that come in during the week are scheduled for the release after the current one. If they are really, really, desperately urgent then they replace the current release, with the current release delayed by a week.

This makes it painfully obvious to management that unscheduled changes come at a cost. They have to pay that cost, sooner or later and one way or another. Period. Best if those costs are shown up-front and in their face, rather than hidden at the expense of team morale and product quality.

Re:Make a deadline for additions

[complete loony]

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:Make a deadline for additions

[b4dc0d3r]

Making a new policy like that will not happen in an environment with "feature changes and requests that are expected to be included in this week's package". The expectation is there, and the history is there. Making a huge change like that requires getting everyone to change their expectations.

We don't have enough information to give a diagnosis. What kind of software gets a weekly build, where people expect features to be in that package and usable?

I don't see any testing - commits happen, a weekly build happens, and then what? There has to be some sort of stabilization period where someone is poking at the solution to find problems - whether it's an analyst, QA team, or user acceptance.

We don't know what parts resemble Agile - so we can't say you freeze your sprints, because you may not do sprints. Every week you seem to get to whatever you can - that's not a sprint.

And Agile doesn't have arbitrary deadlines. If you get 5 small requests that you can squeeze in, but your policy is every change pushes the deadline out, you now have 5 days. Deliver early and you undermine your own policy by proving it's arbitrary.

1) There is no testing, and that is resulting in crap releases.

2) Code seems to go live too quickly, it needs time to mature

3) I don't see any analysts in the picture, so it's still a free for all. It might be better, but it's still chaos.

You need to start explaining that this is not how development is done. You have terrible results because there is no process. Developers get blamed because they are apparently the only people responsible for getting anything done.

If anyone wants different results, something has to change, and everyone is going to have to take a hit equally. It won't be equal of course, but if you want to CHANGE the results, you have to CHANGE something. Tell everyone the situation sucks and things are changing, and explain why, from whatever applies above.

Now that you have everyone's attention, and they are feeling like they won't ever get what they want, drop the bomb. Now you have set the stage for "all new stuff takes two weeks". This means two branches - branch on Monday for example, and fixes go into the release branch, and new features go in the new branch. Weekly build comes from the release. Merge nightly. Or skip the two week rule and put in some real discipline.

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.

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.

Re:Scrum

[ATMAvatar]

Interrupting a 1-week sprint occasionally due to business needs is fine. Doing so on such a regular basis that a member of the development team feels the need to beg for help in a public forum (Slashdot, no less) is indication of a rather large management failure. Blaming schedule slips on the devs after arbitrarily changing direction shows that management has no concern or respect for them.

I know the submitter doesn't want to hear this, but if his description is even remotely accurate, he needs to start looking for another job (yes, it is *always* an option).

Simple solution

[turgid]

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 feature requests can come in at any time, but tell "them" that they will get prioritised and planned once per week and the important ones will get done in that time box. You will not change course between planning sessions.

After three or four weeks "they" will see that progress is quicker over all and the code is more stable.

Push back on your management. As a professional, it's your responsibility to do what you can to ensure the quality and timeliness of the end product. This is part of that responsibility.

Re:Simple solution

[Teancum]

This really takes a strong manager, and especially a CEO who can stand up to customers on stuff like this and especially stand up to the sales team saying "no, we won't do that". Any time there is a feature request after the "contract" is signed, it should cost the customer money. Usually it should cost that customer a whole lot of money. Keep in mind, any time there are changes like this, it really does cost the company as a whole quite a bit of money so by demanding that customers pay for those costs you are really asking for the customer to cover the cost of the product itself.

Indeed, if you are "pushing back" on management, you might even mention that it is their fiduciary responsibility to make sure that the customer pays for the things that cost the company money. That is one way to keep this kind of thing under control, as when it starts to cost the customer money they usually shut up.... or are willing to pony up a huge pile of money for things that really do matter to them. At that point, you have the option of either hiring more employees or at least reassigning people as necessary.

Yes, I know the old saying that adding programmers to a late project only makes it later. But you can take "other projects" off of developers who are running behind and do some things to at least help out. Or at least insist that the deadline needs to be pushed back plus some extra charges.

This isn't something that normally can be done by a mere grunt employee though. At best all you can do as an employee is to encourage this kind of behavior in your managers and hope they stand up on your behalf to those who don't give a damn about the pressures you are under. If you have a crappy manager, there isn't much hope other than quitting or trying to convince the CEO that your boss is worthless. That is a risky endeavor on multiple levels.

I also know that telling a customer they can't have something is risky in terms of possibly losing a contract. Sometimes you have to pick and choose, where I've seen some good managers tell a customer "no", that customer leaves, and then the customer comes crawling back begging to have the company's services again (when you should charge an even higher price). That is the ideal situation, where you are good enough that people will pay a premium for your services and are willing to at least treat you as an equal rather than shitting all over you. When the CEO lets the customer shit all over him, you should be aware that shit runs downhill and only gets worse as it moves down the food chain.

Change Management

[DexterIsADog]

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

[buddyglass]

1. Before any work is done with respect to a given request it is first assigned to a developer.
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

[TrumpetPower!]

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&

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.

Agile + Scrum?

[merick]

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

Need to go against Agile

[Todd Knarr]

The problem here is management not wanting to take responsibility for their changes. The only way I know of to fix this is to force the issue. You need a process in place that requires sign-offs for schedule changes due to new requests. Then every time these requests come in you prepare a time estimate and send out the new request and current work-in-progress with a request for management and business to assign a priority to the new work so you can determine which existing work will be impacted and can get sign-offs for those delays. Then make it clear to the people requesting the new work that it will not go into the schedule until it's been prioritized and management and business agree to any impact. The selling point to management is that this is to insure that once work has been promised by a given deadline you won't miss the deadline because of new projects without management and business knowing about it and agreeing on which projects are more important. This goes against Agile in that the whole point of the process is to prevent the development team from adjusting to new requests as they come in. Eventually you will, but you're adding "stiffness" and delay to the process to deliberately act as a stumbling block to new work and force management and business to get together first so when they come to development for an estimate they've already agreed on priorities and development can proceed to revise the schedule without anyone being surprised at delays.

Quality, Scope and Deadline

[curunir]

If you change one, you can only keep one of the others fixed. This is an immutable law of any sort of work.

Where I work, we have an agile process, but we're rigid about one thing...sprint plans don't change. Once a sprint plan is finalized and developers have accepted it, managers have two options...blow up the sprint and create a new plan (with a new deadline) or wait until the next sprint. The former option is supposed to be an extreme case and all checkins for the sprint, whether complete or not, are reverted to the previous sprint state. This allows management the flexibility to not wait in emergencies (i.e. we signed a multi-million-dollar partnership with XYZ but their shrink-wrapped software releases two weeks from now and we need our integration by next week) and yet provides enough of a penalty that they don't do it very often.

One Simple Sentence

[Anonymous Coward]

"All of our development bandwidth for this sprint is committed. Which item would you like to delay to make room for this one?"

In the spirit of my title, the second sentence is, of course, the important one.

You've already lost this battle

[Mandatory Default]

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.

What would a chef do?

[Culture20]

If a restaurant customer changes their mind while the chef is cooking their choice of meal, or maybe forget to request "no mushrooms" until 20 minutes after ordering, they may get the new dish, but they won't get it on time, and reasonable people understand that. Of course there are always unreasonable customers. Management reserves the right to not serve them.

Re:Agile is about commitment, not flexibility

[rwa2]

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

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