Slashdot Mirror
Ask Slashdot: Development Requirements Change But Deadlines Do Not?
cyclomedia writes "Over a number of years my company has managed to slowly shift from a free-for-all (pick a developer at random and get them to do what you want) to something resembling Agile development with weekly builds. But we still have to deal with constant incoming feature changes and requests that are expected to be included in this week's package. The upshot is that builds are usually late, not properly tested and developers get the flak when things go wrong. I suspect the answer is political, but how do we make things better? One idea I had was that every time a new request comes in — no matter how small — the build gets pushed back by 24 or even 48 hours. I'd love to hear your ideas or success stories. (Unfortunately, quitting is not an option)"
We have a bastardized combo of waterfall and agile here. I call it the Drunken Sailor approach.
People in cars cause accidents....accidents in cars cause people
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.
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.
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.
-SaNo
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.
Stick Men
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.
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.
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.
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&
All but God can prove this sentence true.
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.
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.
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".
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.
I still have more fans than freaks. WTF is wrong with you people?
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.
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.
"Don't blame me, I voted for Kodos!"
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.
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.
I'm a 2000 man.
"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.
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.
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.
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.
Privacy is terrorism.
You find another job. Life's too short to work for an asshole.
Peter predicted that you would "deliberately forget" creation 2000 years ago...
"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.
I am officially gone from
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. 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.
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.
"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.
If you're not consistently delivering on your own promises, then by what definition are you acting honestly?
--- Most topics have many sides worth arguing, allow me to take one opposite you.
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
I am John Hurt.
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 try to change them."