Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: Development Requirements Change But Deadlines Do Not?

Soulskill posted about a year ago | from the anonymous-emails-and-heavy-drinking dept.

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

Sorry! There are no comments related to the filter you selected.

Agile? (5, Funny)

pixelpusher220 (529617) | about a year ago | (#44243663)

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

Re: Agile? (1)

jd2112 (1535857) | about a year ago | (#44243731)

What DO you do with a drunken sailor?

Re: Agile? (0)

Anonymous Coward | about a year ago | (#44243823)

You don't want to know.

Ok, I'll tell you anyway. It involves a barrel with a hole in it.

Re: Agile? (4, Funny)

MarkusQ (450076) | about a year ago | (#44243843)

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? (1)

HaZardman27 (1521119) | about a year ago | (#44243865)

It depends. Is said sailor drunk during acceptable hours, such as the evening, or is it early in the morning?

Re: Agile? (1)

Teancum (67324) | about a year ago | (#44244087)

It depends. Is said sailor drunk during acceptable hours, such as the evening, or is it early in the morning?

At this point in time, are you sure of the gender or even gender preference of the said sailor?

Re: Agile? (1)

Anonymous Coward | about a year ago | (#44244287)

put 'em in a scupper with a hose pipe in 'em!

Re: Agile? (3, Funny)

interval1066 (668936) | about a year ago | (#44244743)

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.

Re:Agile? (1)

Anonymous Coward | about a year ago | (#44243755)

We're more of the shitpile approach... I just tell my boss that every time he adds a new feature that "must" be on the new release how long that feature should take ( plus 10 - 15% ) and that it will take that much longer for the release. Then he can either choose to have that feature added to the next release or remove a feature that hasn't been worked on yet to get it out the door when he wants it done.

The biggest problem is that most of his new features need to be done "yesterday" and there's nothing to do but drop everything and add what he wants...

Re:Agile? (5, Insightful)

Sponge Bath (413667) | about a year ago | (#44244013)

...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? (3, Informative)

Chrono11901 (901948) | about a year ago | (#44243761)

That already has a name: []

Re:Agile? (4, Informative)

kybred (795293) | about a year ago | (#44243957)

We use the Lava Flow [] methodology.

Re:Agile? (2)

leuk_he (194174) | about a year ago | (#44244271)

Thx for the link, but then the only reference to avalanche is mainly that wiki article... i am suprised it was not taken down without citations.

Re: Agile? (0)

Anonymous Coward | about a year ago | (#44243813)

Sounds like they need Project Managament that follows PMBOK and is supported by upper management.

Re:Agile? (1)

interval1066 (668936) | about a year ago | (#44244689)

Rated funny, but all too true. Almost EVERY shop I've worked at said they were Agile but really just ended up being agile/waterfall. its getting so that every job I go for (consultant here) who claims to be agile makes me just grin to myself. Once I caught one of the engineers I was interviewing with let out that same wry grin while the HR manager expounded on how 'agile' the company was. I've worked in and around silicon valley almost all my profressional life and I've never worked a smoothly functioning agile shop, as far as my understanding of the process is. I may be a fool, but I think I have a good grasp on what agile is from all the literature and online material I've read. Seriously? Who is using it to success?

Make a deadline for additions (4, Interesting)

kawabago (551139) | about a year ago | (#44243709)

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 (5, Funny)

Anonymous Coward | about a year ago | (#44243829)

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 (1)

Sponge Bath (413667) | about a year ago | (#44244423)

...talking like a soprano and walking like a cowboy.

Swaggering Tony Soprano: I wipe my ass with your feelings.

Come on pop culture sponges, name that episode.

Re:Make a deadline for additions (-1)

Anonymous Coward | about a year ago | (#44244611)

It was admittedly a confusing and contradictory statement. Talking like a soprano, with lower-case "s", doesn't mean they're tough like a mob boss - It means that they have the effeminate high-pitched voice of an upper-register vocalist (should I have used the words "castrati" or "falsetto?"). Walking like a cowboy is also not meant to be a sign of masculinity, it is a sign of having something (like the front half of my shoe) lodged up their ass. I was trying to say that ol' boy was socked in the nuts and then kicked in the ass -- deservedly.

But now its not funny anymore, because I just explained it.

-- Ethanol-fueled

Re:Make a deadline for additions (5, Insightful)

Anonymous Coward | about a year ago | (#44243931)

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 (1)

intermodal (534361) | about a year ago | (#44244063)

It's pretty much the only way. push through and pull off the unreasonable, especially repeatedly, and you just poison your own future.

Re:Make a deadline for additions (4, Insightful)

Jane Q. Public (1010737) | about a year ago | (#44244591)

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

jimshatt (1002452) | about a year ago | (#44244803)

Precisely. That way, you can still live up to being 'agile' (which doesn't mean you can jump through hoops). Bits of work (sprint, iteration, whatever) being worked on cannot be changed in mid-air.

When requirements change in-sprint (5, Interesting)

NastyNate (398542) | about a year ago | (#44243711)

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.

Re:When requirements change in-sprint (0)

Anonymous Coward | about a year ago | (#44243883)

That's not feasible in most environments. There is also very little likelihood that one of the developers is going to have the authority to implement such a controversial decision as automatic timeline resets on feature changes.

Developer, you already know how management wants you to handle this: Work 60 hours while billing 40. However, you can try to give them additional proposals. What my last employer did was create stories in the next sprint for feature changes. This had the advantage that customer whims were well documented and everyone could see in the metrics how much time they ate up The drawback was that it really did eat up a lot more time than it should have, because developers would fully implement the old request then scrap it in a week to work on the revision.

My current employer is more of the work 60, bill 40 type of place and customers don't even look at mock-ups until code has started to be written, because they have no reason to think that last minute changes are bad. After all, the sprints are being completed on time and feature-full. I am not aware of a middle ground between the two approaches.

Charge them (0)

Anonymous Coward | about a year ago | (#44243719)

For any change, have them sign a document and charge them.

New requests go in future builds (1)

Anonymous Coward | about a year ago | (#44243737)

New requests should not be integrated into current or even the build, but should be kicked into the long grass and added as time permits. Do not make agreements to have new features integrated into a particular release, just state that they gradually appear in time. Then there is no pressure and the quality of the builds will go up.

Scrum (4, Interesting)

sanosuke001 (640243) | about a year ago | (#44243747)

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 (2)

Kjella (173770) | about a year ago | (#44244159)

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.

Unfortunately at my job the boss tells me what to do, I don't tell him what to do. All I can do is give him options, like saying there's no time for everything so what would he like to put on the back burner. If he tries the usual BS on how surely you can squeeze it in there I usually point out that if there was room in the original plan we'd have added more tasks until it was full, we don't have any time set off for goofing around. I'd also point out how inefficient it is and how these rushed solutions ruin the overall quality, but if they don't listen hey... I only work there, I don't run the place. If the same retarded rules and system applies to the other employees too, I'll probably still come out ahead on reviews even if you're driving with the handbrake on. It also keeps you sane when the WTFs are of a kind or on a level you can't do anything about.

Re:Scrum (4, Interesting)

AmiMoJo (196126) | about a year ago | (#44244503)

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 (3, Interesting)

hey! (33014) | about a year ago | (#44244387)

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.

Making it better (0)

Anonymous Coward | about a year ago | (#44243759)

We use agile and determine our teams average velocity per 2 week iteration to be able to gauge how much work we can do during a 2 week period. The team commits to a certain amount of work for two weeks during a planning meeting. If new things need to come in after the planning meeting, something we were going to work on will need to go out to replace it. Otherwise, the new item goes in the backlog for consideration in the next iteration.

Say No (1)

Anonymous Coward | about a year ago | (#44243765)

I learned the "say no" trick. Basically I present them with what I'm working on right now and say "this can't all happen, what would you like to take out". It doesn't make me super popular, but I've found most people appreciate honesty over disappointment.

Re:Say No (2)

Chrono11901 (901948) | about a year ago | (#44243987)

I second this... I would also drive home the fact that the lack of quality is a direct result of them interfering with the development process.

Simple solution (4, Insightful)

turgid (580780) | about a year ago | (#44243767)

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 (3, Insightful)

Teancum (67324) | about a year ago | (#44244359)

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.

Charge them (0)

Anonymous Coward | about a year ago | (#44243769)

For any change, have them sign something and charge extra for it as it was not included in the original design.

Either featurefreeze or delay up front (2)

PastaAnta (513349) | about a year ago | (#44243773)

When someone requests new features you have two options:
- Tell them they have missed the feature/requirement freeze and will have to wait until next iteration.
- Tell them that, if they insist, it will delay the release.
Do not compromise the quality of the release.

Re:Either featurefreeze or delay up front (0)

Anonymous Coward | about a year ago | (#44244015)

The corollary is obvious but needs to be stated:
If one of your customers still insists, do actually skip that release, and inform all customers of why the release was skipped and who insisted.

If developers are currently getting flack for code quality, and you'd prefer to get flack for delaying feature implementations, that's the way to go.

That's what change orders are for (1)

DougDot (966387) | about a year ago | (#44243789)


Be honest (1)

abigsmurf (919188) | about a year ago | (#44243791)

Quote the number of hours to implement a new feature or change request.

Adding an arbitrary fixed minimum for the changes and features is just going to piss them off and seem stupid, especially for trivial changes.

Quote them a realistic time, show them that quote when they want something rushed through and it deploys with serious issues.

Change Management (4, Informative)

DexterIsADog (2954149) | about a year ago | (#44243795)

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.

Re:Change Management (2)

American AC in Paris (230456) | about a year ago | (#44244247)

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.

Slashdot most decidedly believes in project management. In fact, The Slashdot Consensus very fervently believes that project management is too important to be entrusted to project managers; like marketing, sales, management, and pretty much every other non-technical facet of business, project management is doomed to fail unless the technical people are doing it.

We'll call it "Slashdot's Rule of Business": No matter what the task, the only people to which it can be reasonably entrusted are the computer geeks.

Re:Change Management (0)

Anonymous Coward | about a year ago | (#44244489)

If you get to know ITIL more intimately, you may discover that the end output of projects are input to the Change-process. Projects are typically incredibly more complex and manually driven beasts than the typical maintenance or migration Change. So comparing project / development processes to the Change-process is more like comparing a basket of apples to bicycles. One is not really part of the other.

A project may spawn off many Changes during it's whole lifecycle, yes. However, the processes going on in projects can vary from project to project, while Change Management should follow the exact same process every time. Change Managament really is not part of Project Management, is done by total different functions, and for projects, is preferred but not mandatory, not even always the best way to accomplish project goals.

TROLL (-1)

Anonymous Coward | about a year ago | (#44243801)

Smith only serve To get involved in to get involved in Good to write you fact came into expulsion of IPF same year, BSD World-spanning show that FrreBSD

Weak management (1, Insightful)

Anonymous Coward | about a year ago | (#44243807)

In my experience, this is an indication of weak management, usually (but not exclusively) in the software development group. Rather than adjusting the build schedule you need to stop the feature creep. Once a development cycle starts the feature list should be locked until the next cycle starts.

Since you suggest that this occurs on a semi-regular basis, someone in the management chain either doesn't care about the slips or doesn't recognize what is actually happening because their subordinates are incompetent. No software manager enjoys being castigated for schedule slips, and good ones figure out what is wrong and address it. If you really want things to change, you'll probably need to figure out where the weak link is and work to get it removed.

Re:Weak management (0)

Anonymous Coward | about a year ago | (#44244097)

This +10000

When i first started here we had constant feature creep on releases from our customer. After a few years though management finally decided they had enough and started getting it in writing from the customer exactly what they expected on releases and if they wanted any new features after writing that up then they were SOL and would have to wait for another release

Mature engineering. (1)

Impy the Impiuos Imp (442658) | about a year ago | (#44243809)

Have a deadline for new features or bug fixes for that week.

Proper engineering (engineering is about how you build things, not about just crafting the thing itself) typically should look like this:

- Requirement deadline (Specify bug to fix or new feature)
- Software domain deadline (To do the above)
- Integration deadline. (Integrate above into larger project)
- Test deadline (verify bug fix or feature. Without getting fancy, must budget time for repairs)
- Customer delivery deadline.

The key is to work this stuff backwards.

Software moves a lot faster than hardware, but it does not move infinitely fast. Normal hardware works on the order of months for these things, working backwards from Job 1 to factory tooling to a half-dozen proveouts of HW and assembly line.

Software needs to recognize this and stop playing the infinitely fast "It should work." famous last words game.

uhh (4, Informative)

buddyglass (925859) | about a year ago | (#44243817)

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.

THIS! (1)

Chirs (87576) | about a year ago | (#44243935)

Ultimately someone needs to be responsible for what gets into a given release. And given a fixed pool of developers, if something new comes in then something else likely needs to get pushed out.

Re:uhh (2)

jimshatt (1002452) | about a year ago | (#44244869)

Just getting through these steps is already going to delay the release?

Not many options (4, Informative)

TrumpetPower! (190615) | about a year ago | (#44243821)

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.



Send it back upstream (0)

Anonymous Coward | about a year ago | (#44243833)

Force a delay somehow.

Requirements given for a new project? Send it back to analysis with some question that you know will force it to be reviewed. Knowing most BA's that should give you at least 2 days.

Historical (Hysterical?) Observation (4, Interesting)

3leggeddog (981745) | about a year ago | (#44243837)

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.

Just quit. (1)

Narcocide (102829) | about a year ago | (#44243847)

No amount of sane, productive, alternate solution propositions will get these assholes to treat you like a human being.

Don't work here (0)

Anonymous Coward | about a year ago | (#44243881)

I have worked at my present company for 15 years. What you are describing is simply one aspect of what I consider normal development here. We use a modified waterfall. Requirements are gathered and estimates are produced for everything through testing and deployment. That's not requirements then estimates it's estimates then requirements usually and sometimes estimates after some of the requirements. The estimates are always called estimates and everybody seems to understand that they are very ballpark. Somehow, though, they end up in MS Project as deadlines and milestones with a heads may or may not roll consequence associated at the end. They keep paying me and I keep coming back, so I guess you can get used to anything.

You have to start being a complete dick / say no. (0)

Anonymous Coward | about a year ago | (#44243885)

Sounds like my company. The only thing people seem to understand is when I started being a complete dick, and when someone says I need this done by this date and it is unreasonable, simply say no, too bad, you are the fucking moron sales guy that promised it on a whim, so no go back and tell your customer No. I get lucky and got support from my CIO and CEO, instead of getting fired. 99 out of 100 developers have an excruciating time saying No to people, so upper management gets used to the answer always being Yes. Not until you get a development leader with some balls that can say no will your situation improve.

You need someone to say no. (4, Interesting)

miltonw (892065) | about a year ago | (#44243895)

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:You need someone to say no. (0)

Anonymous Coward | about a year ago | (#44244461)

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.

Yep, this is how real engineers do it. If the client wants more stuff but won't pay for it then they simply don't get it, we continue along as per the original scope. One of many reasons I got out of software "engineering."

Agile + Scrum? (4, Informative)

merick (1878106) | about a year ago | (#44243911)

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

As one of my professors said (1)

GodfatherofSoul (174979) | about a year ago | (#44243917)

If you keep missing deadlines and find yourself in overtime crunches, the problem is with the way you estimate costs. Lots of shops assume that you're supposed to start working 60 hour weeks and running around flailing your arms right before every release. If that's your pattern, figure out why things are so delayed and factor that in. If management doesn't accept your estimates and they turn out to be closer to reality, there's not much more you can do.

Any changes and feature additions obviously have to be included in the estimate.

Re:As one of my professors said (0)

Anonymous Coward | about a year ago | (#44244055)

Typical ivory tower syndrome. Business is real life, shit happens. People get sick, leave, have family woes (ever tried to motivate someone that's lost both parents due to a DUI?, You can't.) Management over promise, sales even staff more so. The bean counters make unrealistic projections, and the board (or owners) favor accountants over those at the furnace. That's before spec changes, some of which have huge ramifications and are driving by law.

The simple solution is to constantly reevaluate where you are and move the release date, which like stock, can go up and down. 95% of software is in-house, yet it's the 5% "late" that makes nonsense news.

Push back (2)

AuMatar (183847) | about a year ago | (#44243937)

You can't do the impossible, and no techniques will allow you to do infinite work in a given period of time. This can be a permanent push back (never going to do it) or a temporary one (we'll discuss it at the next planning meeting).

If they won't be pushed back, stop caring and dust off the resume. Don't work for people who aren't willing to compromise.

Need to go against Agile (3, Insightful)

Todd Knarr (15451) | about a year ago | (#44243943)

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.

Re:Need to go against Agile (1)

avandesande (143899) | about a year ago | (#44244487)

Or you can just deliver it late. They will get over it.

doesn't really go against agile (1)

Chirs (87576) | about a year ago | (#44244785)

Agile is all about adaptive development. This includes management, not just the developers. Part of adjusting to new requests is to prioritize them relative to existing getting management to prioritize you're just bringing them into the Agile process.

Switch to Kanban (0)

Anonymous Coward | about a year ago | (#44243965)

When you are in an environment where they will not stick with the commited stories during a sprint Kanban is a good way to go. They can add anything they want whenever they want. But all they can control is what is the next item worked on, not when it is due.

Quality, Scope and Deadline (3, Insightful)

curunir (98273) | about a year ago | (#44243973)

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.

how to fix (1)

Anonymous Coward | about a year ago | (#44243985)

The whole point of a sprint is that once it starts, it doesn't change. This protects developers from your exact problem - managers screwing everything up. If it's not possible to do weekly sprints (build/release friday morning, plan friday afternoon, start work on monday, or some variant thereof), that are static once the storiesare decided on, you need to move to a "feature" model, where you can build/deploy whenever wherever and your "feature teams" just pick up the next feature in the list, which is prioritized by management. This way builds / deploys can never be late, because they happen all the time on a per-feature basis. If management decides a new feature / fix takes priority over whatever the feature teams are working on at the time, they can either wait a day for their request or they can pull a feature team immediately and start them on the new story.

Well, la dee dah da! (1)

Anonymous Coward | about a year ago | (#44244003)

Alrighty, let me put my onion on my belt, my teeth in, and give you whipper snappers a history lesson:

That's how it has always been. We have never been given enough time. Specs change and when you miss the deadline, it's your fault. Period, no excuses - there's ALWAYS something you could have done to meet it - that's what my manager told me at NCR.

And ...the point is?

Software development and IT (same fucking thing in my day) have been like this. You have to work 10 -12 hours a day or more, at least 5 days a week, and you dealt with it. Because back then, we were paid 80-90 thousand dollars a year in my area - and now, you're paid 80-90 thousand dollars a year in my area - after 20 years of inflation, btw. Just saying - with inflation, developer salaries have been going DOWN.

And after you spent your 10 -12 hours a day coding or engineering software, you went home reading a goddamn O'Reilly animal book on the latest and greatest "technology" and tried to figure out how to work it into your daily job because the next time you looked for a job, that technology that came out will be required along with 2+ years of experience in that technology. Things change.

Stopping now because it's banana pudding night, the TV room opened, and there's Matlock Marathon on!


Re:Well, la dee dah da! (1)

PRMan (959735) | about a year ago | (#44244601)

and there's Matlock Marathon on!


Wow, you are old.

Renegotiate your contract (1)

Intrepid imaginaut (1970940) | about a year ago | (#44244009)

Simple really, add both extra pay and extra time when new requests come in. The amount of extra pay and time are to be determined by the developer on a sliding scale. Developers don't need to adjust to unreasonable demands from clients, clients need to adjust to reality.

Burn the whole place to the ground (0)

Anonymous Coward | about a year ago | (#44244029)

And retire to a Mexican beach resort

Simple: Bad management (1)

Anonymous Coward | about a year ago | (#44244041)

The first issue is bad management. The second is lazy developers. Development should unit test their code before check in. If the project is 'that big', then there should be a server to run 'test builds' prior to actual check in.

Yes, I've had to fight these issues at multiple companies.

Acceptance Testing and signoff before release (0)

Anonymous Coward | about a year ago | (#44244071)

Have your 'clients' test any released builds in a non-production environment and sign off indicating their acceptance.

If they want the code fast - they can accelerate their testing process.

Deployments should be trivial (0)

Anonymous Coward | about a year ago | (#44244079)

The problem is that you've got a deployment schedule. It implies deployments are scary, complex things. If you do things right, deployments are trivial, zero downtime events. Extra feature? Extra deployment. No biggie. If you stop deploying on a schedule, you'll also stop wasting time waiting for friday (or thursday, if that's your regular deployment day of the week). Of course, part of any feature being deployed is peer review, proof of testing etc.

Also, what other people said. If your employer wants to be professional, call them on it. Sneaking in last-minute features is not professional. Request a meeting, raise the issue.

Institutionalize Change... (1)

jdbuz (962721) | about a year ago | (#44244089)

Product Manager here. And I'm the guy who just can't help himself to add in that one more feature that seems so obvious now but was somehow hiding in my blind spot previously. Oh, and we're gonna make a TON of money if you can just implement this.

Step one: accept that life means constant change and these requests are always going to happen, like it or not. Nature of the beast but you can moderate this.
Step two: find a way to get your arms around it. A formula of: one feature = X days slip on delivery date is not sustainable since all X's aren't created equal. This will ultimately backfire when features take a long time to implement because expectations have been incorrectly established. You need to have a code freeze date for each build and stick to it. Managing code branches and merging will be key.
Step three: Make sure your product manager has solid use cases. Features wrapped in a story tend to stick together. If the feature doesn't play well into an already defined use case (story) then it is likely superfluous to the main goal of the product and can wait. If the PM needs to change the use case to accommodate the new feature then the PM needs to get his or her act together (while understanding that PMs are human and can sometimes make mistakes, but this should not be a standard operating procedure, changing fundamental use case scenarios). Sales organizations are typically coin operated so they'll always ask for just this one feature to make the big sale. It's a lie. If they didn't need it last month then they can wait another month.

In my opinion, this in not something a developer should have to be concerned with, this is a product management issue. What is probable in these situations is that the PM is not including all stake holders in the requirements doc. All stake holders need to understand to some degree the end user's mental model (assumptions, motivations, goals, etc.) and if so a lot of these things will get vetted during the review process. But Sales, that darn Sales team... can't ever keep them happy; can't run a business without the revenue the bring in. They will always try but only the lesser ones will need said feature NOW to make the sale.

I don't know what I'm talking about! (1)

nine-times (778537) | about a year ago | (#44244105)

I'm not a developer, so take what I say with a grain of salt, but I *do* manage technical projects on a regular basis. I try to stick to the rule that deadlines are dependent on requirements. If you ask for something to be added to the project, then the deadline (and budget) must be reviewed and altered to account for the changes. It only makes sense.

But if you're trying to make a regular release schedule, then I'd suggest that you basically stop accepting new requests for each release some number of days ahead of time.

The key sentence in your post is, "But we still have to deal with constant incoming feature changes and requests that are expected to be included in this week's package." Change that expectation. Maybe tell people that all requested changes for Friday's release must be submitted at least a week in advance, and then set the task on Monday morning to review those requests and set them on a realistic schedule.

Of course, I might be talking out of my ass because I don't program and I don't really understand what Agile development is.

Re:I don't know what I'm talking about! (1)

shentino (1139071) | about a year ago | (#44244339)

If you have a hardass above you in the chain of command that not only insists on being unreasonable, but threatens to fire anyone who even SUGGESTS doing things differently, how do you handle that?

It sounds to me like TFA was submitted by someone looking for an escape from a hostile management environment.

It's all well and good to know that you need to change expectations. But if you have a hardass pulling rank on you, you're kinda fucked.

Re:I don't know what I'm talking about! (2)

PRMan (959735) | about a year ago | (#44244615)

You find another job. Life's too short to work for an asshole.

Formally find out why deadlines are missed (1)

milkasing (857326) | about a year ago | (#44244109)

After you miss your next deadline and/or push out a bug riddled release, task the initiative and get your group and sponsors together to formally find out why deadlines are missed.
As discussed by commentators above, the reasons are definitely a lack of a change management process (and possibly a lack of a clear scope / requirements definition). But somehow people are more receptive to the obvious when it comes from a discovery process, rather than being told.
After you set up a change management process figure out a way to get an estimate of how much the impact will be. So the next time some change comes up, tell them how much the release will be delayed up. front and ask them if they would want it for the next release.
Remember, the more time you spend on management, the less time you have to develop, so factor that into your schedule as well.

Document the requests (2)

eples (239989) | about a year ago | (#44244111)

Keep a written record each time something unreasonable is requested.

After a few months (6?) show the documentation to the manager of whomever is making the requests.

Then crack open a beer and wait for your new middle manager to arrive.

Political or not, software project or not, someone in the management chain isn't doing their fucking job and you should not simply accept that.

One Simple Sentence (3, Insightful)

Anonymous Coward | about a year ago | (#44244117)

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

According to scrum.... (2)

leuk_he (194174) | about a year ago | (#44244119)

Do agile proper. Choose a method. stick to it. Not a bit waterfall and a bit agile. then basically you are doing waterfall with some new term, but not new procedures.

Eg. with Scrum [] at the end of a sprint, the product is Done, or it is taken out. The development team decides how much work to take on. Since the development process is transparant business can guess that extra criteria will add load.

Business decides what are the priorities. Development determines how much can be done in a timebox and how they engineer it.

If there are more requirement that take extra time, then those requirements are taken to the next sprint. If there are delays, then those delays are the time of a full sprint, (3-4 weeks). And realize that 80% of perfect often is enough.

Things like "not an option" "business decides". "too costly"... are all in the big excuses book.

Play politics back (2)

Dishwasha (125561) | about a year ago | (#44244133)

To be perfectly honest, you as a developer probably shouldn't be defining timelines. That's what management is for. If management is failing at establishing stable timelines, call them out. It is their job to redefine the release process when it is needed, not you.

And don't keep the quitting option off the table. Typically the only time I've seen management change in a majorly positive fashion is when they have to deal with a mass exodus of developers.

Be more agile. (1)

Anonymous Coward | about a year ago | (#44244151)

Far too many companies partially adopt Agile development practices. They integrate the rapid iteration, sprints, iteration planning, and standups but avoid the real work which is writing unit tests, and integration testing. It's impossible to work at break neck speeds while maintaining the integrity of the build without unit testing and integration testing even if you have embeded testers on hand to test things for you and most non-programmers don't really seem to understand this concept.

Developers who are being introduced to Agile development practices most likely need some basic training beyond "how to use the iteration planning software" which addresses the concept of Agile development and the importance of writing good unit tests to validate that the code that was written is still working as expected after developer C, B and A have checked in code they've modified which may break someone else's features.

The whole point of Agile development is to essentially be able to jump from one thing to another, but that doesn't mean things shouldn't be planned out. If a customer comes in asking for changes that are not planned for this sprint it should get added to a backlog, prioritized and then added to the next sprint or delayed even further into the future.

So essentially what I'm suggesting is to first put in place development practices that will help maintain a working build. And secondly, you need to manage the change requests in the same way any service industry does. A request is made, it is assigned a priority. At an iteration planning session that task is either assigned for this weeks worth of work or pushed into a backlog where it will eventually be assigned. Any work not assigned for this weeks sprint which would include all feature change requests that come in after the iteration planning meeting will not be addressed until the next iteration planning session.

Granted this is all ideal talk, because most of the time the players involved don't really want to make a commitment to the Agile development process.

If you can't get buy in on integration testing and unit testing/training for the developers, and sprint planning go back to waterfall development practices. Otherwise you will wind up with a bunch of very stressed, unhappy programmers who are rapidly iterating themselves and the code base into a tangled constantly broken mess.

Just do what the gov't does: (1)

jennatalia (2684459) | about a year ago | (#44244219)

Step 1: Create expectations for contractors and then change your mind to something else. Step 2: ???? Step 3: Profit...oh wait, lawsuit, anti-profit.

Rule of thumb for swaps (0)

Anonymous Coward | about a year ago | (#44244239)

Okay, let's assume this since you say you're doing agile:

  • You're estimating the cost of stories going into the sprint (for example you might have a sprint where your team can do 20 points worth of stories, and so you have a five pointer, a three pointer, a two pointer and ten one pointers.)

  • You can estimate the new story they want to put in the sprint

If they want to put their new story in the current sprint then I've used the rule you have to take double the number of points worth of story out. So if they want to add a three pointer, then they'd have to take out at least six points worth of promised stories. The double points is to account for the fact that anything at the last minute is hard. This *also* has to come from work that hasn't been done yet - so say you've got a sprint with a six pointer in it that is two thirds done (going by your daily burndown) they can only get two points back by saying that this doesn't have to be delivered.

not your problem (1)

shentino (1139071) | about a year ago | (#44244257)

Fix the economy so that bosses can't get away with fucking over their workers because there's nowhere better to go.

Your bosses know damn well they are forcing you to make bricks without straw here. Don't overestimate how much power you have over this situation.

Since you say quitting isn't an option it appears you are captive to the situation and are going to have to put up with it. Still, now would be a good time to build references and find another employer.

See a few things (1)

multimediavt (965608) | about a year ago | (#44244353)

Rummaging through the thread I see a few good pieces of advice. One, somebody in the food chain needs to grow a set of balls and learn how to say no. Yeah, yeah, yeah, the-customer-is-always-right, if-I-piss-the-customer-off-we-may-never-get-any-more-business BS. It's BS. Grow a set! Second, even with a set and some compromise you will still need to start setting REAL (as in hard) deadlines for feature requests with regard to release dates. Project management 101, actually, and even the current methodologies assume there are still dates for changes. If your boss(es) don't know this already from experience before they became management or while managing elsewhere, they are incompetent and need to be rooted out. Not easy, mind you. Third, keep looking for other opportunities. Even if change starts you may not want to wait for the positive effects, as you may not retain your sanity/joie de vive long enough to reap them where you are.

Scrum master, product backlog, communication. (2)

Fuzzums (250400) | about a year ago | (#44244385)

Don't push back the deadline.
A new requirement / feature is given a priority and added to the product backlog.
It's not added to the sprint backlog.

I'm sure the customer can wait one week longer for a proper release with the new functionality.
If the feature request is so important that it ABSOLUTELY has to be in THIS release, restart the sprint from the beginning.
But that should be an exception, since it disrupts the production cycle.

Of course you explain these procedures with the customer and make sure he knows why it is important to stick to the production cycle (quality, productivity).

Also work on you Definition of Done.
Make sure you put "all unit tests passed" on that.

Dealing with that myself (1)

gman003 (1693318) | about a year ago | (#44244501)

We're not doing agile or scrum or anything - honestly, we have a development process that's like waterfall but with no falling. Nobody's charted out which parts are dependent on any other part.

But even with the complete lack of project management, scope creep is still a bigger problem.

The initial specs for the project ("R2" of a project we did earlier) started with about half a dozen items on the scope list. When the contract was signed (our company is technically contract working for another company), it had expanded to about ten.

Now it's around thirty, maybe forty depending on how you count things. We're about a month from the due date (we started in March), and we're horribly behind. Some of the things still don't even have specs. I'm trying to get them to trim scope - we've cut half a dozen things just this week, after I blew up on a phone call with the person in charge of managing the project (a combined VP/marketing lead/programmer with commit access, the most dangerous combination I've ever seen as he will sell a customer something, code it in a sleepless weekend, then expect us to help him when it breaks or needs more functionality).

backlog (0)

Anonymous Coward | about a year ago | (#44244603)

Your project manager and sprint master are not doing their jobs. Perhaps you should apply for the position.

If feature requests are still being added to the iteration, then development needs to immediately cease and the sprint needs backlogged.

The hell it isn't (0)

Anonymous Coward | about a year ago | (#44244661)

>(Unfortunately, quitting is not an option)

Unless you're an indentured servant or your family is being held at gunpoint, then quitting is always an option.

Proposed team motto (2)

dkleinsc (563838) | about a year ago | (#44244673)

"A lack of planning on your part does not constitute an emergency on our part."

Another option: Use the power of bureaucracy to your advantage. For example, create a fairly confusing Mid-Sprint Change Request Form that needs to be signed off by 2-3 people that are never in the office.

A third option: Make sure that the work that was requested properly gets released on time, while the work that was requested mid-sprint will get released when it's ready (which, if you're doing things right, is always later than on time).

The idea is to use the carrot of on-time quality delivery plus the stick of annoying bureaucracy and late delivery to push the people making requests towards doing the right thing.

To bad we can't work like attorneys (1)

CQDX (2720013) | about a year ago | (#44244687)

My wife is an attorney. When she's working on a case for a client, there isn't a lot of face time if she able to work out what needs to be done for the client in the initial meetings. Often she'll get clients who want to change or add things mid-stream. Fine... If you want to make a request after I've started working on your case, it's $150-$300/hr for me just to listen about what you want different. If I agree to do the work, it's another $150-$300/hr beyond the initial estimate of how much the total was going to be. And if it's more than a few hours I'll have to charge an additional retainer. This has cut down a lot on clients who bug for too many trivial reasons and don't realize it's just delaying things.

It's simple (1)

Charliemopps (1157495) | about a year ago | (#44244695)

You don't get deadlines until you get requirements. Once you have them you give them a quote. "If you want all of this it will be done by February 1st" if they complain, tell them what they'll have to cut out to meet their deadline. Once this processes is done EVERY CHANGE TO THE REQUIREMENTS COMES WITH A CHANGE IN THE DEADLINE. No matter how small it is, they send you a change, you send back your revised estimate. You keep track of all of these changes. When the projects complete you do a post-completion review and explain why you missed your original date, siting line by line all of their changes.

This is how it should always happen. The only real catch is you get into arguments with them about "what is a change?" and "We really meant this, not that" So it's important to have the requirements really nailed down. You can take short 1 day classes on these sorts of things, how to word stuff. You want to avoid requirements like "Make the billing application faster" Well... what does "Faster" mean? does 1% faster count? Do they mean LOAD faster? Or that the reports return data faster? You need to be very specific because they're rarely satisfied. Also, define what the billing application is... Very specifically. You really have no idea what they are doing on the business side and sometimes you can get all done and find out they are doing 90% of their work in a spreadsheet and then dumping it into your application. You could likely meet all your requirements just by doing away with the 10yr old lotus notes sheet some dead guy wrote back in the day.

You've already lost this battle (5, Informative)

Mandatory Default (323388) | about a year ago | (#44244723)

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.

Get a Manager (2)

Darinbob (1142669) | about a year ago | (#44244831)

Get a manager. This is the appropriate role for a manager, to stand as the gate keeper between the development team and the incoming barrage of requests. It doesn't matter what process you use if the manager is able to be an effective buffer. Ie, a new request comes in and the manager estimates how long it will take and then tells the requester either that the release will be delayed or that the feature will go into a subsequent release.

If the manager can not manage this process, then it will not matter at all what process is used because it won't fix the problem. Of course you could always be unlucky and be stuck with a bad manager, one who always sides with the requesters and is actively working against the developers, but no process is going to fix that problem either. Processes can and WILL be ignored. In fact, processes can often hide the problem of having a bad manager because nothing covers an ass better than a process.

Re:Get a Manager (1)

Darinbob (1142669) | about a year ago | (#44244847)

I should add that sometimes this means bad news for the manager. I have seen companies cycle through a sequence of managers, hiring and discarding them, until the company finally gets the picture that the managers were not being obstructionist but were actually doing the right thing.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?