Ask Slashdot: Development Requirements Change But Deadlines Do Not? 221
cyclomedia writes "Over a number of years my company has managed to slowly shift from a free-for-all (pick a developer at random and get them to do what you want) to something resembling Agile development with weekly builds. But we still have to deal with constant incoming feature changes and requests that are expected to be included in this week's package. The upshot is that builds are usually late, not properly tested and developers get the flak when things go wrong. I suspect the answer is political, but how do we make things better? One idea I had was that every time a new request comes in — no matter how small — the build gets pushed back by 24 or even 48 hours. I'd love to hear your ideas or success stories. (Unfortunately, quitting is not an option)"
Agile? (Score:5, Funny)
Re: Agile? (Score:2)
Re: Agile? (Score:5, Funny)
Typically, you start working er'ly in the morning. And stay at it till the even'n's glomming.
-- MarkusQ
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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? (Score:4, Funny)
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: (Score:3)
Re: (Score:3, Informative)
That already has a name:
http://en.wikipedia.org/wiki/Avalanche_model [wikipedia.org]
Re:Agile? (Score:5, Informative)
We use the Lava Flow [wikipedia.org] methodology.
Re: (Score:2)
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: (Score:2)
Re:Agile is about commitment, not flexibility (Score:5, Informative)
"Agile" is something of a misnomer... it's about committing to the work items you've estimated into your current sprint -- and no more. If someone wants to add a feature or request, it goes straight into the backlog for consideration during the next sprint planning session.
"Agile" is more about setting up a consistent delivery schedule... the build train leaves the same time each week, carrying whatever passed QA testing... and no more. The build train is never delayed, only derailed by an Act of God. That's right, if some exec really thinks that something is so important that it needs to be done *right now*, you completely stop all work, scrap the current sprint and start a new sprint planning session with all of the overhead that entails.
Anyone who practices differently is not practicing Agile according to the way it was intended. There are no "sprint schedule extensions" in Agile, since it's a measurement and estimation tool... the same way you don't measure with a longer "yardstick" when something is too big to fit in a 1-yard container.
Re: (Score:2)
Over the past few months, my org has moved from waterfall to scrum, and while the transition is painful for some people, I think it's really simple to grasp. We no longer have the 3-day meetings of adds/cuts to figure out what features we think we'll be able to ship in the next 2 years, we just have an idea of the bigger items we want to accomplish. Things that we need to do sooner rather than later are more detailed, such that we know whatever work we thi
Re: (Score:2)
Thank you. Best, most concise description of Scrum ever.
"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.
I'm currently working at my first gig where they're actually doing Agile properly, but even here, it has happened that something needed to be included in a current sprint. And we have accepted it (if it was small enough) but dropped other stuff out of the sprint. And even then, it always cost problems. Putting it on the backlog is nearly always the best approach. Disrupting a current sprint is always messy.
There are still a lot of things we're struggli
Committing to work in current sprint (Score:2)
Mod parent up.
Commit to your short-range deliverables. Restate your commitments daily, keep your team informed.
Re: (Score:2)
I worked in a real agile shop once. Sometimes we were agile to a customer feature wish in the morning and shipping him the update in the afternoon.
Of course this borders the realm of chaos but worked surprisingly well. But you need a small team with very good communications and customers who understand that it's them who are doing the testing.
And the funny thing: This never has been called "agile". It was way before it became a buzzword. We just called it "normal".
Re: (Score:2)
Everybody claims to be Agile, but few really are. Often they just do a daily stand-up (or even a sit-down), don't really plan, and generally mess about.
Process is important in Agile, but it's a flexible process that you refine during retrospectives after every sprint.
I'm currently at my first gig where they're actually doing Agile properly, and it works very well. Best work environment I've ever been in.
Re: (Score:2)
At least on a "Drunken Sailor" project you get somewhere. It's the "Brownian Motion", aka "Random Walk", projects that drive me nuts.
Re: (Score:2)
Keelhaul that filthy land lubber, send him down to the depths below!
Make that bastard walk the plank, with a bottle of rum and a Yo ho ho!
Pretty NSFW, sound is mandatory [youtube.com]
Re:Agile? (Score:5, Insightful)
...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: (Score:2)
...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.
Well, after all, "All You Have To Do Is..."
Re: (Score:3)
I had a manager to whom all problems could be solved with "a function that receives a string and returns another" and "can be done in 10 minutes".
He kept accepting project over project over project, and change over change over change. When I told him that we were already busy with one project or feature, he used to tell us "no problem, you can fit this one in your idle time, when you're slacking off". And I used to ask "which idle time?". With no answer, of course.
Fortunately, someone higher up noticed
Make a deadline for additions (Score:5, Interesting)
Re:Make a deadline for additions (Score:5, Funny)
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: (Score:2)
...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 (Score:5, Insightful)
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 (Score:4, Insightful)
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.
Re:Make a deadline for additions (Score:5, Insightful)
"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: (Score:2)
Re: (Score:3)
Re: (Score:3)
I disagree.
Irrelevant, you have no idea what the GP's source tree and processes look like. Also you appear to be talking about delivering a build to the testers rather than the end customer. If not then how do you handle a change that you know will take at least a month to test after it is added to the build?
Best if those costs are shown up-front and in their face, rather than hidden at the expense of team morale and product quality.
This^ is the actual solution, it's called "managing up" in buzzword bingo but we all know it as "office politics". As a "boomer" with 20+yrs as a corporate data plumber, I'm still learning how to do it right.
Re: (Score:2)
"Irrelevant, you have no idea what the GP's source tree and processes look like. Also you appear to be talking about delivering a build to the testers rather than the end customer. If not then how do you handle a change that you know will take at least a month to test after it is added to the build?"
Good point. I wouldn't say irrelevant, but you are correct that I do not know his particular situation and my comment might not apply.
Re:Make a deadline for additions (Score:4, Informative)
Branch the source code!
You should *always* have a stable base version that can be released at a moments notice. Each feature should be developed and tested on a branch. If the feature isn't "done", it isn't merged. If you discover a bug after merging you back it out again and review how you missed it.
Pausing development of the current set of half-finished features so you can shift priorities onto something else, should be as simple as creating a new branch and ignoring the others until your next sprint.
When requirements change in-sprint (Score:5, Interesting)
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 (Score:5, Interesting)
Re: (Score:3)
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 rui
Re:Scrum (Score:5, Interesting)
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 (Score:2)
And it's the BOSSES job to put 40 hours of work into the bucket each week with expectation that it can be a achieved. Not to just have a rolling list and HOPE developers hit what's important. Hesse systems break down because the boss is the one responsible for managing deadlines and expectations, not the developers. If the boss doesn't know what a reasonable quantity of work to accomplish in a week is, they are not really the boss.
Re:Scrum (Score:4, Interesting)
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 (Score:4, Insightful)
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).
Re: Scrum (Score:2)
I laughed when changing jobs wasn't an option.... FIRING YOU certainly is an option.
My company works strictly to tickets, but its a legacy system, not a product. Don't other places work against bug or enhancement requests versus normal development? We have items that are "projects" and items that have complex dependencies, so a certain number of items have to be completed at once, but I guess I don't understand how developers just "add features" each week to a system with out some formal inputs...
I must be
Re: (Score:2)
You totally missed the point. I'm saying you *don't* interrupt the sprint. You make the sprint long enough to get things done but short enough that changing business priorities get injected into the development process in a timely fashion.
A 1 week sprint is, in my opinion, almost always going to be too short. 30 days is almost always a reasonable sprint length, and as you say if something is *really* pressing you can always interrupt it. A one week sprint that you can interrupt is almost meaningless as a
Learn their language (money) (Score:2)
Yes!
You communicate with anyone by speaking to them in their own language. Maybe they understand your language as well, all good and fine. But the best way to reach someone is to speak his language.
Money people speak money. If you want to get through to them, speak money.
For that matter, if you are a developer who doesn't speak money, you might want t
Simple solution (Score:5, Insightful)
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 (Score:4, Insightful)
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.
Either featurefreeze or delay up front (Score:3)
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.
Be honest (Score:2)
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 (Score:4, Informative)
It's a discipline, it's part of project management, it works. You can look it up.
I don't believe this answer will be well received on /. because it is usually practiced by project managers, and /. doesn't believe in project management.
Re: (Score:3)
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 gee
Re: (Score:2)
That's because project management in software is mostly mythical. In practice, having a project manager just means you'll have TWO pointy-haired types running around demanding ridiculous things. But one will have a Gantt chart so it's so much better.
uhh (Score:5, Informative)
2. The developer's first job is to estimate how long it will take to satisfy the request.
3. If the request is too vague for an estimate to be made then the developer conferences with the request's originator to get the information he needs.
4. Once a time estimate has been made, the developer communicates it to a project manager.
5. If the request can be accommodated without delaying the release then the project manager gives the go ahead for the work to begin.
6. If the request cannot be accommodated without delaying the release then the project manager conferences with its originator (and the originators of any other requests currently slated for the current release) to determine which will be dropped.
THIS! (Score:2)
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: (Score:3)
Re: (Score:2)
Not many options (Score:5, Informative)
First, you can -- and probably should -- just accept that the deadlines don't mean anything. They self-evidently don't to anybody else, so why should they to you?
But if you must pretend that they mean something, then you've really only got three options:
1) adjust the deadline based upon how much actual work is involved with the new request;
2) factor into your initial estimate how much you think it'll take to do what you think they're likely to add on later;
3) or make new requests a separate project with their own life cycle.
This, of course, assumes that you're the one estimating time and setting deadlines. If somebody else is doing all that, forget about it. It's not your problem; it's the problem of whomever is setting deadlines. Either they need to be doing a better job at time / project / resource management, or they need to bring on enough additional developers to meet the demands, or they need to fire the incompetent hacks they've got working for them now who can't meet the demands of the job. Whatever the case may be, it's a management problem and nothing for a developer to worry about.
Cheers,
b&
Re: (Score:2)
Historical (Hysterical?) Observation (Score:4, Interesting)
You need someone to say no. (Score:5, Interesting)
Agile + Scrum? (Score:4, Informative)
If you are using Agile with a combination of Scrum (like we do), then every task is roughly estimated for the size of work required. In each sprint, you can only accomplish so much work. Over time you determine your teams "velocity" (the estimated size of work you can do in a sprint).
Then, you have a person who plays the role of Scrum master. His or her job is to "protect the sprint". Meaning they help keep new issues from entering the queue during the sprint. When an actual emergency or rush item comes up, the Scrum master (or lead, whomever) asks, "what is OK to drop from the sprint if we can't get both done?". Some places take turns being the Scrum master, so it need not be a set role.
The Scrum master has to be willing to be that gentle jerk, and say things like, "not now, but we can work on that in the next sprint".
As one of my professors said (Score:2)
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
Push back (Score:3)
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 (Score:4, Insightful)
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: (Score:2)
Or you can just deliver it late. They will get over it.
doesn't really go against agile (Score:2)
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 commitments...by getting management to prioritize you're just bringing them into the Agile process.
Quality, Scope and Deadline (Score:4, Insightful)
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.
Renegotiate your contract (Score:2)
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.
I don't know what I'm talking about! (Score:2)
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 da
Re: (Score:2)
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: (Score:3)
Re: (Score:3)
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?
Politely. With guile.
I don't know what you expect me to say. I've had to convince some hardass bosses of various things, and either I convinced them, or they convinced me, or I lived with it, or I quit. There's no magical answer here.
The question seemed to be, in effect, "Everyone expects things to be done in an unreasonable way. What technical thing can you do to meet the unreasonable demands?"
So my answer would be, "If their expectations are actually unreasonable, you won't meet them, so instead tr
Formally find out why deadlines are missed (Score:2)
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
Document the requests (Score:3)
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 (Score:3, Insightful)
"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.... (Score:2)
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 [scrum.org] 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
Play politics back (Score:3)
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.
not your problem (Score:2)
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 (Score:2)
Scrum master, product backlog, communication. (Score:3)
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 (Score:2)
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 h
Proposed team motto (Score:3)
"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.
It's simple (Score:2)
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 r
You've already lost this battle (Score:5, Informative)
You think you're fighting manager's lack of understanding of software development. You are wrong.
You are fighting politically savvy people who have found a way to blame you for their problems. They don't want you to solve the problem and will actively work to prevent you from solving the problem, because then you can't be the scapegoat.
If you don't have a VP or C-level manager who will fight this fight for you, then you've already lost. Don't bang your head against the wall. Play the same game as everyone else and find someone else that you can use as a scapegoat. Meanwhile, start looking for a new job.
Even if you miraculously "fix" this problem, someone else is going to claim credit and you're going to get nothing.
Re: (Score:2)
While blaming IT for their problems may work once or twice, those who do it more often look like idiots themselves. The project manager who delievers on time gets a raise, and the one who never delievers on time gets fired, even if he constantly blames IT.
Best thing to do is put a process in writing... One that will make it clear that last-minute requests will go in the queue behind all others. If you can point to a procedure some sociopath was not following, then they dangle on the hook for the late del
Get a Manager (Score:3)
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: (Score:2)
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.
What would a chef do? (Score:5, Insightful)
Re: (Score:2)
And chefs can spit in your food too. Remember that next time you torture you waitstaff or anyone else who touches your food.
Architects use "additional services" for creep (Score:2)
In our architectural practice [osterlundhall.com], we use the term "additional services" to quantify scope creep, basically anything beyond the scope defined in our proposal/contract.
This reinforces the need for making that initial statement of expectations clear AND the implications for any deviation thereafter.
Point to a (semi) physical task board (Score:2)
If these requests are made in person or at least by someone in the office, you should have a task board with your current work on it. When someone comes in with a request, say "I'd love to, but this is our current feature list, and my job is to work on those tasks. You're welcome to go argue with the people who gave me these features which one should be removed for your new request. Otherwise, talk to the product owner and get it added to the backlog and prioritized appropriately."
If these are coming in
If you can't quit, or win (Score:2)
Move over to Management or Marketing. You can thank me later from the deck of your trophy yacht.
You can't (Score:5, Interesting)
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
Lower Your Expectations (Score:2)
"Get the flak" -- in other words, someone (the business line) expresses anger.
Anger happens when people have expectations, and these expectations go unmet.
The answer is: Lower Your Expectations. (Management, I am looking at you.).
I'm guessing you can't actually say this to management, without coming off as sarcastic. But I a
The bigger the company, the bigger the problem. (Score:2)
I work for a large multinational (well, for a subsidiary. Parent company is massive. Global subsidiary is quite large. We're a regional offshoot).
We get a fair amount of our deadlines set by head office, with a "We've put out a press release saying it'll be out on this date". You can't say no, it won't work. This sort of thing isn't restricted to big companies. In smaller companies I've had bosses tell me (and this pre-dates Agile as IT design tool) that I have to have the code finished before the end of th
Re: (Score:2)
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.
Re: (Score:2)
most people appreciate honesty over disappointment
Only if you consistently deliver on your own promises.
Re: (Score:3)
If you're not consistently delivering on your own promises, then by what definition are you acting honestly?
Amen to "No" (Score:2)
Yes! I also learned the "say no" trick, and use it to good effect.
Re: (Score:2)
and there's Matlock Marathon on!
MATLOCK!
Wow, you are old.
Re: (Score:2)
since they can and will fire you for any reason they choose, quitting or sudden loss of employment is thus also always to be prepared for and considered.