Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Businesses Programming

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)"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Development Requirements Change But Deadlines Do Not?

Comments Filter:
  • Simple solution (Score:5, Insightful)

    by turgid ( 580780 ) on Wednesday July 10, 2013 @05:11PM (#44243767) Journal

    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.

  • Weak management (Score:1, Insightful)

    by Anonymous Coward on Wednesday July 10, 2013 @05:15PM (#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.

  • by Anonymous Coward on Wednesday July 10, 2013 @05:23PM (#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.

  • by Todd Knarr ( 15451 ) on Wednesday July 10, 2013 @05:25PM (#44243943) Homepage

    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.

  • by curunir ( 98273 ) * on Wednesday July 10, 2013 @05:27PM (#44243973) Homepage Journal

    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.

  • Re:Agile? (Score:5, Insightful)

    by Sponge Bath ( 413667 ) on Wednesday July 10, 2013 @05:30PM (#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.

  • by Anonymous Coward on Wednesday July 10, 2013 @05:38PM (#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.

  • Re:Simple solution (Score:4, Insightful)

    by Teancum ( 67324 ) <robert_horning AT netzero DOT net> on Wednesday July 10, 2013 @06:00PM (#44244359) Homepage Journal

    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.

  • by Jane Q. Public ( 1010737 ) on Wednesday July 10, 2013 @06:19PM (#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.

  • by Culture20 ( 968837 ) on Wednesday July 10, 2013 @07:15PM (#44245159)
    If a restaurant customer changes their mind while the chef is cooking their choice of meal, or maybe forget to request "no mushrooms" until 20 minutes after ordering, they may get the new dish, but they won't get it on time, and reasonable people understand that. Of course there are always unreasonable customers. Management reserves the right to not serve them.
  • Re:Scrum (Score:4, Insightful)

    by ATMAvatar ( 648864 ) on Wednesday July 10, 2013 @09:03PM (#44245867) Journal

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

  • by b4dc0d3r ( 1268512 ) on Wednesday July 10, 2013 @10:07PM (#44246209)

    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.

The Force is what holds everything together. It has its dark side, and it has its light side. It's sort of like cosmic duct tape.